Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images

[Sascha Hauer <s.hauer@pengutronix.de>]

On Mon, May 06, 2013 at 10:35:40PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:21 Mon 06 May     , Thomas Petazzoni wrote:
> > Hello,
> > 
> > On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> > 
> > > > And it's does not require you to generate the image before flashing.
> > > > And request the blob by XMODEM will NEVER work to update at runtime
> > > > as can not discuss with the ROM code via XMODEM. So yes this will
> > > > not work for self update
> > > 
> > > You seem to be assuming that the bootloader is already running fine
> > > on the box, which is not the case that Thomas has addressed. In order
> > > to *flash* the bootloader to the device, you need that DDR3 code to
> > > be *executed*, and if you had read his cover mail carefully, you'd
> > > have seen that this happens *during* the XMODEM upload sequence
> > > (hence the changes to kwboot to protect the upload while this code
> > > talks to the serial port). It's painful but that's how it works, and
> > > once you get it after all it's rather flexible in the end.
> > > 
> > > So please don't use your update code as an argument as it's not the
> > > interesting part here.
> > 
> > Just to expand on what Willy explains: the bootable image contains
> > essentially 3 things:
> > 
> >  * A header describing the image
> >  * A binary header that contains the binary blob responsible for
> >    calculating the DDR3 timings
> >  * The payload, which in our case is Barebox.
> > 
> > When the ROM code sees a bootable image on SPI/NAND, or receives it
> > through Xmodem, it sets up the MMU, initializes the L2 cache as SRAM,
> > and it copies the header of the image (including the binary header)
> > into the SRAM. At this point, it *stops* getting data from Xmodem, and
> > executes the binary blob to configure the DDR3. Then, it goes on to
> > fetch the rest of the image (i.e the payload) and pushes that directly
> > to the DRAM, at an address defined in the header of the image. So the
> > DDR3 training code actually gets executed in the *middle* of the Xmodem
> > transfer, and the Xmodem transfer cannot continue if the DDR3 timings
> > have not been set up properly by the binary blob.
> Same principle as on Atmel when you flash via XMODEM or USB Device
> 
> This does not means you need to generate any specific media file
> > 
> > So, when you have in front of your eyes a device with *nothing* on it,
> > then you *must* have an image as prepared by kwbimage, that contains
> > those three elements: the header, the binary blob, and the payload, and
> > you must use the kwboot tool to push it through Xmodem to the SoC.
> > 
> > For self-update, there is no problem: the same kwbimage tool can
> > generate either an image that boots from UART, SPI, NAND or SATA. So
> > you can simply flash the generated image wherever you want on a SPI
> > flash or NAND flash, reboot and that's it. The image needs to be
> > slightly different depending on the boot media, but that's really
> > because the Marvell ROM code insists in the image having a 'blockid',
> > which identifies on which boot media the image is stored.
> 
> this is where it's wrong, you does not need such binary at all, barebox update
> will handle this by himself and will never requiere one image per media
> 
> As barebox does not care wheren it boot from or where the dev is stored. we
> choose is at runtime not at compile time
> 
> Barebox update will generate the correct image for the storagemedia at
> runtime

You need a running barebox to be able to run barebox update. This tool
is for being able to run something for the first time.

Without this tool you have a can with the can opener inside.

> > 
> > Jean-Christophe, I think you should have a serious look at the boot
> > process of Marvell SoC before aggressively telling everybody that they
> > are wrong. It's not because you know how AT91 and i.MX are booting that
> > you necessarily know the specificities of Marvell SoCs. Remember also
> > that the Marvell Armada 370 and XP have a different booting process than
> > Marvell Kirkwood (Marvell Kirkwood does not have this mechanism of
> > binary blob).
> 
> I very well such mecanism ST and ST-Ericsson use similar way. But mandatory to
> generate the barebox image for a storage media is a non sense. That's why we
> work to have multi-arch. SO no this is in the oposite way of the whole work on
> barebox done for months. It's regression

It's absolutely necessary to generate SoC specific images, because
that's all that SoCs are able to boot.
All that multiarch for a bootloader can do is to reuse the same binary
for different SoCs. Still you have to encapsulate it in SoC specific
images.
The fact that often you want to be able to generate SoC specific images
from a generic binary during runtime is orthogonal to this issue.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox