Re: kwuartboot on DreamPlug success
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.
Reply to: