Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format

Patrick Venture venture at google.com
Tue Jul 3 03:14:15 AEST 2018


On Mon, Jul 2, 2018 at 10:13 AM, Patrick Venture <venture at google.com> wrote:
> On Thu, Jun 28, 2018 at 7:33 AM, Patrick Venture <venture at google.com> wrote:
>> On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel at jms.id.au> wrote:
>>> On 27 June 2018 at 01:49, Patrick Venture <venture at google.com> wrote:
>>>
>>>> Hit any key to stop autoboot:  0
>>>> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
>>>> ## Loading kernel from FIT Image at 20080000 ...
>>>>    Using 'conf at aspeed-bmc-quanta-q71l.dtb' configuration
>>>>    Trying 'kernel at 1' kernel subimage
>>>>      Description:  Linux kernel
>>>>      Type:         Kernel Image
>>>>      Compression:  uncompressed
>>>>      Data Start:   0x20080124
>>>>      Data Size:    1723192 Bytes = 1.6 MiB
>>>>      Architecture: ARM
>>>>      OS:           Linux
>>>>      Load Address: 0x40008000
>>>>      Entry Point:  0x40008000
>>>>      Hash algo:    sha1
>>>>      Hash value:   95ed76c9361d9f6f991a6a859a06eb7626af80df
>>>>    Verifying Hash Integrity ... sha1+ OK
>>>> Wrong Ramdisk Image Format
>>>> Ramdisk image is corrupt or invalid
>>>> """
>>>>
>>>> I figured I'd reach out first as I'm sure this will be familiar to someone :D
>>>
>>> This is due to a change Brad made to the u-boot setup. If you change
>>> your bootcmd to simply be 'bootm 20080000' you might be fine.
>>
>> Thanks, I'll give that a try tomorrow morning!
>
> Joel, that worked.  Running "bootm 20080000" from the ast uboot
> command line got it to boot.

 ast# fdt print /configurations/conf at 1
 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

 ast# fdt list
 / {
         timestamp = <0x5b3a5087>;
         description = "U-Boot fitImage for gBMC (OpenBMC + Google
 customizations)/4.13.16+gitAUTOINC+d5c7e19b10+.quanta-4.13-testing.+/quanta";
         #address-cells = <0x00000001>;
         images {
         };
         configurations {
         };
 };

I checked our u-boot patches and didn't see anything that was
different -- Brad, presumably this is something you can speak to?
At first glance, I can just write a u-boot patch that changes the
CONFIG_BOOTCOMMAND, but I imagine it's not creating the configuration
or it's not writing it where it should and that's the real issue.

>>
>>>
>>> Cheers,
>>>
>>> Joel


More information about the openbmc mailing list