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 :-)

Best regards,
Ɓukasz Majewski



Attachment: pgpj27Ph3jd2S.pgp
Description: OpenPGP digital signature

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to