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

[Patrick Venture]

On Wed, Jun 27, 2018 at 2:17 PM, Patrick Venture <venture at google.com> wrote:
> On Wed, Jun 27, 2018 at 8:39 AM, Patrick Venture <venture at google.com> wrote:
>> On Wed, Jun 27, 2018 at 7:38 AM, Patrick Venture <venture at google.com> wrote:
>>> On Tue, Jun 26, 2018 at 6:10 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
>>>> On Wed, 27 Jun 2018, at 01:49, Patrick Venture wrote:
>>>>> I assume this is just a recipe change such that I need to now specify
>>>>> something -- with OpenBMC v2.1 I see:
>>>>>
>>>>> """
>>>>> U-Boot 2016.07 (May 24 2018 - 12:55:55 -0700)
>>>>>
>>>>> DRAM:  120 MiB
>>>>> WARNING: Caches not enabled
>>>>> Flash: 64 MiB
>>>>> *** Warning - bad CRC, using default environment
>>>>>
>>>>> In:    serial
>>>>> Out:   serial
>>>>> Err:   serial
>>>>> Net:   aspeednic#0
>>>>> Error: aspeednic#0 address not set.
>>>>>
>>>>> Hit any key to stop autoboot:  0
>>>>> ## Loading kernel from FIT Image at 20080000 ...
>>>>>    Using 'conf at 1' configuration
>>>>>    Trying 'kernel at 1' kernel subimage
>>>>>      Description:  Linux kernel
>>>>>      Type:         Kernel Image
>>>>>      Compression:  uncompressed
>>>>>      Data Start:   0x20080128
>>>>>      Data Size:    1721352 Bytes = 1.6 MiB
>>>>>      Architecture: ARM
>>>>>      OS:           Linux
>>>>>      Load Address: 0x40008000
>>>>>      Entry Point:  0x40008000
>>>>>      Hash algo:    sha1
>>>>>      Hash value:   de140d9d803c22f731c4d99a4250979489383a81
>>>>>    Verifying Hash Integrity ... sha1+ OK
>>>>> ## Loading ramdisk from FIT Image at 20080000 ...
>>>>>    Using 'conf at 1' configuration
>>>>>    Trying 'ramdisk at 1' ramdisk subimage
>>>>>      Description:  obmc-phosphor-initramfs
>>>>>      Type:         RAMDisk Image
>>>>>      Compression:  lzma compressed
>>>>>      Data Start:   0x2022ad00
>>>>>      Data Size:    1592362 Bytes = 1.5 MiB
>>>>>      Architecture: ARM
>>>>>      OS:           Linux
>>>>>      Load Address: unavailable
>>>>>      Entry Point:  unavailable
>>>>>      Hash algo:    sha1
>>>>>      Hash value:   9f6f2feb110e27e07f81bb60bb372b4083672f19
>>>>>    Verifying Hash Integrity ... sha1+ OK
>>>>> ## Loading fdt from FIT Image at 20080000 ...
>>>>>    Using 'conf at 1' configuration
>>>>>    Trying 'fdt at 1' fdt subimage
>>>>>      Description:  Flattened Device Tree blob
>>>>>      Type:         Flat Device Tree
>>>>>      Compression:  uncompressed
>>>>>      Data Start:   0x20224624
>>>>>      Data Size:    26139 Bytes = 25.5 KiB
>>>>>      Architecture: ARM
>>>>>      Hash algo:    sha1
>>>>>      Hash value:   37864a4c4a608d5f4e370bbccf93ccbe3e77462d
>>>>>    Verifying Hash Integrity ... sha1+ OK
>>>>>    Booting using the fdt blob at 0x20224624
>>>>>    Loading Kernel Image ... OK
>>>>>    Loading Ramdisk to 47213000, end 47397c2a ... OK
>>>>>    Loading Device Tree to 47209000, end 4721261a ... OK
>>>>>
>>>>> Starting kernel ...
>>>>> """
>>>>>
>>>>> With v2.2 I see:
>>>>> """
>>>>> U-Boot 2016.07 (Jun 25 2018 - 10:07:57 -0700)
>>>>>
>>>>> DRAM:  120 MiB
>>>>> WARNING: Caches not enabled
>>>>> Flash: 64 MiB
>>>>> *** Warning - bad CRC, using default environment
>>>>>
>>>>> In:    serial
>>>>> Out:   serial
>>>>> Err:   serial
>>>>> Net:   aspeednic#0
>>>>> Error: aspeednic#0 address not set.
>>>>>
>>>>> Hit any key to stop autoboot:  0
>>>>> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
>>>>
>>>> From below it looks like u-boot finds the kernel in the FIT, but your ramdisk is "corrupt". The error above suggests something is missing from the FIT. Can you check the initrd/ramdisk node in your FIT to make sure it is present and uses all the correct options and paths with respect to the initrd you intended to package?
>>>
>>> I'll take a look -- one thought I had last night is that now the
>>> kernel config bit above is using the dts -- and IIRC, there have been
>>> changes to the flash layout.  So, maybe my device tree being used here
>>> is out-of-date or doesn't match what it's expecting now.  I'm still on
>>> the 4.7.10 kernel as I haven't had a chance to get the host booted
>>> with 4.13 (although that's high on my todo list).
>>
>> My layout idea didn't pan out -- I'm going to try 4.13 kernel with
>> v2.2 openbmc -- I had tried 4.13 with v2.0 and it worked (other than
>> the host wouldn't boot).  So, I'm going to give that a quick try so
>> I"m at least failing on something up-to-date.
>
> The BMC is able to boot using the 4.13 kernel.  So the issue must be
> something incompatible or unhappy.  As a reason to force cycles to get
> to 4.13, this will do the trick.

I need to retract that statement. I'm testing 4.13 with v2.1 (forgot
to reapply associated patches).

>
>>
>>>
>>>>
>>>> Might also be helpful to provide the content of the .its file.
>>>>
>>>>> ## 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
>>>>>
>>>>> Patrick