* [U-Boot] distro boot on ls2085ardb
@ 2017-02-08 22:55 Stuart Yoder
2017-02-08 23:06 ` york sun
0 siblings, 1 reply; 6+ messages in thread
From: Stuart Yoder @ 2017-02-08 22:55 UTC (permalink / raw)
To: u-boot
All,
The patch Alex submitted to enable distro boot on ls2085ardb sets
up a default bootcmd that looks like this:
bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
cp.b $kernel_start $kernel_load $kernel_size &&
bootm $kernel_load || run distro_bootcmd
Was there any particular reason to attempt the NOR flash boot
first? (Just backwards compatibility?) That "cp.b" takes a full
30 seconds and seems potentially unnecessary. I thought the board
was hung.
We want to support distro boot on all NXP LS* boards, and I'm wondering
if it's better to just make running distro_bootcmd the default, and
then fall back to NOR flash boot if distro boot fails.
bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
run distro_bootcmd ||
cp.b $kernel_start $kernel_load $kernel_size &&
bootm $kernel_load
Thoughts?
Thanks,
Stuart
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] distro boot on ls2085ardb
2017-02-08 22:55 [U-Boot] distro boot on ls2085ardb Stuart Yoder
@ 2017-02-08 23:06 ` york sun
2017-02-08 23:08 ` Peter Newton
0 siblings, 1 reply; 6+ messages in thread
From: york sun @ 2017-02-08 23:06 UTC (permalink / raw)
To: u-boot
On 02/08/2017 02:55 PM, Stuart Yoder wrote:
> All,
>
> The patch Alex submitted to enable distro boot on ls2085ardb sets
> up a default bootcmd that looks like this:
>
> bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
> cp.b $kernel_start $kernel_load $kernel_size &&
> bootm $kernel_load || run distro_bootcmd
>
> Was there any particular reason to attempt the NOR flash boot
> first? (Just backwards compatibility?) That "cp.b" takes a full
> 30 seconds and seems potentially unnecessary. I thought the board
> was hung.
>
> We want to support distro boot on all NXP LS* boards, and I'm wondering
> if it's better to just make running distro_bootcmd the default, and
> then fall back to NOR flash boot if distro boot fails.
>
> bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
> run distro_bootcmd ||
> cp.b $kernel_start $kernel_load $kernel_size &&
> bootm $kernel_load
>
> Thoughts?
It was for backward compatibility. Even I have pointed out numerous
times (internally) that cp.b should not be used for this case, and even
pointed out how to make a FIT image with load address, the board
maintainer(s) didn't act. One change I can propose is to drop the "cp.b
$kernel_start $kernel_load $kernel_size" and run "bootm $kernel_start"
directly. If it fails, then falls to distro_bootcmd.
York
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] distro boot on ls2085ardb
2017-02-08 23:06 ` york sun
@ 2017-02-08 23:08 ` Peter Newton
2017-02-08 23:12 ` york sun
0 siblings, 1 reply; 6+ messages in thread
From: Peter Newton @ 2017-02-08 23:08 UTC (permalink / raw)
To: u-boot
> From: york sun
> Sent: Wednesday, February 08, 2017 5:06 PM
> To: Stuart Yoder <stuart.yoder@nxp.com>; agraf at suse.de; Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: Peter Newton <peter.newton@nxp.com>; u-boot at lists.denx.de
> Subject: Re: distro boot on ls2085ardb
>
> On 02/08/2017 02:55 PM, Stuart Yoder wrote:
> > All,
> >
> > The patch Alex submitted to enable distro boot on ls2085ardb sets up a
> > default bootcmd that looks like this:
> >
> > bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
> > cp.b $kernel_start $kernel_load $kernel_size &&
> > bootm $kernel_load || run distro_bootcmd
> >
> > Was there any particular reason to attempt the NOR flash boot first?
> > (Just backwards compatibility?) That "cp.b" takes a full
> > 30 seconds and seems potentially unnecessary. I thought the board was
> > hung.
> >
> > We want to support distro boot on all NXP LS* boards, and I'm
> > wondering if it's better to just make running distro_bootcmd the
> > default, and then fall back to NOR flash boot if distro boot fails.
> >
> > bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x580700000 &&
> > run distro_bootcmd ||
> > cp.b $kernel_start $kernel_load $kernel_size &&
> > bootm $kernel_load
> >
> > Thoughts?
>
> It was for backward compatibility. Even I have pointed out numerous times (internally) that cp.b should not be used for this case, and
> even pointed out how to make a FIT image with load address, the board
> maintainer(s) didn't act. One change I can propose is to drop the "cp.b $kernel_start $kernel_load $kernel_size" and run "bootm
> $kernel_start"
> directly. If it fails, then falls to distro_bootcmd.
I wondered why we needed the cp.b at all. How do you add the load address to fit?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] distro boot on ls2085ardb
2017-02-08 23:08 ` Peter Newton
@ 2017-02-08 23:12 ` york sun
2017-02-09 2:43 ` Prabhakar Kushwaha
0 siblings, 1 reply; 6+ messages in thread
From: york sun @ 2017-02-08 23:12 UTC (permalink / raw)
To: u-boot
On 02/08/2017 03:08 PM, Peter Newton wrote:
>> From: york sun
<snip>
>>
>> It was for backward compatibility. Even I have pointed out numerous times (internally) that cp.b should not be used for this case, and
>> even pointed out how to make a FIT image with load address, the board
>> maintainer(s) didn't act. One change I can propose is to drop the "cp.b $kernel_start $kernel_load $kernel_size" and run "bootm
>> $kernel_start"
>> directly. If it fails, then falls to distro_bootcmd.
>
> I wondered why we needed the cp.b at all. How do you add the load address to fit?
>
FIT image header has load address and entry address. Our SDK didn't fill
in load address before (not sure now). If the load address exists, the
image(s) would be copied accordingly.
York
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] distro boot on ls2085ardb
2017-02-08 23:12 ` york sun
@ 2017-02-09 2:43 ` Prabhakar Kushwaha
2017-02-09 17:03 ` york sun
0 siblings, 1 reply; 6+ messages in thread
From: Prabhakar Kushwaha @ 2017-02-09 2:43 UTC (permalink / raw)
To: u-boot
> -----Original Message-----
> From: york sun
> Sent: Thursday, February 09, 2017 4:43 AM
> To: Peter Newton <peter.newton@nxp.com>; Stuart Yoder
> <stuart.yoder@nxp.com>; agraf at suse.de; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>
> Cc: u-boot at lists.denx.de
> Subject: Re: distro boot on ls2085ardb
>
> On 02/08/2017 03:08 PM, Peter Newton wrote:
> >> From: york sun
>
> <snip>
>
> >>
> >> It was for backward compatibility. Even I have pointed out numerous times
> (internally) that cp.b should not be used for this case, and
> >> even pointed out how to make a FIT image with load address, the board
> >> maintainer(s) didn't act. One change I can propose is to drop the "cp.b
> $kernel_start $kernel_load $kernel_size" and run "bootm
> >> $kernel_start"
> >> directly. If it fails, then falls to distro_bootcmd.
> >
> > I wondered why we needed the cp.b at all. How do you add the load address
> to fit?
> >
>
> FIT image header has load address and entry address. Our SDK didn't fill
> in load address before (not sure now). If the load address exists, the
> image(s) would be copied accordingly.
>
Our SDK provide load address for Kernel and device tree. But it don't provide load address for file system.
This means, "its" file should be updated to provide load address of filesystem also?
--prabhakar
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] distro boot on ls2085ardb
2017-02-09 2:43 ` Prabhakar Kushwaha
@ 2017-02-09 17:03 ` york sun
0 siblings, 0 replies; 6+ messages in thread
From: york sun @ 2017-02-09 17:03 UTC (permalink / raw)
To: u-boot
On 02/08/2017 06:43 PM, Prabhakar Kushwaha wrote:
>
>> -----Original Message-----
>> From: york sun
>> Sent: Thursday, February 09, 2017 4:43 AM
>> To: Peter Newton <peter.newton@nxp.com>; Stuart Yoder
>> <stuart.yoder@nxp.com>; agraf at suse.de; Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com>
>> Cc: u-boot at lists.denx.de
>> Subject: Re: distro boot on ls2085ardb
>>
>> On 02/08/2017 03:08 PM, Peter Newton wrote:
>>>> From: york sun
>>
>> <snip>
>>
>>>>
>>>> It was for backward compatibility. Even I have pointed out numerous times
>> (internally) that cp.b should not be used for this case, and
>>>> even pointed out how to make a FIT image with load address, the board
>>>> maintainer(s) didn't act. One change I can propose is to drop the "cp.b
>> $kernel_start $kernel_load $kernel_size" and run "bootm
>>>> $kernel_start"
>>>> directly. If it fails, then falls to distro_bootcmd.
>>>
>>> I wondered why we needed the cp.b at all. How do you add the load address
>> to fit?
>>>
>>
>> FIT image header has load address and entry address. Our SDK didn't fill
>> in load address before (not sure now). If the load address exists, the
>> image(s) would be copied accordingly.
>>
>
> Our SDK provide load address for Kernel and device tree. But it don?t provide load address for file system.
> This means, "its" file should be updated to provide load address of filesystem also?
>
I think so. I have verified this before and sent email to internal team.
There was an issue before concerning loading to high region. It was
fixed by commit c1913cb7897f77a26791765ef9c3c02b3588f3c1 in Feb 2016. We
have been using low region for kernel and ramdisk, so this bug didn't
block us.
Let's take this to internal team for further discussion.
York
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-09 17:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-08 22:55 [U-Boot] distro boot on ls2085ardb Stuart Yoder
2017-02-08 23:06 ` york sun
2017-02-08 23:08 ` Peter Newton
2017-02-08 23:12 ` york sun
2017-02-09 2:43 ` Prabhakar Kushwaha
2017-02-09 17:03 ` york sun
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.