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