3,260
edits
Changes
m
no edit summary
{{InfoBoxTop}}
{{AppliesToNaonAppliesToNaonFamily}}
{{Applies To U-Boot}}
{{InfoBoxBottom}}
* user can load the image into ram via TFTP
** there's also a serial load option (using kermit or ymodem protocol) but we'll take care of this (primary due its slowness). Anyway, you can refer to [[Recovery U-Boot Image (Naon)]] again, which uses the serial port to download the 2nd stage U-Boot binary.
{{WarningMessage|text=Please note that loading the wrong U-Boot (1st or 2nd stage) image may damage the hardware permanently. Also a power interruption during the U-Boot update process may not allow the board to boot correctly. In this case user can refer to [[Recovery U-Boot Image (Naon)]] procedure for recovery}}
{{ImportantMessage|text=Please note that U-Boot 1st stage does NOT have networking support, due size constraint. For this reason, a corruption of the 2nd stage will allow 1st stage boot but will not allow loading 2nd stage via TFTP. Again please refer to the [[Recovery U-Boot Image (Naon)|recovery procedure]] for more details}}
{{Board Specific Information|text=Before continue reading, we suggest to first have a look at [[Memory organization (Naon)|Naon Memory organization]], where details of memory addresses and size are detailed.}}
# erase a flash range
# write the binary image from RAM to SPI Flash
In the following section we'll see an example of how those generic steps apply to each different image.
==== Flashing U-Boot 1st Stage ====
Into the default U-Boot environment there are usually two macro the do all the work:
<pre class="board-terminal">
NAON#print spi_load_1st spi_update_1st
spi_load_1st=tftp ${loadaddr} naon/MLO
spi_update_1st=sf probe 0:0; sf erase 0x0 0x20000; sf write ${loadaddr} 0x0 0x20000
</pre>
Running them update the U-Boot 1st stage image.
<pre class="board-terminal">
NAON#run spi_load_1st spi_update_1st
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.0.250; our IP address is 192.168.0.78
Filename 'naon/u-boot.min.spi'.
Load address: 0x81000000
Loading: ############
done
Bytes transferred = 58780 (e59c hex)
8192 KiB AT45DB642D at 0:0 is now current device
NAON#
</pre>
==== Flashing U-Boot 2nd Stage ====
Like the 1st stage, 2nd stage is handled by two macro in U-Boot default environment:
<pre class="board-terminal">
NAON#print loadaddr load spi_update
loadaddr=0x81000000
load=tftp ${loadaddr} naon/u-boot.bin
spi_update=sf probe 0:0; sf erase 0x20000 0x40000; sf write ${loadaddr} 0x20000 0x40000
</pre>
Here is the result of running them:
<pre class="board-terminal">
NAON#run load spi_update
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.0.250; our IP address is 192.168.0.78
Filename 'naon/u-boot.bin'.
Load address: 0x81000000
Loading: ######################################
done
Bytes transferred = 193092 (2f244 hex)
8192 KiB AT45DB642D at 0:0 is now current device
</pre>
==== Flashing Linux Kernel ====
Loading and updating kernel image does not differ from U-Boot images:
<pre class="board-terminal">
NAON#print loadaddr loadk spi_updatek
loadaddr=0x81000000
loadk=tftp ${loadaddr} ${bootfile}
spi_updatek=sf probe 0:0; sf erase 0x80000 0x300000; sf write ${loadaddr} 0x80000 0x300000
</pre>
<pre class="board-terminal">
NAON#run loadk spi_updatek
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.0.250; our IP address is 192.168.0.78
Filename 'naon/uImage'.
Load address: 0x81000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
######
done
Bytes transferred = 2688084 (290454 hex)
8192 KiB AT45DB642D at 0:0 is now current device
</pre>
{{Board Specific Information|text=Please note that Linux kernel image size may vary, depending on how you configure the kernel itself. The default erase size (3MiB) should be enough large for all configuration but the user needs to take care of changing this value if using a bigger kernel. User should also resize Linux kernel [[Memory Tecnology Device (MTD)|MTD]] partitioning accordingly}}
=== Flashing images on NAND Flash ===
NAND Flash can be used for:* U-Boot (1st and 2nd stage) storage* U-Boot environment storage* Linux Kernel Image storage* Root File System storage (e.g. by using UBIFS) ==== Using NAND Flash ==== U-Boot uses <code>nand</code> (''NAND sub-system'') commands and all its subcommands, to manage NAND flashes. As with all U-Boot commands, there's a brief <code>help</code> description: <pre class="board-terminal">NAON##help nandnand - NAND sub-system Usage:nand info - show available NAND devicesnand device [dev] - show or set current devicenand read - addr off|partition sizenand write - addr off|partition size read/write 'size' bytes starting at offset 'off' to/from memory address 'addr', skipping bad blocks.nand erase [clean] [off size] - erase 'size' bytes from offset 'off' (entire device if not specified)nand bad - show bad blocksnand dump[.oob] off - dump pagenand scrub - really clean NAND erasing bad blocks (UNSAFE)nand markbad off [...] - mark bad block(s) at offset (UNSAFE)nand biterr off - make a bit error at offset (UNSAFE)</pre> First of all we need to configure which ECC algorithm is used by the NAND sub-system. By default, both u-boot and Linux use BCH8. <code>nandecc</code> command is used to change ECC algorithm: <pre class="board-terminal">NAON#help nandeccnandecc - Switch NAND ECC calculation algorithm b/w hardware and software Usage:nandecc [sw|hw <hw_type>] [sw|hw]- Switch b/w hardware(hw) & software(sw) ecc algorithm hw_type- 0 for Hamming code 1 for bch4 2 for bch8 3 for bch16 NAON#nandecc hw 2HW ECC BCH8 Selected</pre> Generally speaking flashing a binary from U-Boot into NAND flash requires# download the binary image (via TFTP)# choose the correct ECC algorithm# erase a flash range# write the binary image from RAM to NAND Flash In the following section we'll see an example of how those generic steps apply to each different image. ==== Flashing U-Boot 1st Stage ==== Into the default U-Boot environment there are usually two macro the do all the work: <pre class="board-terminal">NAON#print nand_load_1st nand_update_1stnand_load_1st=mw.b ${loadaddr} 0xFF 0x20000; tftp ${WorkInProgressloadaddr} naon/MLOnand_update_1st=nand erase 0x0 0x20000; nandecc hw 2; nand write.i ${loadaddr} 0x0 0x20000</pre> Running them update the U-Boot 1st stage image. <pre class="board-terminal">NAON#run nand_load_1st nand_update_1stlink up on port 0, speed 100, full duplexUsing cpsw deviceTFTP from server 192.168.0.250; our IP address is 192.168.0.78Filename 'naon/MLOLoad address: 0x81000000Loading: ############doneBytes transferred = 58780 (e59c hex)NAND erase: device 0 offset 0x0, size 0x20000Erasing at 0x0 -- 100% complete.OKHW ECC BCH8 Selected NAND write: device 0 offset 0x0, size 0x20000131072 bytes written: OKNAON#</pre> ==== Flashing U-Boot 2nd Stage ==== Like the 1st stage, 2nd stage is handled by two macro in U-Boot default environment: <pre class="board-terminal">NAON##print load nand_updateload=mw.b ${loadaddr} 0xFF 0x40000; tftp ${loadaddr} dido/u-boot.binnand_update=nand erase 0x20000 0x40000; nandecc hw 2; nand write.i ${loadaddr} 0x20000 0x40000</pre> Here is the result of running them: <pre class="board-terminal">NAON#run load nand_updatelink up on port 0, speed 100, full duplexUsing cpsw deviceTFTP from server 192.168.0.250; our IP address is 192.168.0.78Filename 'naon/u-boot.bin'.Load address: 0x81000000Loading: ######################################doneBytes transferred = 193092 (2f244 hex)NAND erase: device 0 offset 0x20000, size 0x40000Erasing at 0x0 -- 100% complete.OKHW ECC BCH8 Selected NAND write: device 0 offset 0x20000, size 0x40000131072 bytes written: OK</pre> ==== Flashing Linux Kernel ==== Loading and updating kernel image does not differ from U-Boot images: <pre class="board-terminal">NAON#print loadk nand_updatekloadk=mw.b ${loadaddr} 0xFF 0x400000; tftp ${loadaddr} ${bootfile}nand_updatek=nand erase 0xA0000 0x400000; nandecc hw 2; nand write.i ${loadaddr} 0xA0000 0x400000</pre> <pre class="board-terminal">NAON#run loadk nand_updateklink up on port 0, speed 100, full duplexUsing cpsw deviceTFTP from server 192.168.0.250; our IP address is 192.168.0.78Filename 'naon/uImage'.Load address: 0x81000000Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######doneBytes transferred = 2688084 (290454 hex)NAND erase: device 0 offset 0xA0000, size 0x400000Erasing at 0x0 -- 100% complete.OKHW ECC BCH8 Selected NAND write: device 0 offset 0xA0000, size 0x4000004194304 bytes written: OK</pre> {{Board Specific Information|text=Please note that Linux kernel image size may vary, depending on how you configure the kernel itself. The default erase size (4MiB) should be enough large for all configuration but the user needs to take care of changing this value if using a bigger kernel. User should also resize Linux kernel [[Memory Tecnology Device (MTD)|MTD]] partitioning accordingly}}