On 12/26/2016 05:36 PM, Lukasz Majewski wrote: > Hi Marek, > >> On 11/29/2016 07:18 PM, Tom Rini wrote: >>> On Tue, Nov 29, 2016 at 11:50:34AM +0100, Marek Vasut wrote: >>>> On 11/29/2016 10:11 AM, Lukasz Majewski wrote: >>>>> Hi Marek, >>>>> >>>>>> On 11/28/2016 10:09 PM, Lukasz Majewski wrote: >>>>>>> This define gives the possibility to copy entire image >>>>>>> (including header - e.g. u-boot.img) from NOR parallel memory >>>>>>> to e.g. SDRAM. The current code only supports loading the raw >>>>>>> binary image (the u-boot.bin). >>>>>>> >>>>>>> The legacy behavior is preserved, since other board don't >>>>>>> enabled this option. >>>>>> >>>>>> Sooooo, what's the usecase again ? ;-) >>>>> >>>>> :-) >>>>> >>>>> The use case is to allow u-boot.img being loaded from Parallel >>>>> NOR. The current code only supports u-boot.bin. >>>> >>>> Why is u-boot.bin (or the payload) not sufficient ? Why do you >>>> need the header ? >>> >>> Well, the general use-case and code flow is that we load u-boot.img >>> (or a FIT image) and if all else fails, fall back to assuming >>> a .bin and a known address). >>> >> And exactly how is that whole image useful in RAM ? Sorry, I still do >> not see it, usually you just need the executable payload, although >> even that can be left in flash most of the time. > > The use case is that I do want to boot from SD card/eMMC and NOR with > using u-boot.img. > > I would like to avoid situation when for NOR I must use u-boot.bin and > for eMMC u-boot.img. > > Such approach keeps things as simple as possible :-)
Oh, so it allows you to detect bitrot for the content in SPI NOR ? It's a bit strange we had to use u-boot.bin with SPL there. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
