openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
@ 2018-06-26 16:19 Patrick Venture
  2018-06-27  1:10 ` Andrew Jeffery
  2018-06-28  1:30 ` Joel Stanley
  0 siblings, 2 replies; 14+ messages in thread
From: Patrick Venture @ 2018-06-26 16:19 UTC (permalink / raw)
  To: OpenBMC Maillist

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@1' configuration
   Trying 'kernel@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@1' configuration
   Trying 'ramdisk@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@1' configuration
   Trying 'fdt@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
## Loading kernel from FIT Image at 20080000 ...
   Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
   Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-26 16:19 Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format Patrick Venture
@ 2018-06-27  1:10 ` Andrew Jeffery
  2018-06-27  1:40   ` Kun Yi
  2018-06-27 14:38   ` Patrick Venture
  2018-06-28  1:30 ` Joel Stanley
  1 sibling, 2 replies; 14+ messages in thread
From: Andrew Jeffery @ 2018-06-27  1:10 UTC (permalink / raw)
  To: Patrick Venture, OpenBMC Maillist

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@1' configuration
>    Trying 'kernel@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@1' configuration
>    Trying 'ramdisk@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@1' configuration
>    Trying 'fdt@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?

Might also be helpful to provide the content of the .its file.

> ## Loading kernel from FIT Image at 20080000 ...
>    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
>    Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27  1:10 ` Andrew Jeffery
@ 2018-06-27  1:40   ` Kun Yi
  2018-06-27 14:39     ` Patrick Venture
  2018-06-27 14:38   ` Patrick Venture
  1 sibling, 1 reply; 14+ messages in thread
From: Kun Yi @ 2018-06-27  1:40 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: Patrick Venture, OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]

libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

Might be caused a config change in U-boot?

On Tue, Jun 26, 2018 at 6:10 PM Andrew Jeffery <andrew@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@1' configuration
> >    Trying 'kernel@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@1' configuration
> >    Trying 'ramdisk@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@1' configuration
> >    Trying 'fdt@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?
>
> Might also be helpful to provide the content of the .its file.
>
> > ## Loading kernel from FIT Image at 20080000 ...
> >    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
> >    Trying 'kernel@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
>


-- 
Regards,
Kun

[-- Attachment #2: Type: text/html, Size: 6023 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27  1:10 ` Andrew Jeffery
  2018-06-27  1:40   ` Kun Yi
@ 2018-06-27 14:38   ` Patrick Venture
  2018-06-27 15:39     ` Patrick Venture
  1 sibling, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-06-27 14:38 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: OpenBMC Maillist

On Tue, Jun 26, 2018 at 6:10 PM, Andrew Jeffery <andrew@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@1' configuration
>>    Trying 'kernel@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@1' configuration
>>    Trying 'ramdisk@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@1' configuration
>>    Trying 'fdt@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).

>
> Might also be helpful to provide the content of the .its file.
>
>> ## Loading kernel from FIT Image at 20080000 ...
>>    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
>>    Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27  1:40   ` Kun Yi
@ 2018-06-27 14:39     ` Patrick Venture
  0 siblings, 0 replies; 14+ messages in thread
From: Patrick Venture @ 2018-06-27 14:39 UTC (permalink / raw)
  To: Kun Yi; +Cc: Andrew Jeffery, OpenBMC Maillist

On Tue, Jun 26, 2018 at 6:40 PM, Kun Yi <kunyi@google.com> wrote:
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
>
> Might be caused a config change in U-boot?

I'll check to see what changed in the u-boot config between v2.1 and
v2.2 (and if there were any changes in our aspeed.google branch).

>
> On Tue, Jun 26, 2018 at 6:10 PM Andrew Jeffery <andrew@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@1' configuration
>> >    Trying 'kernel@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@1' configuration
>> >    Trying 'ramdisk@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@1' configuration
>> >    Trying 'fdt@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?
>>
>> Might also be helpful to provide the content of the .its file.
>>
>> > ## Loading kernel from FIT Image at 20080000 ...
>> >    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
>> >    Trying 'kernel@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
>
>
>
> --
> Regards,
> Kun

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27 14:38   ` Patrick Venture
@ 2018-06-27 15:39     ` Patrick Venture
  2018-06-27 21:17       ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-06-27 15:39 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: OpenBMC Maillist

On Wed, Jun 27, 2018 at 7:38 AM, Patrick Venture <venture@google.com> wrote:
> On Tue, Jun 26, 2018 at 6:10 PM, Andrew Jeffery <andrew@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@1' configuration
>>>    Trying 'kernel@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@1' configuration
>>>    Trying 'ramdisk@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@1' configuration
>>>    Trying 'fdt@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.

>
>>
>> Might also be helpful to provide the content of the .its file.
>>
>>> ## Loading kernel from FIT Image at 20080000 ...
>>>    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
>>>    Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27 15:39     ` Patrick Venture
@ 2018-06-27 21:17       ` Patrick Venture
  2018-06-27 22:58         ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-06-27 21:17 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: OpenBMC Maillist

On Wed, Jun 27, 2018 at 8:39 AM, Patrick Venture <venture@google.com> wrote:
> On Wed, Jun 27, 2018 at 7:38 AM, Patrick Venture <venture@google.com> wrote:
>> On Tue, Jun 26, 2018 at 6:10 PM, Andrew Jeffery <andrew@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@1' configuration
>>>>    Trying 'kernel@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@1' configuration
>>>>    Trying 'ramdisk@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@1' configuration
>>>>    Trying 'fdt@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.

>
>>
>>>
>>> Might also be helpful to provide the content of the .its file.
>>>
>>>> ## Loading kernel from FIT Image at 20080000 ...
>>>>    Using 'conf@aspeed-bmc-quanta-q71l.dtb' configuration
>>>>    Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-27 21:17       ` Patrick Venture
@ 2018-06-27 22:58         ` Patrick Venture
  0 siblings, 0 replies; 14+ messages in thread
From: Patrick Venture @ 2018-06-27 22:58 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: OpenBMC Maillist

On Wed, Jun 27, 2018 at 2:17 PM, Patrick Venture <venture@google.com> wrote:
> On Wed, Jun 27, 2018 at 8:39 AM, Patrick Venture <venture@google.com> wrote:
>> On Wed, Jun 27, 2018 at 7:38 AM, Patrick Venture <venture@google.com> wrote:
>>> On Tue, Jun 26, 2018 at 6:10 PM, Andrew Jeffery <andrew@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@1' configuration
>>>>>    Trying 'kernel@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@1' configuration
>>>>>    Trying 'ramdisk@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@1' configuration
>>>>>    Trying 'fdt@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>>>>    Trying 'kernel@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-26 16:19 Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format Patrick Venture
  2018-06-27  1:10 ` Andrew Jeffery
@ 2018-06-28  1:30 ` Joel Stanley
  2018-06-28 14:33   ` Patrick Venture
  1 sibling, 1 reply; 14+ messages in thread
From: Joel Stanley @ 2018-06-28  1:30 UTC (permalink / raw)
  To: Patrick Venture; +Cc: OpenBMC Maillist

On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>    Trying 'kernel@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.

Cheers,

Joel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-28  1:30 ` Joel Stanley
@ 2018-06-28 14:33   ` Patrick Venture
  2018-07-02 17:13     ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-06-28 14:33 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel@jms.id.au> wrote:
> On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>    Trying 'kernel@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!

>
> Cheers,
>
> Joel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-06-28 14:33   ` Patrick Venture
@ 2018-07-02 17:13     ` Patrick Venture
  2018-07-02 17:14       ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-07-02 17:13 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

On Thu, Jun 28, 2018 at 7:33 AM, Patrick Venture <venture@google.com> wrote:
> On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel@jms.id.au> wrote:
>> On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>>    Trying 'kernel@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@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-07-02 17:13     ` Patrick Venture
@ 2018-07-02 17:14       ` Patrick Venture
  2018-07-02 17:39         ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-07-02 17:14 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

On Mon, Jul 2, 2018 at 10:13 AM, Patrick Venture <venture@google.com> wrote:
> On Thu, Jun 28, 2018 at 7:33 AM, Patrick Venture <venture@google.com> wrote:
>> On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel@jms.id.au> wrote:
>>> On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>>>    Trying 'kernel@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@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-07-02 17:14       ` Patrick Venture
@ 2018-07-02 17:39         ` Patrick Venture
  2018-07-02 17:43           ` Patrick Venture
  0 siblings, 1 reply; 14+ messages in thread
From: Patrick Venture @ 2018-07-02 17:39 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

On Mon, Jul 2, 2018 at 10:14 AM, Patrick Venture <venture@google.com> wrote:
> On Mon, Jul 2, 2018 at 10:13 AM, Patrick Venture <venture@google.com> wrote:
>> On Thu, Jun 28, 2018 at 7:33 AM, Patrick Venture <venture@google.com> wrote:
>>> On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel@jms.id.au> wrote:
>>>> On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>>>>    Trying 'kernel@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@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.

When I built from openbmc v2.2 pure:

ast# print env
## Error: "env" not defined
ast# printenv
baudrate=115200
bootargs=console=ttyS4,115200n8 root=/dev/ram rw
bootcmd=bootm 20080000
bootdelay=2
ethact=aspeednic#0
spi_dma=yes
stderr=serial
stdin=serial
stdout=serial
verify=yes

Environment size: 204/65531 bytes

ast# fdt addr 20080000
ast# fdt list
/ {
timestamp = <0x5b3a5f75>;
description = "U-Boot fitImage for Phosphor OpenBMC (Phosphor OpenBMC
Project Reference Distro)/4.13.16+gitAUTOINC+158c8e15d5/quanta-q71l";
#address-cells = <0x00000001>;
images {
};
configurations {
};
};
ast# fdt print /configurations/conf@1
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format
  2018-07-02 17:39         ` Patrick Venture
@ 2018-07-02 17:43           ` Patrick Venture
  0 siblings, 0 replies; 14+ messages in thread
From: Patrick Venture @ 2018-07-02 17:43 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

https://github.com/openbmc/u-boot/commit/e4c85cd4de96bfdff7b614731a044db11815ff0c

Looks like this is the patch we need in our downstream u-boot! :D

On Mon, Jul 2, 2018 at 10:39 AM, Patrick Venture <venture@google.com> wrote:
> On Mon, Jul 2, 2018 at 10:14 AM, Patrick Venture <venture@google.com> wrote:
>> On Mon, Jul 2, 2018 at 10:13 AM, Patrick Venture <venture@google.com> wrote:
>>> On Thu, Jun 28, 2018 at 7:33 AM, Patrick Venture <venture@google.com> wrote:
>>>> On Wed, Jun 27, 2018 at 6:30 PM, Joel Stanley <joel@jms.id.au> wrote:
>>>>> On 27 June 2018 at 01:49, Patrick Venture <venture@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@aspeed-bmc-quanta-q71l.dtb' configuration
>>>>>>    Trying 'kernel@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@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.
>
> When I built from openbmc v2.2 pure:
>
> ast# print env
> ## Error: "env" not defined
> ast# printenv
> baudrate=115200
> bootargs=console=ttyS4,115200n8 root=/dev/ram rw
> bootcmd=bootm 20080000
> bootdelay=2
> ethact=aspeednic#0
> spi_dma=yes
> stderr=serial
> stdin=serial
> stdout=serial
> verify=yes
>
> Environment size: 204/65531 bytes
>
> ast# fdt addr 20080000
> ast# fdt list
> / {
> timestamp = <0x5b3a5f75>;
> description = "U-Boot fitImage for Phosphor OpenBMC (Phosphor OpenBMC
> Project Reference Distro)/4.13.16+gitAUTOINC+158c8e15d5/quanta-q71l";
> #address-cells = <0x00000001>;
> images {
> };
> configurations {
> };
> };
> ast# fdt print /configurations/conf@1
> libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
>
>>
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Joel

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-07-02 17:43 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-26 16:19 Merging up to OpenBMC v2.2 from v2.1 - boot problem, invalid ramdisk format Patrick Venture
2018-06-27  1:10 ` Andrew Jeffery
2018-06-27  1:40   ` Kun Yi
2018-06-27 14:39     ` Patrick Venture
2018-06-27 14:38   ` Patrick Venture
2018-06-27 15:39     ` Patrick Venture
2018-06-27 21:17       ` Patrick Venture
2018-06-27 22:58         ` Patrick Venture
2018-06-28  1:30 ` Joel Stanley
2018-06-28 14:33   ` Patrick Venture
2018-07-02 17:13     ` Patrick Venture
2018-07-02 17:14       ` Patrick Venture
2018-07-02 17:39         ` Patrick Venture
2018-07-02 17:43           ` Patrick Venture

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).