Re: kwuartboot on DreamPlug success
On Wed, Oct 5, 2011 at 9:27 AM, Jari Kirma <jari@kirma.fi> wrote:
> On Wed, Oct 5, 2011 at 12:11 AM, Martin Lucina <mato@kotelna.sk> wrote:
>> [Moving this discussion to debian-arm to keep others in the loop,
>> this is regarding booting a DreamPlug from UART using Leigh's kwuartboot
>> which you can find at http://www.solinno.co.uk/public/kwuartboot/]
>>
>> leigh@solinno.co.uk said:
>>> On Fri, 30 Sep 2011 17:47:54 +0200, Martin Lucina wrote:
>>> >mato@kotelna.sk said:
>>> >>AFAICS there's an extra 0x200 byte header in the .kwb, do I just
>>> >>need to
>>> >>copy this onto the front of my u-boot.bin?
>>> >
>>> >Seems to work:
>>> >
>>> >[nodbug:kwuartboot-0.1]$ cat kwb-header u-boot.bin > new-boot.kwb
>>> >[nodbug:kwuartboot-0.1]$ ./kwuartboot /dev/ttyUSB0 ./new-boot.kwb
>>> >Sending boot pattern: power on or reset now...done
>>> >Sending file...|
>>> >Finishing...done
>>> >
>>> >Marvell>> ver
>>> >
>>> >U-Boot 2011.09-rc2-00003-g279bbbc-dirty (Sep 28 2011 - 10:04:28)
>>> >Marvell-DreamPlug
>>> >arm-linux-gnueabi-gcc (Debian 4.4.5-8) 4.4.5
>>> >GNU ld (GNU Binutils for Debian) 2.20.1.20100303
>>> >
>>> >Yoohoo. Leigh can you confirm that this is the right thing to do
>>> >and that's
>>> >just a verbatim magic header?
>>>
>>> Probably safer to configure the image to boot from UART.
>
> For those that wonder about this "magic header", see Marvell 88F6281
> functional specifications, section 24.2 ("BootROM Firmware"), and
> especially subsections 24.2.4.1 ("Main Header Format") and 24.2.4.2
> ("Header Extension Format"). The first of these subsections defines
> handling of the image being read, and the second basically contains
> list of configuration register - value pairs which BootROM initializes
> while it is still operating without memory peripherals (such as SDRAM)
> enabled, with only locked cache lines as it's working memory. Contents
> of these headers are SoC family and possibly SoC model specific, but
> they may also be board specific - since timings of SDRAM chips may
> vary. If you decode the contents of these headers, they're almost
> exclusively concerned with setting up the SDRAM registers. (It is
> notable that BootROM is SoC-specific piece of code, and it has no
> knowledge of board properties - so these headers are the only source
> of sane SDRAM timings before the actual contents of the image are
> loaded to SDRAM, which is the typical practice.) As far as I know,
> this header is also found in other boot media that BootROM would read
> directly - such as SPI flash.
Just one more note; contents of the main header differ on basis of
boot "media" being used, but the extension headers (really a register
setup list and a checksum) are unlikely to differ. Thus, copying the
contents of these headers from regular flash boot loader and modifying
the main header for the specific boot device should be a good way to
acquire usable headers for a board. Making a straight copy of the main
header wouldn't work.
Reply to: