bootm: Disable interrupts only when loading
PATCH v2 2/5 bootm: Disable interrupts only when loading
With the move of the interrupt code to earlier in the sequence, we exposed a problem where the interrupts are disabled at each bootm stage. This is not correct - it should be done only once. Let's disable interrupts in the LOAD stage. Put the code in a function for clarity.
Also, bootz lost its interrupt code altogether, so reinstate it.
---
Changes in v2: None
common/cmd_bootm.c | 67 +++++++++++++++++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 24 deletions(-)
common/cmd_bootm.c +43 -24
@@ -539,6 +539,42 @@ static int boot_selected_os(int argc, char * const argv[], int state, }/** +* bootm_disable_interrupts() - Disable interrupts in preparation for load/boot +* +* @return interrupt flag (0 if interrupts were disabled, non-zero if they were +* enabled) +*/ +static ulong bootm_disable_interrupts (void ) +{ +ulong iflag; + +/* +* We have reached the point of no return: we are going to +* overwrite all exception vector code, so we cannot easily +* recover from any failures any more... +*/ + iflag =disable_interrupts (); +#ifdef CONFIG_NETCONSOLE +/* Stop the ethernet stack if NetConsole could have left it up */ +eth_halt (); +#endif + +#if defined(CONFIG_CMD_USB ) +/* +* turn off USB to prevent the host controller from writing to the +* SDRAM while Linux is booting. This could happen (at least for OHCI +* controller), because the HCCA (Host Controller Communication Area) +* lies within the SDRAM and the host controller writes continously to +* this area (as busmaster!). The HccaFrameNumber is for example +* updated every 1 ms within the HCCA structure in SDRAM! For more +* details see the OpenHCI specification. +*/ +usb_stop (); +#endif +return iflag; +} + +/** * Execute selected states of the bootm command. * * Note the arguments to this state must be the first argument, Any 'bootm'
@@ -588,34 +624,11 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, argc =0 ;/* consume the args */ } -/* -* We have reached the point of no return: we are going to -* overwrite all exception vector code, so we cannot easily -* recover from any failures any more... -*/ - iflag =disable_interrupts (); -#ifdef CONFIG_NETCONSOLE -/* Stop the ethernet stack if NetConsole could have left it up */ -eth_halt (); -#endif - -#if defined(CONFIG_CMD_USB ) -/* -* turn off USB to prevent the host controller from writing to the -* SDRAM while Linux is booting. This could happen (at least for OHCI -* controller), because the HCCA (Host Controller Communication Area) -* lies within the SDRAM and the host controller writes continously to -* this area (as busmaster!). The HccaFrameNumber is for example -* updated every 1 ms within the HCCA structure in SDRAM! For more -* details see the OpenHCI specification. -*/ -usb_stop (); -#endif -/* Load the OS */ if (!ret && (states &BOOTM_STATE_LOADOS )) {ulong load_end; + iflag =bootm_disable_interrupts (); ret =bootm_load_os (images, &load_end,0 );if (ret && ret !=BOOTM_ERR_OVERLAP ) goto err;
@@ -1774,6 +1787,12 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])if (bootz_start (cmdtp, flag, argc, argv, &images))return 1 ; +/* +* We are doing the BOOTM_STATE_LOADOS state ourselves, so must +* disable interrupts ourselves +*/ +bootm_disable_interrupts (); + ret =do_bootm_states (cmdtp, flag, argc, argv,BOOTM_STATE_OS_FAKE_GO |BOOTM_STATE_OS_GO , &images,1 );
Signature · 1 line
1.8.3
PATCH v2 3/5 bootm: Require boot function only if it is about to be used
The original bootm code (before commit 35fc84f) did not check for a valid boot function in the subcommand case, which was incorrect.
This check was introduced in all cases, but in fact we should only check for the function when we need it. Otherwise in some cases the check fires before the OS type is known.
---
Changes in v2:
- Add new patch to limit checking of rboot function validity
common/cmd_bootm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
common/cmd_bootm.c +5 -2
@@ -605,7 +605,7 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, {boot_os_fn *boot_fn;ulong iflag =0 ; -int ret =0 ; +int ret =0 , need_boot_fn; images->state |= states;
@@ -665,7 +665,10 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc,if (ret)return ret; boot_fn = boot_os[images->os.os]; -if (boot_fn ==NULL ) { + need_boot_fn = states & (BOOTM_STATE_OS_CMDLINE | +BOOTM_STATE_OS_BD_T |BOOTM_STATE_OS_PREP | +BOOTM_STATE_OS_FAKE_GO |BOOTM_STATE_OS_GO ); +if (boot_fn ==NULL && need_boot_fn) {if (iflag)enable_interrupts (); printf("ERROR: booting os '%s' (%d) is not supported\n",
Signature · 1 line
1.8.3
PATCH v2 4/5 bootm: Clean up bootz_setup() function
In reply to Simon GlassThis function has no prototype in the headers and passes void * around, thus requiring several casts. Tidy this up.
- Add new patch to clean up bootz_setup() function
---
Changes in v2: None
arch/arm/lib/bootm.c | 14 ++++++++------ common/cmd_bootm.c | 8 +++----- include/image.h | 11 +++++++++++ 3 files changed, 22 insertions(+), 11 deletions(-)
arch/arm/lib/bootm.c +8 -6
@@ -300,21 +300,23 @@ struct zimage_header {#define LINUX_ARM_ZIMAGE_MAGIC 0x016f2818 -int bootz_setup (void *image,void **start,void **end) +int bootz_setup (ulong image,ulong *start,ulong *end) { -struct zimage_header *zi = (struct zimage_header *)image; +struct zimage_header *zi; + zi = (struct zimage_header *)map_sysmem (image,0 );if (zi->zi_magic !=LINUX_ARM_ZIMAGE_MAGIC ) {puts ("Bad Linux ARM zImage magic!\n" );return 1 ; } - *start = (void *)zi->zi_start; - *end = (void *)zi->zi_end; + *start = zi->zi_start; + *end = zi->zi_end; -debug ("Kernel image @ 0x%08x [ 0x%08x - 0x%08x ]\n" , - (uint32_t )image, (uint32_t )*start, (uint32_t )*end); +printf ("Kernel image @ %#08lx [ %#08lx - %#08lx ]\n" , image, *start, + *end);return 0 ; } +#endif /* CONFIG_CMD_BOOTZ */
common/cmd_bootm.c +3 -5
@@ -1737,15 +1737,13 @@ static int do_bootm_integrity(int flag, int argc, char * const argv[],#ifdef CONFIG_CMD_BOOTZ -static int __bootz_setup (void *image,void **start,void **end) +int __weak bootz_setup (ulong image,ulong *start,ulong *end) {/* Please define bootz_setup() for your platform */ puts ("Your platform's zImage format isn't supported yet!\n" );return -1 ; } -int bootz_setup (void *image,void **start,void **end) - __attribute__((weak,alias ("__bootz_setup" )));/* * zImage booting support
@@ -1754,7 +1752,7 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[], bootm_headers_t *images) { int ret; -void *zi_start, *zi_end; +ulong zi_start, zi_end; ret =do_bootm_states (cmdtp, flag, argc, argv,BOOTM_STATE_START , images,1 );
@@ -1770,7 +1768,7 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc, images->ep); } - ret =bootz_setup ((void *)images->ep, &zi_start, &zi_end); + ret =bootz_setup (images->ep, &zi_start, &zi_end);if (ret !=0 )return 1 ;
include/image.h +11 -0
@@ -662,6 +662,17 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,*/ int image_setup_linux (bootm_headers_t *images); +/** +* bootz_setup() - Extract stat and size of a Linux xImage +* +* @image: Address of image +* @start: Returns start address of image +* @end : Returns end address of image +* @return 0 if OK, 1 if the image was not recognised +*/ +int bootz_setup (ulong image,ulong *start,ulong *end); + +/*******************************************************************/ /* New uImage format specific code (prefixed with fit_) */ /*******************************************************************/
Signature · 1 line
1.8.3
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Simon GlassIn the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c does not in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
---
Changes in v2:
- Remove local images variable
- Set OS type to Linux in all cases
common/cmd_bootm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
common/cmd_bootm.c +3 -2
@@ -1782,7 +1782,6 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc,int do_bootz (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) { -bootm_headers_t images;int ret;if (bootz_start (cmdtp, flag, argc, argv, &images))
@@ -1794,8 +1793,10 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])*/ bootm_disable_interrupts (); + images.os.os =IH_OS_LINUX ; ret =do_bootm_states (cmdtp, flag, argc, argv, -BOOTM_STATE_OS_FAKE_GO |BOOTM_STATE_OS_GO , +BOOTM_STATE_OS_PREP |BOOTM_STATE_OS_FAKE_GO | +BOOTM_STATE_OS_GO , &images,1 );return ret;
Signature · 1 line
1.8.3
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 10 lines · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not in fact use the same image structure, so remove this.Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>
With the whole series applied, I still see a hang at:
Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but 0x80000000 -> 256MiB ?
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130708/e29aa3d0/attachment.pgp>
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 12 lines · Tom Rini
Quoted 10 lines · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not in fact use the same image structure, so remove this.Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>
Quoted 7 lines
With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage reading zImage
3413152 bytes read in 161 ms (20.2 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Kernel image @ 0x82000000 [ 0x000000 - 0x3414a0 ]
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu
Wandboard (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} run mmcargs
bootz ${loadaddr} - ${fdt_addr}
Hit any key to stop autoboot: 0
=> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage 3464448 bytes read in 249 ms (13.3 MiB/s)
=> load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} 23571 bytes read in 253 ms (90.8 KiB/s)
=> run mmcargs
=> bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x12000000 [ 0x000000 - 0x34dd00 ]
Starting kernel ...
<lockup>
Regards,
Signature · 2 lines
Robert Nelson http://www.rcn-ee.com/
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 24 lines · Robert Nelson
Quoted 12 lines · Tom Rini
Quoted 10 lines · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not in fact use the same image structure, so remove this.Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>Quoted 7 lines
With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?Tom, which board is that?
Quoted 8 lines
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130708/9ce80e86/attachment.pgp>
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 29 lines · Tom Rini
Quoted 27 lines · Robert Nelson
Quoted 12 lines · Tom Rini
Quoted 10 lines · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not in fact use the same image structure, so remove this.Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>Quoted 7 lines
With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Quoted 8 lines
Quoted 5 lines
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet. Simon, do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130709/875d501e/attachment.pgp>
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
Quoted 39 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
Quoted 24 lines
Quoted 23 lines
Quoted 11 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Quoted 10 lines
Quoted 2 lines
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet. Simon, do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be able to try bootz with appeneded dtb on another ARM board.
Regards,
Simon
Quoted 3 lines
--
Tom
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 53 lines · Simon Glass
Hi Tom,
Quoted 39 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
Quoted 24 lines
Quoted 23 lines
Quoted 11 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Quoted 10 lines
Quoted 2 lines
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet. Simon, do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Quoted 8 lines
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be able to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that BOOTM_STATE_FINDOTHER would never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130709/466b7c17/attachment.pgp>
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
Quoted 65 lines · Tom Rini
Quoted 29 lines · Simon Glass
Hi Tom,
Quoted 25 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiBbut
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with
separate.
Quoted 4 lines
Quoted 4 lines
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet.Simon,
Quoted 11 lines
Quoted 4 lines
do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be
Quoted 9 lines
able
Quoted 1 line
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that
BOOTM_STATE_FINDOTHERwould never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.
OK great, thanks for looking at this. I wonder if we can collect a set of different use cases for bootz as a basis for test cases?
Quoted 4 lines
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write some sandbox tests for the other image types today and post my results. I guess this bootm code has built up over a long time and it is hard to know all the ways it is used.
Regards,
Simon
Quoted 3 lines
--
Tom
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 79 lines · Simon Glass
Hi Tom,
Quoted 65 lines · Tom Rini
Quoted 29 lines · Simon Glass
Hi Tom,
Quoted 25 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiBbut
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with
separate.
Quoted 4 lines
Quoted 4 lines
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet.Simon,
Quoted 11 lines
Quoted 4 lines
do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be
Quoted 8 lines
able
Quoted 1 line
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that
BOOTM_STATE_FINDOTHERwould never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.
Quoted 2 lines
OK great, thanks for looking at this. I wonder if we can collect a set of different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
Quoted 7 lines
Quoted 2 lines
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write some sandbox tests for the other image types today and post my results. I guess this bootm code has built up over a long time and it is hard to know all the ways it is used.
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130709/82dc8e41/attachment.pgp>
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 90 lines · Tom Rini
Quoted 79 lines · Simon Glass
Hi Tom,
Quoted 65 lines · Tom Rini
Quoted 29 lines · Simon Glass
Hi Tom,
Quoted 25 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cdoes not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiBbut
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with
separate.
Quoted 4 lines
Quoted 4 lines
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet.Simon,
Quoted 11 lines
Quoted 4 lines
do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be
Quoted 8 lines
able
Quoted 1 line
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that
BOOTM_STATE_FINDOTHERwould never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.Quoted 2 lines
OK great, thanks for looking at this. I wonder if we can collect a set of different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.Quoted 3 lines
Quoted 2 lines
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Quoted 8 lines
Quoted 4 lines
Yes, I am not really comfortable with this. I will see if I can write some sandbox tests for the other image types today and post my results. I guess this bootm code has built up over a long time and it is hard to know all the ways it is used.
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
There 'seems' to be a pre-built freebsd arm port...
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
Regards,
Signature · 2 lines
Robert Nelson http://www.rcn-ee.com/
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Quoted 7 lines
Quoted 3 lines
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
There 'seems' to be a pre-built freebsd arm port...
NM.. they are using the 'bootelf' command..
Regards,
Signature · 2 lines
Robert Nelson http://www.rcn-ee.com/
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Tom RiniHi Tom,
Quoted 91 lines · Tom Rini
Quoted 15 lines · Simon Glass
Hi Tom,
Quoted 11 lines · Tom Rini
Quoted 10 lines · Simon Glass
Hi Tom,
Quoted 6 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in
the
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
does not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the
only
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
possibility
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0->256MiB
Quoted 9 lines
Quoted 9 lines
but
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
file) works, but Wand (device tree) is still locking up for
me...
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with
separate.
Quoted 2 lines
Quoted 2 lines
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since wedon't
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
have the rest of the header bits that the code checks for set.
I've
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
taken a few stabs at reworking things, but it's not working yet.
Simon,
Quoted 1 line
Quoted 1 line
do you have any ideas here? I'm starting to wonder if we don't
need to
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they
are
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as
we
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should
be
Quoted 10 lines
Quoted 8 lines
able
Quoted 1 line
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that
BOOTM_STATE_FINDOTHERwould never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.
Quoted 8 lines
Quoted 1 line
OK great, thanks for looking at this. I wonder if we can collect a set
of
Quoted 1 line
different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
Yes certainly there are limitations, but the test I have there so far does check that all the data appears in the correct place in memory. That seems to me most of the battle with bootm.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write
some
Quoted 9 lines
Quoted 1 line
sandbox tests for the other image types today and post my results. I
guess
Quoted 2 lines
this bootm code has built up over a long time and it is hard to know all the ways it is used.
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
Me neither, unfortunately.
Regards,
Simon
Quoted 4 lines
--
Tom
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Tom Rinihi Tom,
On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
<snip>
Quoted 8 lines
Quoted 4 lines
Yes, I am not really comfortable with this. I will see if I can write some sandbox tests for the other image types today and post my results. I guess this bootm code has built up over a long time and it is hard to know all the ways it is used.
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm. Need a day or two to check this out though.
-sughosh
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Hi Sughosh,
Quoted 14 lines · Sughosh Ganu
hi Tom,
On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
<snip>
Quoted 1 line
Quoted 1 line
Yes, I am not really comfortable with this. I will see if I can write
some
Quoted 1 line
Quoted 1 line
sandbox tests for the other image types today and post my results. I
guess
Quoted 1 line
Quoted 1 line
this bootm code has built up over a long time and it is hard to know
all
Quoted 2 lines
Quoted 1 line
the ways it is used.
Quoted 9 lines
Quoted 3 lines
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm. Need a day or two to check this out though.
Thanks, much appreciated.
Regards,
Simon
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Sughosh GanuQuoted 14 lines · Sughosh Ganu
hi Tom,
On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
<snip>
Quoted 1 line
Quoted 1 line
Yes, I am not really comfortable with this. I will see if I can write
some
Quoted 1 line
Quoted 1 line
sandbox tests for the other image types today and post my results. I
guess
Quoted 1 line
Quoted 1 line
this bootm code has built up over a long time and it is hard to know
all
Quoted 2 lines
Quoted 1 line
the ways it is used.
Quoted 9 lines
Quoted 3 lines
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm. Need a day or two to check this out though.
Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to apply any patch on top of the said commit.
hawkboard > bootm c3000000
## Booting kernel from Legacy Image at c3000000 ...
Image Name: Netbsd Image Type: ARM NetBSD Kernel Image (uncompressed) Data Size: 2329152 Bytes = 2.2 MiB
Load Address: c0200000
Entry Point: c0200000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
subcommand not supported
hawkboard >
-sughosh
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Hi,
Quoted 11 lines · Sughosh Ganu
Quoted 7 lines · On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu <[email protected] wrote:
hi Tom,
On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
<snip>
Quoted 1 line
Quoted 1 line
Yes, I am not really comfortable with this. I will see if I can
write
Quoted 8 lines
Quoted 8 lines
some
Quoted 1 line
Quoted 1 line
sandbox tests for the other image types today and post my results. I
guess
Quoted 1 line
Quoted 1 line
this bootm code has built up over a long time and it is hard to know
all
Quoted 3 lines
Quoted 1 line
the ways it is used.
Important, but I really want to see real-world booting in a case or
two.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Unfortunately I don't have any ARM boards that work out of the box
with
Quoted 10 lines
Quoted 7 lines
Quoted 1 line
NetBSD.
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm. Need a day or two to check this out though.
Tried to boot netbsd with u-boot head
225fd8c5d45, and the boot fails. Was able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
apply
Quoted 1 line
any patch on top of the said commit.
Yes please see the four commits I sent earlier today.
Regards,
Simon
Quoted 21 lines
hawkboard > bootm
c3000000
## Booting kernel from Legacy Image atc3000000...Image Name: Netbsd Image Type: ARM NetBSD Kernel Image (uncompressed) Data Size: 2329152 Bytes = 2.2 MiBLoad Address:
c0200000
Entry Point:c0200000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
subcommand not supported
hawkboard >-sughosh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
hi,
Quoted 6 lines · Simon Glass
Quoted 6 lines
Quoted 5 lines
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm. Need a day or two to check this out though.
Quoted 6 lines
Quoted 2 lines
Tried to boot netbsd with u-boot head
225fd8c5d45, and the boot fails. Was able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed toapply
Quoted 1 line
any patch on top of the said commit.
Yes please see the four commits I sent earlier today.
Tried after applying the series from Simon, and now the netbsd image boots fine with the bootm command.
-sughosh
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
Hi Sughosh,
Quoted 13 lines · Sughosh Ganu
hi,
Quoted 3 lines · Simon Glass
Quoted 3 lines
Quoted 3 lines
I have netbsd running on hawkboard, but i do not boot it using the bootm command, but use the go command instead. I will try to build a netbsd image with the u-boot header and give it a try with bootm.
Need
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
a day or two to check this out though.
Tried to boot netbsd with u-boot head
225fd8c5d45, and the boot fails.Was
Quoted 9 lines
Quoted 5 lines
Quoted 1 line
able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
apply
Quoted 1 line
any patch on top of the said commit.
Yes please see the four commits I sent earlier today.
Tried after applying the series from Simon, and now the netbsd image boots fine with the bootm command.
Thanks very much for testing this.
Regards,
Simon
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Tom RiniHi Tom,
Quoted 91 lines · Tom Rini
Quoted 15 lines · Simon Glass
Hi Tom,
Quoted 11 lines · Tom Rini
Quoted 10 lines · Simon Glass
Hi Tom,
Quoted 6 lines · Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Robert Nelson
Quoted 2 lines · Tom Rini
Quoted 1 line · Simon Glass
In the recent bootm refactor, the PREP stage was missing in
the
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
bootz
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of
cmd_bootm.cQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
does not
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the
only
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
possibility
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
at present, and we need to select the right boot function.
Signed-off-by Simon Glass <[email protected]>With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0->256MiB
Quoted 9 lines
Quoted 9 lines
but
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
file) works, but Wand (device tree) is still locking up for
me...
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with
separate.
Quoted 2 lines
Quoted 2 lines
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since wedon't
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
have the rest of the header bits that the code checks for set.
I've
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
taken a few stabs at reworking things, but it's not working yet.
Simon,
Quoted 1 line
Quoted 1 line
do you have any ideas here? I'm starting to wonder if we don't
need to
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they
are
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as
we
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should
be
Quoted 10 lines
Quoted 8 lines
able
Quoted 1 line
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further. The problem is that
BOOTM_STATE_FINDOTHERwould never work since we aren't the "right" image types, so passed ramdisk and/or dtb didn't work. Another problem was that bootz was never consuming 'bootz', but this was OK before. I'll post a patch shortly.
Quoted 8 lines
Quoted 1 line
OK great, thanks for looking at this. I wonder if we can collect a set
of
Quoted 1 line
different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
The test currently checks that the kernel/ramdisk/fdt appear in the right place, and that U-Boot reports that it is booting the kernel from the right address. That actually should cover bugs where things don't end up in the right place, or are corrupted. Of course there are limitations with automated tests like this, but I still think it will make it easier for the next person who takes on a clean-up in this area of U-Boot.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
My biggest worry right now is, what might show up broken next? Anyone out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write
some
Quoted 9 lines
Quoted 1 line
sandbox tests for the other image types today and post my results. I
guess
Quoted 2 lines
this bootm code has built up over a long time and it is hard to know all the ways it is used.
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD.
Yes, me too. But in the meantime I have tried to do what I can here - spent many happy hours reviewing the code carefully and writing a 'sandbox' test for the following OSes:
['netbsd', 'lynxos', 'rtems', 'ose', 'plan9', 'vxworks', 'qnx', 'integrity']
I found that most of them have the same problem fixed by Andreas/Tom's commit 2cb0e55, so I will prepare a patch for this.
Additionally, the vxworks arguments are incorrect (argc is one less than expected). I will prepare a patch for this also.
Other than that, everything looks correct so far as I can tell, up to the point where U-Boot actually jumps to the OS.
I will tidy up my tests and submit these also at some point. Coverage now includes FIT and legacy images, with bootm commands and subcommands. For the record there is still a lot of test code missing:
Regards,
Simon
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
[snip]
I will tidy up my tests and submit these also at some point. Coverage now
Quoted 3 lines
includes FIT and legacy images, with bootm commands and subcommands. For the record there is still a lot of test code missing:
(sorry, sent the last email by mistake - here is a list that I compiled when writing the original tests)
- hash algorithms - invalid hash/contents should be detected
- signature algorithms - invalid sig/contents should be detected
- compression
- checking that errors are detected like:
- image overwriting
- missing images
- invalid configurations
- incorrect os/arch/type fields
- empty data
- images too large/small
- invalid FDT (e.g. putting a random binary in instead)
- default configuration selection
- bootm command line parameters should have desired effect
- run code coverage to make sure we are testing all the code
PATCH v2 5/5 bootm: Add the missing PREP stage to bootz and correct image handling
In reply to Simon GlassQuoted 53 lines · Simon Glass
Hi Tom,
Quoted 40 lines · Tom Rini
Quoted 38 lines · Tom Rini
Quoted 35 lines · Robert Nelson
Quoted 15 lines · Tom Rini
Quoted 8 lines · Simon Glass
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour.The use of a local variable means that the reset of
cmd_bootm.cdoes not
in fact use the same image structure, so remove this.Quoted 5 lines
Also manually set the OS type to Linux, since this is the only possibility
at present, and we need to select the right boot function.Signed-off-by Simon Glass <[email protected]>Quoted 7 lines
With the whole series applied, I still see a hang at:
Kernel image @0x80200000[0x000000-0x3d44a0]Starting kernel ...
Perhaps something to do with how my DDR is not at
0x0-> 256MiB but0x80000000-> 256MiB ?Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}Quoted 9 lines
Quoted 2 lines
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the
BOOTM_STATE_FINDOTHERstate code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet. Simon, do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Quoted 5 lines
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
Close.. It's the 'non appended dtb case'...
bootz ${loadaddr} - ${fdt_addr}
It's almost as if bootz doesn't have the location of the dtb binary in memory...
Quoted 2 lines
I will see if I can get a Beaglebone today or failing that I should be able to try bootz with appeneded dtb on another ARM board.
Regards,
Signature · 2 lines
Robert Nelson http://www.rcn-ee.com/
PATCH v2 2/5 bootm: Disable interrupts only when loading
In reply to Simon GlassQuoted 8 lines · Simon Glass
With the move of the interrupt code to earlier in the sequence, we exposed a problem where the interrupts are disabled at each bootm stage. This is not correct - it should be done only once. Let's disable interrupts in the LOAD stage. Put the code in a function for clarity.
Also, bootz lost its interrupt code altogether, so reinstate it.
Signed-off-by Simon Glass <[email protected]>
This and 3, 4 and 5 have been applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130710/1f67e6af/attachment.pgp>