* 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: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 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 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).