[U-Boot] Attached DTB no longer supported u-boot.imx?
I tried to update the new u-boot I get,
Bytes transferred = 3413041 (341431 hex) Kernel image @ 0x86000000 [ 0x000000 - 0x33e150 ] Could not find a valid device tree
The 'bootcmd' is,
tftp ${loadaddr} zImage.dtb; bootz ${loadaddr}
has the syntax changed and I am not up to date? I think I saw something about an attached DTB not supported.
u-boot-imx$ git describe v2009.08-18413-g5c84206
err, that is no good. I have 2a82ec77d27ef5f860a107c4b764643a655dceeb as 'Prepare v2015.01-rc2' and I had to apply 5c84206 to compile with a 4.9 hard-float ARM compiler.
I pulled the main 'u-boot.git' and this does not happen.
u-boot$ git describe v2015.01-rc2-87-g0f89149
It is '38cd8c4253013ccdd4052ee021f6066fe9a52551', with the same patch as 'pwclient git-am 415336'
Is the imx just using newer patches to be merged to the main tree and I must switch to a detached DT? Or is there something else?
Thanks, Bill.
On 28 Nov 2014, bpringlemeir@nbsps.com wrote:
I tried to update the new u-boot I get,
Bytes transferred = 3413041 (341431 hex) Kernel image @ 0x86000000 [ 0x000000 - 0x33e150 ] Could not find a valid device tree
[snip]
Is the imx just using newer patches to be merged to the main tree and I must switch to a detached DT? Or is there something else?
Sorry, both trees behave the same. I will switch to separate binaries.
On Fri, Nov 28, 2014 at 06:56:32PM -0500, Bill Pringlemeir wrote:
On 28 Nov 2014, bpringlemeir@nbsps.com wrote:
I tried to update the new u-boot I get,
Bytes transferred = 3413041 (341431 hex) Kernel image @ 0x86000000 [ 0x000000 - 0x33e150 ] Could not find a valid device tree
[snip]
Is the imx just using newer patches to be merged to the main tree and I must switch to a detached DT? Or is there something else?
Sorry, both trees behave the same. I will switch to separate binaries.
This is not intentional. I suspect I know what commit did this. Can you please do a git bisect from v2015.01-rc1 to -rc2 and see what it says the bad commit is? Thanks!
On Fri, Nov 28, 2014 at 06:56:32PM -0500, Bill Pringlemeir wrote:
Sorry, both trees behave the same. I will switch to separate binaries.
On 28 Nov 2014, trini@ti.com wrote:
This is not intentional. I suspect I know what commit did this. Can you please do a git bisect from v2015.01-rc1 to -rc2 and see what it says the bad commit is? Thanks!
I have the 'ext4-div' patch and I must reduce the vf610 image size in order to boot (why I have 'git reset --hard').
git reset --hard; git bisect bad HEAD is now at c6150aa image-fdt: boot_get_fdt() return value when no DTB exists c6150aaf2f2745141a7c2ceded58d7efbfeace7d is the first bad commit commit c6150aaf2f2745141a7c2ceded58d7efbfeace7d Author: Noam Camus noamc@ezchip.com Date: Wed Oct 22 17:17:49 2014 +0300
image-fdt: boot_get_fdt() return value when no DTB exists
I believe that when no DTB is around we should return 1. This why I fixed such scenarious to not return zero anymore. Else kernel might get NULL pointer to DTB which doesn't exists.
Signed-off-by: Noam Camus noamc@ezchip.com
:040000 040000 f343f802d1491dc54545271694669c21f5efaa65 1120435d7aee7a9c12a6c8e2c0b19a364cbaf185 M common
If I take rc2, revert c6150aaf2 and rebuild then the attached DTB image seems fine for booting.
Regards, Bill Pringlemeir.
On Wed, Dec 03, 2014 at 10:43:59AM -0500, Bill Pringlemeir wrote:
On Fri, Nov 28, 2014 at 06:56:32PM -0500, Bill Pringlemeir wrote:
Sorry, both trees behave the same. I will switch to separate binaries.
On 28 Nov 2014, trini@ti.com wrote:
This is not intentional. I suspect I know what commit did this. Can you please do a git bisect from v2015.01-rc1 to -rc2 and see what it says the bad commit is? Thanks!
I have the 'ext4-div' patch and I must reduce the vf610 image size in order to boot (why I have 'git reset --hard').
git reset --hard; git bisect bad HEAD is now at c6150aa image-fdt: boot_get_fdt() return value when no DTB exists c6150aaf2f2745141a7c2ceded58d7efbfeace7d is the first bad commit commit c6150aaf2f2745141a7c2ceded58d7efbfeace7d Author: Noam Camus noamc@ezchip.com Date: Wed Oct 22 17:17:49 2014 +0300
image-fdt: boot_get_fdt() return value when no DTB exists I believe that when no DTB is around we should return 1. This why I fixed such scenarious to not return zero anymore. Else kernel might get NULL pointer to DTB which doesn't exists. Signed-off-by: Noam Camus <noamc@ezchip.com>:040000 040000 f343f802d1491dc54545271694669c21f5efaa65 1120435d7aee7a9c12a6c8e2c0b19a364cbaf185 M common
If I take rc2, revert c6150aaf2 and rebuild then the attached DTB image seems fine for booting.
Great, thanks!
participants (2)
-
Bill Pringlemeir -
Tom Rini