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.}}
</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_updateloadaddr=0x81000000load=tftp ${loadaddr} naon/u-boot.binspi_update=sf probe 0:0; sf erase 0x20000 0x40000; sf write ${WarningMessageloadaddr} 0x20000 0x40000</pre> Here is the result of running them: <pre class="board-terminal">NAON#run load spi_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)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_updatekloadaddr=0x81000000loadk=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_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)8192 KiB AT45DB642D at 0:0 is now current device</pre> {{Board Specific Information|text=Please note that loading the wrong 1st stage Linux kernel image size may damage vary, depending on how you configure the hardware permanentlykernel itself. Also 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 power interruption during the update process will 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 allow 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 board to NAND sub-system. By default, both u-boot correctlyand Linux use BCH8. In this case user can refer <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>] [Recovery 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 Image into NAND flash requires# download the binary image (Naonvia TFTP)]] procedure# 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 ${loadaddr}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_update
load=mw.b ${loadaddr} 0xFF 0x40000; tftp ${loadaddr} dido/u-boot.bin
nand_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_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)
NAND erase: device 0 offset 0x20000, size 0x40000
Erasing at 0x0 -- 100% complete.
OK
HW ECC BCH8 Selected
NAND write: device 0 offset 0x20000, size 0x40000
131072 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_updatek
loadk=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 == Flashing images on 2688084 (290454 hex)NAND erase: device 0 offset 0xA0000, size 0x400000Erasing at 0x0 -- 100% complete.OKHW ECC BCH8 Selected NAND Flash ===write: device 0 offset 0xA0000, size 0x4000004194304 bytes written: OK</pre>
{{WorkInProgressBoard 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}}