Dear Mike Dunn,
On 04/11/2013 12:20 PM, Marek Vasut wrote:
Dear Mike Dunn,
A quick overview of u-boot implementation on the treo 680...
The treo 680 has a Diskonchip G4 nand flash chip. This device has a 2k region that maps to the system bus at the reset vector in a NOR-like fashion so that it can be used as the boot device. The phone is shipped with this 2k region configured as write-protected (can't be modified) and programmed with an initial program loader (IPL). At power-up, this IPL loads the contents of two flash blocks to SDRAM and jumps to it. The capacity of the two blocks is not large enough to hold all of u-boot, so a u-boot SPL is used. To conserve flash space, these two blocks and the necessary number of subsequent blocks are programmed with a concatenated spl + u-boot image. That way, the IPL will also load a portion of u-boot proper, and when the spl runs, it relocates the portion of u-boot that the IPL has already loaded, and then resumes loading the remaining part of u-boot before jumping to it.
The default_environment is used (CONFIG_ENV_IS_NOWHERE) because I didn't think that having a writable environment was worth the cost of a flash block, although adding it would be straightforward. I abuse the CONFIG_EXTRA_ENV_SETTINGS option to specify the usbtty for the console (CONFIG_SYS_CONSOLE_IS_IN_ENV).
Support for the LCD is included, but currently it is only useful for displaying the u-boot splash screen. But if u-boot is built without the usbtty console, it does display the auto-boot progress nicely.
Signed-off-by: Mike Dunn mikedunn@newsguy.com
I think the tool shall really go as a separate patch. Besides, can the tool not be implemented as a part of u-boot's mkimage infrastructure?
OK, I can make the flash_u-boot utility (which writes u-boot to the flash boot blocks) a separate patch.
As for making it part of mkimage... I didn't really consider that because based on my (limited) knowledge, I figured they are unrelated. As I understand it, mkimage creates an OS image file that u-boot can parse and load. flash_u-boot is a utility that performs the task of writing u-boot itself to flash.
It can create an bootloader image that can be written to flash using standard mtd utilities. Does this not cut it for you? Why do you need a separate flasher, because the G4 is special ?
I figured that mine was a special case, since u-boot must be written in a special format (redundant pages) and in a special manner (alternate 4k regions skipped), with the flash device in a special mode, and so it can not be done in the normal manner; e.g., 'nandwrite' from mtd-utils, or its u-boot 'nand write' equivalent, even if you first ran the u-boot image through a separate utility that simply converted the format of the image.
Hope that makes sense. Any insight appreciated. I'll take a look at what's in the tools directory.
I see ... so the G4 is such a horrible beast :( OK
Best regards, Marek Vasut