From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Dunn Date: Fri, 12 Apr 2013 05:51:16 -0700 Subject: [U-Boot] [PATCH v2 7/7] add support for palm treo 680 board In-Reply-To: <201304112120.50954.marex@denx.de> References: <1365641128-15812-1-git-send-email-mikedunn@newsguy.com> <1365641128-15812-8-git-send-email-mikedunn@newsguy.com> <201304112120.50954.marex@denx.de> Message-ID: <51680344.80800@newsguy.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > 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. 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. Thanks Marek, Mike