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

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Bartlomiej Sieka]

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

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Markus Klotzbücher]

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 at denx.de

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HEALTH WARNING: Care Should Be Taken When Lifting This Product, Since
Its Mass, and Thus Its Weight, Is Dependent on Its Velocity  Relative
to the User.

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

[Bartlomiej Sieka]

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

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

[Bartlomiej Sieka]

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

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

[Stefan Roese]

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 at denx.de
=====================================================================