| Message ID | CAOCHtYjD-v+XisPkDc2n9Rth73LqEuoB9070gBAKwcmxYQ-fLw@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Robert, On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com>wrote: > On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: > > Hey all, > > > > I've tagged and pushed v2013.07-rc2. A bit more over the place than I > > should have gone, but picked up a lot of things that have been > > outstanding for a while. The big thing is a refactor of the boot loop. > > Everything should be working right now, but please test. Related to > > this is the ability to have crytpographically signed images. It's like > > secure boot in UEFI land, but hopefully without the kerfuffle. > > > > If you've got changes outstanding still, please start gently poking > > custodians with patchwork links. I've got a good bit of stuff I need to > > deal with myself still, but please prod me all the same. > > So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) > also broke bootz/zImage... > > Got it to atleast get past the "invalid OS" message via: > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > index 02a5013..a0b55ef 100644 > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int > flag, int argc, > int ret; > void *zi_start, *zi_end; > > + memset(images, 0, sizeof(bootm_headers_t)); > + > + boot_start_lmb(images); > + > + images->os.os = IH_OS_LINUX; > + > ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, > images, 1); > > However it's still locking up at "Starting Kernel ..." > What board is this please? I have only tested on x86, but perhaps have missed something here. Regards, Simon
Hi, On 07/01/2013 10:44 PM, Robert Nelson wrote: > On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >> Hey all, >> >> I've tagged and pushed v2013.07-rc2. A bit more over the place than I >> should have gone, but picked up a lot of things that have been >> outstanding for a while. The big thing is a refactor of the boot loop. >> Everything should be working right now, but please test. Related to >> this is the ability to have crytpographically signed images. It's like >> secure boot in UEFI land, but hopefully without the kerfuffle. >> >> If you've got changes outstanding still, please start gently poking >> custodians with patchwork links. I've got a good bit of stuff I need to >> deal with myself still, but please prod me all the same. > > So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) > also broke bootz/zImage... and also bootm for uImage on avr32 ... will investigate it these days. Best regards Andreas Bießmann
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Robert, > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com> > wrote: >> >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >> > Hey all, >> > >> > I've tagged and pushed v2013.07-rc2. A bit more over the place than I >> > should have gone, but picked up a lot of things that have been >> > outstanding for a while. The big thing is a refactor of the boot loop. >> > Everything should be working right now, but please test. Related to >> > this is the ability to have crytpographically signed images. It's like >> > secure boot in UEFI land, but hopefully without the kerfuffle. >> > >> > If you've got changes outstanding still, please start gently poking >> > custodians with patchwork links. I've got a good bit of stuff I need to >> > deal with myself still, but please prod me all the same. >> >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) >> also broke bootz/zImage... >> >> Got it to atleast get past the "invalid OS" message via: >> >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c >> index 02a5013..a0b55ef 100644 >> --- a/common/cmd_bootm.c >> +++ b/common/cmd_bootm.c >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int >> flag, int argc, >> int ret; >> void *zi_start, *zi_end; >> >> + memset(images, 0, sizeof(bootm_headers_t)); >> + >> + boot_start_lmb(images); >> + >> + images->os.os = IH_OS_LINUX; >> + >> ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, >> images, 1); >> >> However it's still locking up at "Starting Kernel ..." > > > What board is this please? I have only tested on x86, but perhaps have > missed something here. So far it looks like any arm board... I was working on specifically the imx6 quad core wandboard bringup. But i've also verified it on the Panda/Beagle too... Alll 3 of these boards worked fine with v2013.07-rc1... Wandboard: Boot Sequence: (device tree boot) load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} bootz ${loadaddr} - ${fdt_addr} U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage 4112496 bytes read in 307 ms (12.8 MiB/s) => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} 22150 bytes read in 126 ms (170.9 KiB/s) => bootz ${loadaddr} - ${fdt_addr} Beagle xM: Boot Sequence: (old board file boot) fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage bootz ${loadaddr} OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage reading zImage 3421392 bytes read in 246 ms (13.3 MiB/s) OMAP3 beagleboard.org # bootz ${loadaddr} data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [<9ff8bf20>] lr : [<9ff5d2a8>] sp : 9fef8bd8 ip : 9ffffff8 fp : 9fef9760 r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30 r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6 r3 : 00020e61 r2 : 003434d0 r1 : 80200000 r0 : 9fef8cf0 Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53) Regards,
On Tue, Jul 2, 2013 at 6:41 AM, Robert Nelson <robertcnelson@gmail.com> wrote: > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Robert, >> >> On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com> >> wrote: >>> >>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >>> > Hey all, >>> > >>> > I've tagged and pushed v2013.07-rc2. A bit more over the place than I >>> > should have gone, but picked up a lot of things that have been >>> > outstanding for a while. The big thing is a refactor of the boot loop. >>> > Everything should be working right now, but please test. Related to >>> > this is the ability to have crytpographically signed images. It's like >>> > secure boot in UEFI land, but hopefully without the kerfuffle. >>> > >>> > If you've got changes outstanding still, please start gently poking >>> > custodians with patchwork links. I've got a good bit of stuff I need to >>> > deal with myself still, but please prod me all the same. >>> >>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) >>> also broke bootz/zImage... >>> >>> Got it to atleast get past the "invalid OS" message via: >>> >>> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c >>> index 02a5013..a0b55ef 100644 >>> --- a/common/cmd_bootm.c >>> +++ b/common/cmd_bootm.c >>> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int >>> flag, int argc, >>> int ret; >>> void *zi_start, *zi_end; >>> >>> + memset(images, 0, sizeof(bootm_headers_t)); >>> + >>> + boot_start_lmb(images); >>> + >>> + images->os.os = IH_OS_LINUX; >>> + >>> ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, >>> images, 1); >>> >>> However it's still locking up at "Starting Kernel ..." >> >> >> What board is this please? I have only tested on x86, but perhaps have >> missed something here. > > So far it looks like any arm board... I was working on specifically > the imx6 quad core wandboard bringup. But i've also verified it on > the Panda/Beagle too... Alll 3 of these boards worked fine with > v2013.07-rc1... > > Wandboard: > > Boot Sequence: (device tree boot) > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > bootz ${loadaddr} - ${fdt_addr} > > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: FEC [PRIME] > Warning: FEC using MAC address from net device > > Hit any key to stop autoboot: 0 > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > 4112496 bytes read in 307 ms (12.8 MiB/s) > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > 22150 bytes read in 126 ms (170.9 KiB/s) > => bootz ${loadaddr} - ${fdt_addr} <hardlock> Missed the important detail... Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2013 06:37 AM, Andreas Bießmann wrote: > Hi, > > On 07/01/2013 10:44 PM, Robert Nelson wrote: >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >>> Hey all, >>> >>> I've tagged and pushed v2013.07-rc2. A bit more over the place >>> than I should have gone, but picked up a lot of things that >>> have been outstanding for a while. The big thing is a refactor >>> of the boot loop. Everything should be working right now, but >>> please test. Related to this is the ability to have >>> crytpographically signed images. It's like secure boot in UEFI >>> land, but hopefully without the kerfuffle. >>> >>> If you've got changes outstanding still, please start gently >>> poking custodians with patchwork links. I've got a good bit of >>> stuff I need to deal with myself still, but please prod me all >>> the same. >> >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 >> ) also broke bootz/zImage... > > and also bootm for uImage on avr32 ... will investigate it these > days. Hurk, I hope avr32 is the same problem Stefan found/fixed with PowerPC, can you check / test that quickly? See last patch to arch/powerpc/lib/bootm.c. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0sjcAAoJENk4IS6UOR1WfBkQAIXXb3O7/yAYv7hQ/YvcfZej scftgdsmt0kCsAEsCx7Prmae2c5+0HKUADPNRSp6IVuU1aZNCbauT1o0mqDT2ieb JaYDwLaMq5gozZ4HMnc5LyAWDFc6Kh1qqpUV+2hWlRy2ZLjWJ8/f4tEPJQ9ULVs0 t3TO+tpHPKYgg+vgpNePhQxuvphlP8NKpG7eVSuy7atkqWElAzekOtwTAtYFcIGv h0XrAiPnv3WXHGMXfXLA5ABS+71HBOOtewAaSwG0QZ0h55pCRMc/GQ7WxSB2T03C aNV25eCTH0i+LQjvL/8rriE8805yxD04klu//t/520z2ySCDy3DgpwAqnxuXW6+V knATFhWyAsJjNJ2AKgrE+W2ffFcqoVGf+pZW3Da4StoCjHDaCCtp3DFMeqZ8g92I ef+qd96nlYjO+okUf6+4wXgFz1KE5O78NgWLxvaOZ8E55b4hHUMnv0kiEnYpB9OD pK6imnN/0w27Gakzp88kQVQnuu8yps/la/htqyXQMxdSa26OZm1iDFRqRuv2kQbP 8SnW4iVp7QEZZ408pbvMgnfIy/ACnqbxRF5dEm/2gvGZ6bPcJsIjv1BTyal9LYhI qT7flTJGKcgHiVw4/ZszA2tA9zmSpgDN/T7uZp1KpmtIqXfZAgpeJTSwMdkF00z1 sOt9L3YLlzz1/OcDbh5P =dySs -----END PGP SIGNATURE-----
On 07/02/2013 02:34 PM, Tom Rini wrote: > On 07/02/2013 06:37 AM, Andreas Bießmann wrote: >> Hi, > >> On 07/01/2013 10:44 PM, Robert Nelson wrote: >>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >>>> Hey all, >>>> >>>> I've tagged and pushed v2013.07-rc2. A bit more over the place >>>> than I should have gone, but picked up a lot of things that >>>> have been outstanding for a while. The big thing is a refactor >>>> of the boot loop. Everything should be working right now, but >>>> please test. Related to this is the ability to have >>>> crytpographically signed images. It's like secure boot in UEFI >>>> land, but hopefully without the kerfuffle. >>>> >>>> If you've got changes outstanding still, please start gently >>>> poking custodians with patchwork links. I've got a good bit of >>>> stuff I need to deal with myself still, but please prod me all >>>> the same. >>> >>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 >>> ) also broke bootz/zImage... > >> and also bootm for uImage on avr32 ... will investigate it these >> days. > > Hurk, I hope avr32 is the same problem Stefan found/fixed with > PowerPC, can you check / test that quickly? See last patch to > arch/powerpc/lib/bootm.c. got it: http://patchwork.ozlabs.org/patch/256393/ Let it settle some days, would you pick it directly or do you prefer a PR? Best regards Andreas Bießmann
Hi Robert, On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote: > > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: > > Hi Robert, > > > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com> > > wrote: > >> > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: > >> > Hey all, > >> > > >> > I've tagged and pushed v2013.07-rc2. A bit more over the place than I > >> > should have gone, but picked up a lot of things that have been > >> > outstanding for a while. The big thing is a refactor of the boot loop. > >> > Everything should be working right now, but please test. Related to > >> > this is the ability to have crytpographically signed images. It's like > >> > secure boot in UEFI land, but hopefully without the kerfuffle. > >> > > >> > If you've got changes outstanding still, please start gently poking > >> > custodians with patchwork links. I've got a good bit of stuff I need to > >> > deal with myself still, but please prod me all the same. > >> > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) > >> also broke bootz/zImage... > >> > >> Got it to atleast get past the "invalid OS" message via: > >> > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > >> index 02a5013..a0b55ef 100644 > >> --- a/common/cmd_bootm.c > >> +++ b/common/cmd_bootm.c > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int > >> flag, int argc, > >> int ret; > >> void *zi_start, *zi_end; > >> > >> + memset(images, 0, sizeof(bootm_headers_t)); > >> + > >> + boot_start_lmb(images); > >> + > >> + images->os.os = IH_OS_LINUX; > >> + > >> ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, > >> images, 1); > >> > >> However it's still locking up at "Starting Kernel ..." > > > > > > What board is this please? I have only tested on x86, but perhaps have > > missed something here. > > So far it looks like any arm board... I was working on specifically > the imx6 quad core wandboard bringup. But i've also verified it on > the Panda/Beagle too... Alll 3 of these boards worked fine with > v2013.07-rc1... > > Wandboard: > > Boot Sequence: (device tree boot) > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > bootz ${loadaddr} - ${fdt_addr} > > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: FEC [PRIME] > Warning: FEC using MAC address from net device > > Hit any key to stop autoboot: 0 > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > 4112496 bytes read in 307 ms (12.8 MiB/s) > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > 22150 bytes read in 126 ms (170.9 KiB/s) > => bootz ${loadaddr} - ${fdt_addr} > > Beagle xM: > > Boot Sequence: (old board file boot) > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > bootz ${loadaddr} > > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > reading zImage > 3421392 bytes read in 246 ms (13.3 MiB/s) > OMAP3 beagleboard.org # bootz ${loadaddr} > data abort > > MAYBE you should read doc/README.arm-unaligned-accesses > > pc : [<9ff8bf20>] lr : [<9ff5d2a8>] > sp : 9fef8bd8 ip : 9ffffff8 fp : 9fef9760 > r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30 > r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6 > r3 : 00020e61 r2 : 003434d0 r1 : 80200000 r0 : 9fef8cf0 > Flags: nzcv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > resetting ... > > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53) Thanks for the details. I will take a look later today US time. Regards, Simon > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/
Hi Robert. On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Robert, > > On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote: > > > > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: > > > Hi Robert, > > > > > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com > > > > > wrote: > > >> > > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: > > >> > Hey all, > > >> > > > >> > I've tagged and pushed v2013.07-rc2. A bit more over the place > than I > > >> > should have gone, but picked up a lot of things that have been > > >> > outstanding for a while. The big thing is a refactor of the boot > loop. > > >> > Everything should be working right now, but please test. Related to > > >> > this is the ability to have crytpographically signed images. It's > like > > >> > secure boot in UEFI land, but hopefully without the kerfuffle. > > >> > > > >> > If you've got changes outstanding still, please start gently poking > > >> > custodians with patchwork links. I've got a good bit of stuff I > need to > > >> > deal with myself still, but please prod me all the same. > > >> > > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) > > >> also broke bootz/zImage... > > >> > > >> Got it to atleast get past the "invalid OS" message via: > > >> > > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > > >> index 02a5013..a0b55ef 100644 > > >> --- a/common/cmd_bootm.c > > >> +++ b/common/cmd_bootm.c > > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int > > >> flag, int argc, > > >> int ret; > > >> void *zi_start, *zi_end; > > >> > > >> + memset(images, 0, sizeof(bootm_headers_t)); > > >> + > > >> + boot_start_lmb(images); > > >> + > > >> + images->os.os = IH_OS_LINUX; > > >> + > > >> ret = do_bootm_states(cmdtp, flag, argc, argv, > BOOTM_STATE_START, > > >> images, 1); > > >> > > >> However it's still locking up at "Starting Kernel ..." > > > > > > > > > What board is this please? I have only tested on x86, but perhaps have > > > missed something here. > > > > So far it looks like any arm board... I was working on specifically > > the imx6 quad core wandboard bringup. But i've also verified it on > > the Panda/Beagle too... Alll 3 of these boards worked fine with > > v2013.07-rc1... > > > > Wandboard: > > > > Boot Sequence: (device tree boot) > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > > bootz ${loadaddr} - ${fdt_addr} > > > > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > Reset cause: POR > > Board: Wandboard > > DRAM: 2 GiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > Err: serial > > Net: FEC [PRIME] > > Warning: FEC using MAC address from net device > > > > Hit any key to stop autoboot: 0 > > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > 4112496 bytes read in 307 ms (12.8 MiB/s) > > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > > 22150 bytes read in 126 ms (170.9 KiB/s) > > => bootz ${loadaddr} - ${fdt_addr} > > > > Beagle xM: > > > > Boot Sequence: (old board file boot) > > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > bootz ${loadaddr} > > > > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} > zImage > > reading zImage > > 3421392 bytes read in 246 ms (13.3 MiB/s) > > OMAP3 beagleboard.org # bootz ${loadaddr} > > data abort > > > > MAYBE you should read doc/README.arm-unaligned-accesses > > > > pc : [<9ff8bf20>] lr : [<9ff5d2a8>] > > sp : 9fef8bd8 ip : 9ffffff8 fp : 9fef9760 > > r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30 > > r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6 > > r3 : 00020e61 r2 : 003434d0 r1 : 80200000 r0 : 9fef8cf0 > > Flags: nzcv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > > > > resetting ... > > > > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53) > > Thanks for the details. I will take a look later today US time. > Unfortunately due to my current location I don't have access to a good ARM bootz target. I believe I have found a problem, and will send out some patches for you to try/debug, although with tidying up a few things. However until I can test them (several days) they are for interest only. Regards, Simon
On Wed, Jul 03, 2013 at 10:52:18PM +0900, Simon Glass wrote: > Hi Robert. > > On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote: > > > Hi Robert, > > > > On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote: > > > > > > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Robert, > > > > > > > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com > > > > > > > wrote: > > > >> > > > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: > > > >> > Hey all, > > > >> > > > > >> > I've tagged and pushed v2013.07-rc2. A bit more over the place > > than I > > > >> > should have gone, but picked up a lot of things that have been > > > >> > outstanding for a while. The big thing is a refactor of the boot > > loop. > > > >> > Everything should be working right now, but please test. Related to > > > >> > this is the ability to have crytpographically signed images. It's > > like > > > >> > secure boot in UEFI land, but hopefully without the kerfuffle. > > > >> > > > > >> > If you've got changes outstanding still, please start gently poking > > > >> > custodians with patchwork links. I've got a good bit of stuff I > > need to > > > >> > deal with myself still, but please prod me all the same. > > > >> > > > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) > > > >> also broke bootz/zImage... > > > >> > > > >> Got it to atleast get past the "invalid OS" message via: > > > >> > > > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > > > >> index 02a5013..a0b55ef 100644 > > > >> --- a/common/cmd_bootm.c > > > >> +++ b/common/cmd_bootm.c > > > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int > > > >> flag, int argc, > > > >> int ret; > > > >> void *zi_start, *zi_end; > > > >> > > > >> + memset(images, 0, sizeof(bootm_headers_t)); > > > >> + > > > >> + boot_start_lmb(images); > > > >> + > > > >> + images->os.os = IH_OS_LINUX; > > > >> + > > > >> ret = do_bootm_states(cmdtp, flag, argc, argv, > > BOOTM_STATE_START, > > > >> images, 1); > > > >> > > > >> However it's still locking up at "Starting Kernel ..." > > > > > > > > > > > > What board is this please? I have only tested on x86, but perhaps have > > > > missed something here. > > > > > > So far it looks like any arm board... I was working on specifically > > > the imx6 quad core wandboard bringup. But i've also verified it on > > > the Panda/Beagle too... Alll 3 of these boards worked fine with > > > v2013.07-rc1... > > > > > > Wandboard: > > > > > > Boot Sequence: (device tree boot) > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > > > bootz ${loadaddr} - ${fdt_addr} > > > > > > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) > > > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > > Reset cause: POR > > > Board: Wandboard > > > DRAM: 2 GiB > > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > > *** Warning - bad CRC, using default environment > > > > > > In: serial > > > Out: serial > > > Err: serial > > > Net: FEC [PRIME] > > > Warning: FEC using MAC address from net device > > > > > > Hit any key to stop autoboot: 0 > > > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > > 4112496 bytes read in 307 ms (12.8 MiB/s) > > > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} > > > 22150 bytes read in 126 ms (170.9 KiB/s) > > > => bootz ${loadaddr} - ${fdt_addr} > > > > > > Beagle xM: > > > > > > Boot Sequence: (old board file boot) > > > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage > > > bootz ${loadaddr} > > > > > > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} > > zImage > > > reading zImage > > > 3421392 bytes read in 246 ms (13.3 MiB/s) > > > OMAP3 beagleboard.org # bootz ${loadaddr} > > > data abort > > > > > > MAYBE you should read doc/README.arm-unaligned-accesses > > > > > > pc : [<9ff8bf20>] lr : [<9ff5d2a8>] > > > sp : 9fef8bd8 ip : 9ffffff8 fp : 9fef9760 > > > r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30 > > > r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6 > > > r3 : 00020e61 r2 : 003434d0 r1 : 80200000 r0 : 9fef8cf0 > > > Flags: nzcv IRQs off FIQs off Mode SVC_32 > > > Resetting CPU ... > > > > > > resetting ... > > > > > > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53) > > > > Thanks for the details. I will take a look later today US time. > > Unfortunately due to my current location I don't have access to a good ARM > bootz target. I believe I have found a problem, and will send out some > patches for you to try/debug, although with tidying up a few things. > > However until I can test them (several days) they are for interest only. Please post them ASAP, I'll see about picking them up and testing them as well. And if needed, I can get a Beaglebone of some color thrown your way for future ease of testing bootz :)
On Wed, Jul 3, 2013 at 8:52 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Robert. > > On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote: >> >> Hi Robert, >> >> On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote: >> > >> > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote: >> > > Hi Robert, >> > > >> > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson >> > > <robertcnelson@gmail.com> >> > > wrote: >> > >> >> > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote: >> > >> > Hey all, >> > >> > >> > >> > I've tagged and pushed v2013.07-rc2. A bit more over the place >> > >> > than I >> > >> > should have gone, but picked up a lot of things that have been >> > >> > outstanding for a while. The big thing is a refactor of the boot >> > >> > loop. >> > >> > Everything should be working right now, but please test. Related >> > >> > to >> > >> > this is the ability to have crytpographically signed images. It's >> > >> > like >> > >> > secure boot in UEFI land, but hopefully without the kerfuffle. >> > >> > >> > >> > If you've got changes outstanding still, please start gently poking >> > >> > custodians with patchwork links. I've got a good bit of stuff I >> > >> > need to >> > >> > deal with myself still, but please prod me all the same. >> > >> >> > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) >> > >> also broke bootz/zImage... >> > >> >> > >> Got it to atleast get past the "invalid OS" message via: >> > >> >> > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c >> > >> index 02a5013..a0b55ef 100644 >> > >> --- a/common/cmd_bootm.c >> > >> +++ b/common/cmd_bootm.c >> > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int >> > >> flag, int argc, >> > >> int ret; >> > >> void *zi_start, *zi_end; >> > >> >> > >> + memset(images, 0, sizeof(bootm_headers_t)); >> > >> + >> > >> + boot_start_lmb(images); >> > >> + >> > >> + images->os.os = IH_OS_LINUX; >> > >> + >> > >> ret = do_bootm_states(cmdtp, flag, argc, argv, >> > >> BOOTM_STATE_START, >> > >> images, 1); >> > >> >> > >> However it's still locking up at "Starting Kernel ..." >> > > >> > > >> > > What board is this please? I have only tested on x86, but perhaps have >> > > missed something here. >> > >> > So far it looks like any arm board... I was working on specifically >> > the imx6 quad core wandboard bringup. But i've also verified it on >> > the Panda/Beagle too... Alll 3 of these boards worked fine with >> > v2013.07-rc1... >> > >> > Wandboard: >> > >> > Boot Sequence: (device tree boot) >> > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage >> > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} >> > bootz ${loadaddr} - ${fdt_addr} >> > >> > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59) >> > >> > CPU: Freescale i.MX6Q rev1.2 at 792 MHz >> > Reset cause: POR >> > Board: Wandboard >> > DRAM: 2 GiB >> > MMC: FSL_SDHC: 0, FSL_SDHC: 1 >> > *** Warning - bad CRC, using default environment >> > >> > In: serial >> > Out: serial >> > Err: serial >> > Net: FEC [PRIME] >> > Warning: FEC using MAC address from net device >> > >> > Hit any key to stop autoboot: 0 >> > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage >> > 4112496 bytes read in 307 ms (12.8 MiB/s) >> > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} >> > 22150 bytes read in 126 ms (170.9 KiB/s) >> > => bootz ${loadaddr} - ${fdt_addr} >> > >> > Beagle xM: >> > >> > Boot Sequence: (old board file boot) >> > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage >> > bootz ${loadaddr} >> > >> > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} >> > zImage >> > reading zImage >> > 3421392 bytes read in 246 ms (13.3 MiB/s) >> > OMAP3 beagleboard.org # bootz ${loadaddr} >> > data abort >> > >> > MAYBE you should read doc/README.arm-unaligned-accesses >> > >> > pc : [<9ff8bf20>] lr : [<9ff5d2a8>] >> > sp : 9fef8bd8 ip : 9ffffff8 fp : 9fef9760 >> > r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30 >> > r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6 >> > r3 : 00020e61 r2 : 003434d0 r1 : 80200000 r0 : 9fef8cf0 >> > Flags: nzcv IRQs off FIQs off Mode SVC_32 >> > Resetting CPU ... >> > >> > resetting ... >> > >> > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53) >> >> Thanks for the details. I will take a look later today US time. > > Unfortunately due to my current location I don't have access to a good ARM > bootz target. I believe I have found a problem, and will send out some > patches for you to try/debug, although with tidying up a few things. > > However until I can test them (several days) they are for interest only. Sure, no problem... Other then a long drive tonight, I'll have net access over the 4th.. It's just 'too' easy to pack a beaglebone black where ever i go. ;) Regards,
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 02a5013..a0b55ef 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc, int ret; void *zi_start, *zi_end; + memset(images, 0, sizeof(bootm_headers_t)); + + boot_start_lmb(images); + + images->os.os = IH_OS_LINUX; + ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, images, 1);