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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
