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.
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.
Best regards, Łukasz Majewski