[U-Boot] distro boot on ls2085ardb
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
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_bootcmdWas 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_loadThoughts?
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
From: york sun Sent: Wednesday, February 08, 2017 5:06 PM To: Stuart Yoder stuart.yoder@nxp.com; agraf@suse.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com Cc: Peter Newton peter.newton@nxp.com; u-boot@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_bootcmdWas 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_loadThoughts?
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?
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
-----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@suse.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com Cc: u-boot@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
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@suse.de; Prabhakar Kushwaha prabhakar.kushwaha@nxp.com Cc: u-boot@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
participants (4)
-
Peter Newton -
Prabhakar Kushwaha -
Stuart Yoder -
york sun