[U-Boot-Users] Current U-Boot doesn't boot device tree enabled kernel anymore

I just ran into a problem with current U-Boot on Kilauea and device tree enabled Linux kernel (arch/powerpc). After updating U-Boot the kernel doesn't boot anymore:
=> run net_nfs_fdt Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/uImage'. Load address: 0x200000 Loading: ################################################################# ####################### done Bytes transferred = 1288707 (13aa03 hex) ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/kilauea.dtb'. Load address: 0x400000 Loading: # done Bytes transferred = 8000 (1f40 hex) ## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ERROR: image overwritten - must RESET the board to recover.
Before updating U-Boot I am able to boot exactly this kernel/dtb combination without problems:
=> run net_nfs_fdt Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/uImage'. Load address: 0x200000 Loading: ################################################################# ####################### done Bytes transferred = 1288707 (13aa03 hex) ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/kilauea.dtb'. Load address: 0x400000 Loading: # done Bytes transferred = 8000 (1f40 hex) ## Booting image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x400000 Using Kilauea machine description ...
Any ideas?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Stefan Roese wrote:
I just ran into a problem with current U-Boot on Kilauea and device tree enabled Linux kernel (arch/powerpc). After updating U-Boot the kernel doesn't boot anymore:
=> run net_nfs_fdt Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/uImage'. Load address: 0x200000 Loading: ################################################################# ####################### done Bytes transferred = 1288707 (13aa03 hex) ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/kilauea.dtb'. Load address: 0x400000 Loading: # done Bytes transferred = 8000 (1f40 hex) ## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ERROR: image overwritten - must RESET the board to recover.
Before updating U-Boot I am able to boot exactly this kernel/dtb combination without problems:
=> run net_nfs_fdt Waiting for PHY auto negotiation to complete... done ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/uImage'. Load address: 0x200000 Loading: ################################################################# ####################### done Bytes transferred = 1288707 (13aa03 hex) ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.152; our IP address is 10.0.0.182 Filename 'kilauea/kilauea.dtb'. Load address: 0x400000 Loading: # done Bytes transferred = 8000 (1f40 hex) ## Booting image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x400000 Using Kilauea machine description ...
Any ideas?
The image got overwritten during decompression. Try loading the image at a higher address.
Regards, Bartlomiej

On Thursday 27 March 2008, Bartlomiej Sieka wrote:
## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ERROR: image overwritten - must RESET the board to recover.
<snip>
Any ideas?
The image got overwritten during decompression. Try loading the image at a higher address.
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Stefan Roese sr@denx.de writes:
On Thursday 27 March 2008, Bartlomiej Sieka wrote:
The image got overwritten during decompression. Try loading the image at a higher address.
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Odd. My first thought was this must be unrelated and the kernel just grew enough for this to happen. But I see the same failure with top of git sequoia, while it works fine with an older version[1].
Best regards
Markus Klotzbuecher
[1] U-Boot 1.3.2-rc3-g91c82076 (Mar 19 2008 - 10:23:31)
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de

On Thursday 27 March 2008, Markus Klotzbücher wrote:
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Odd. My first thought was this must be unrelated and the kernel just grew enough for this to happen. But I see the same failure with top of git sequoia, while it works fine with an older version[1].
Yes, I really think this should be investigated further.
Bartlomiej, any ideas on this?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Dear Bartek,
in message 87hces18nu.fsf@denx.de Markus Klotzbücher wrote:
Stefan Roese sr@denx.de writes:
On Thursday 27 March 2008, Bartlomiej Sieka wrote:
The image got overwritten during decompression. Try loading the image at a higher address.
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Odd. My first thought was this must be unrelated and the kernel just grew enough for this to happen. But I see the same failure with top of git sequoia, while it works fine with an older version[1].
Best regards
Markus Klotzbuecher
[1] U-Boot 1.3.2-rc3-g91c82076 (Mar 19 2008 - 10:23:31)
Can you please check what's going on there? I think such a regression should not happen - also the significant size increase observed especially on ARM systems.
Please check if there were - for example - merge problems, i. e. if the code is indeed correct.
Thanks.
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
Dear Bartek,
[...]
Please check if there were - for example - merge problems, i. e. if the code is indeed correct.
Dear Wolfgang,
I have verified the code relevant to the overwrite checks reported by Stefan, as well as checked size increase when enabling new format, between the new-image branch, and the current master, and it looks like the merge went OK.
Regards, Bartlomiej

Stefan Roese wrote:
On Thursday 27 March 2008, Bartlomiej Sieka wrote:
## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ERROR: image overwritten - must RESET the board to recover.
<snip>
Any ideas?
The image got overwritten during decompression. Try loading the image at a higher address.
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Hi Stefan,
It's because we assume that if the image got overwritten, its contents can't be trusted anymore, and abort booting. "Old" U-Boot didn't care about overwrites, which sometimes worked out OK, and sometimes didn't, the latter case resulting in nasty failure modes.
The overwrite issue is particularly acute in case of the new image format. Image is based on FDT and is being accessed via libfdt functions, so if it gets overwritten, there's little point in processing it further. But even with images in old format, this issue has been brought up on this list, and there's been proposals to add safeguards. So since overwrite checking was rather necessary for the new format, and desired for the old one, it got added.
There's also a technical reason why the overwrite check is active even when CONFIG_FIT is not defined. To minimize code size increase when adding new format, a lot of boot-related code has been re-factored. In particular, the decompression (and the check for the overwrite) is handled by code common to new and old formats, and hence the check is performed in both cases.
Regards, Bartlomiej

On Thursday 27 March 2008, Bartlomiej Sieka wrote:
It's because we assume that if the image got overwritten, its contents can't be trusted anymore, and abort booting. "Old" U-Boot didn't care about overwrites, which sometimes worked out OK, and sometimes didn't, the latter case resulting in nasty failure modes.
Ah, ok. So I really need to change all default environment variables on the board I maintain. Time to implement a common file for this.
The overwrite issue is particularly acute in case of the new image format. Image is based on FDT and is being accessed via libfdt functions, so if it gets overwritten, there's little point in processing it further. But even with images in old format, this issue has been brought up on this list, and there's been proposals to add safeguards. So since overwrite checking was rather necessary for the new format, and desired for the old one, it got added.
Understood. Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (4)
-
Bartlomiej Sieka
-
Markus Klotzbücher
-
Stefan Roese
-
Wolfgang Denk