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

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 16:13 Mon 06 May     , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> On Mon, 6 May 2013 16:04:39 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> 
> > > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > > at that the same time completely wrong. Your comments make it entirely
> > > > > clear that you haven't even read the comments at the top of file.
> > > > I did but still think we can handle it in C
> > > > 
> > > > and need to handle by barebox itself when flashing
> > > 
> > > The image is pushed to the target through X-modem, directly talking to
> > > the ROM code of the SoC. Do you want the kwboot tool to prepare the
> > > image? It seems to me like it makes a lot more sense to have a tool to
> > > prepare the image.
> > 
> > yes a you want to re-flash barebox itself and you will do for ddr and I do not
> > want to care about all of this blob stuff twht the board already known
> 
> Sorry, but I don't understand what you're trying to explain here, your
> english sentence doesn't make sense.
> 
> The binary blob is needed for now. I've intentionally written a tool
> that allows people to extract this binary blob from their existing
> bootloader image so we don't have to store this binary blob anywhere in
> the Barebox tree. As I explained, getting a working DDR3 training code
> will be something that can be done later on, but it's not yet my
> priority.
> 
> > > Remember also that this tool is needed to *extract* existing images.
> > > And you haven't explained how you intend to do this without a proper
> > > userspace tool such as kwbimage.
> > 
> > why extract?
> > 
> > you generated at runtime
> 
>  1) Because it's useful to extract the various parameters of an
>  existing bootloader image, to see how it was built by the vendor to
>  use the same parameters. For example, for Kirkwood SoCs, the header
>  contains the values to put in the DRAM controller to configure the
>  right timings, and it is useful to extract those values into a
>  configuration file, later used to create a shiny new image that
>  contains Barebox.
> 
>  2) Because it's useful to extract the binary blob needed to configure
>  the DDR3 timing dynamically (for Armada 370/XP).

You do not read the comment

we need *runtime* update not *only* *xmodem* flashing. Barebox need to extract
by itself the information from a running platfrom in C

This is the barebox update that will ensure a binary is correct before
flashing and can only request barebox and not the blob stuff to udpate itself
> 
> > > Quoting Sascha, an e-mail for this thread:
> > > 
> > > """
> > > Anyway, what we do on i.MX doesn't really scale anymore since the more
> > > complicated features of the image format can't be used with C
> > > structures. I'm working on replacing this with a imx-image tool.
> > > You seem to use checksums in your images. These can't be generated
> > > in C or CPP anyway.
> > > """
> 
> Have you read Sascha comment?
Yes you do not read what I write. I write *runtime* not *compiling* time

and yes if we can do *compiling* time I want it more that u-boot style tools
> 
> Thanks,
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

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