On 12/28/2016 09:52 AM, Lukasz Majewski wrote: > Hi Marek, > >> 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 ? > > I do not use SPI NOR, it is parallel NOR.
Sorry, I meant parallel NOR of course. >> It's a bit strange we had to use u-boot.bin with SPL there. >> > > This is how the legacy system behaves. It uses (by default) Parallel > NOR for booting (with advised/provided NOR memory timings). After doing > some measurements, it turned out that for "tunned" u-boot/SPL there > would be the best way to copy it to ram and execute it from there (just > like eMMC). > > Hence, I would like to use u-boot.img in both booting scenarios. I think I was mistaken yesterday, I don't think I understand why copying the image including the header into RAM has any benefit compared to copying just the image payload to RAM (and yes, we're getting back to my original question). -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
