Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
hi, On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote: 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. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Sughosh, On Fri, Jul 12, 2013 at 1:21 AM, Sughosh Ganu urwithsugh...@gmail.comwrote: hi, On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote: 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. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu urwithsugh...@gmail.comwrote: hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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. 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 c300 ## Booting kernel from Legacy Image at c300 ... Image Name: Netbsd Image Type: ARM NetBSD Kernel Image (uncompressed) Data Size:2329152 Bytes = 2.2 MiB Load Address: c020 Entry Point: c020 Verifying Checksum ... OK Loading Kernel Image ... OK OK subcommand not supported hawkboard -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi, On Jul 10, 2013 11:04 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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. 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. Yes please see the four commits I sent earlier today. Regards, Simon hawkboard bootm c300 ## Booting kernel from Legacy Image at c300 ... Image Name: Netbsd Image Type: ARM NetBSD Kernel Image (uncompressed) Data Size:2329152 Bytes = 2.2 MiB Load Address: c020 Entry Point: c020 Verifying Checksum ... OK Loading Kernel Image ... OK OK subcommand not supported hawkboard -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Sughosh, On Wed, Jul 10, 2013 at 2:51 AM, Sughosh Ganu urwithsugh...@gmail.comwrote: hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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. Thanks, much appreciated. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 -
256MiB
but
0x8000 - 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}
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.
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.
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.
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.
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.
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
Re: [U-Boot] [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 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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}
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.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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}
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.
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?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass s...@chromium.org wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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}
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.
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...
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,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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}
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.
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
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB
but
0x8000 - 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}
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.
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.
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?
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
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB
but
0x8000 - 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}
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.
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.
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.
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.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 4:19 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB
but
0x8000 - 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}
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.
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.
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.
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.
There 'seems' to be a pre-built freebsd arm port...
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
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 NM.. they are using the 'bootelf' command.. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot_patch05.patch#L108 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Tom,
On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 -
256MiB
but
0x8000 - 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}
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.
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.
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.
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.
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.
Me neither, unfortunately.
Regards,
Simon
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote: 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.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. Signed-off-by: Simon Glass s...@chromium.org With the whole series applied, I still see a hang at: Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ] Starting kernel ... Perhaps something to do with how my DDR is not at 0x0 - 256MiB but 0x8000 - 256MiB ? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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 @ 0x8200 [ 0x00 - 0x3414a0 ]
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] 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 @ 0x1200 [ 0x00 - 0x34dd00 ]
Starting kernel ...
lockup
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
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.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.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 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}
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.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
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.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.
Signed-off-by: Simon Glass s...@chromium.org
---
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(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index b89d6ad..6a635b0 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -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;
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
