<div dir="ltr"><div>I think within A FIT image, the u-boot binary is not located at your entry point 0x81000000, <br></div><div>it is behind the fit header, somewhere. This means the entry_point and load_addr is not the same as spl_boot.c defined. <br><div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:18px;white-space:pre"><div><span style="color:rgb(212,212,212)"> </span><span style="color:rgb(156,220,254)">spl_image</span><span style="color:rgb(212,212,212)">-></span><span style="color:rgb(156,220,254)">entry_point</span><span style="color:rgb(212,212,212)"> = CONFIG_ASPEED_UBOOT_DRAM_BASE;</span></div><div><span style="color:rgb(212,212,212)"> </span><span style="color:rgb(156,220,254)">spl_image</span><span style="color:rgb(212,212,212)">-></span><span style="color:rgb(156,220,254)">load_addr</span><span style="color:rgb(212,212,212)"> = CONFIG_ASPEED_UBOOT_DRAM_BASE;</span></div></div></div><div>Also, the u-boot code itself before relocation is position aware ( SYS_TEXT_BASE must be set to 0x81000000, as your second try works). This means the entry_point shall be the same as SYS_TEXT_BASE.</div><div><br></div><div>In fb/OpenBMC, verified boot implementation, use mkimage option: <br></div><div> -p => place external data at a static position,</div><div>thus we specify the somewhere to a static offset , then you can set the entry_point = load_addr + offset.</div><div><br></div><div>Another solution may be consider letting the SPL do what "bootm <entry_point>" do, which I guess (I did not look into this yet) shall be what "CONFIG_SPL_LOAD_FIT" do. <br></div><div><br></div><div>BRs</div><div>Dan <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 11:26 AM <<a href="mailto:openbmc-request@lists.ozlabs.org">openbmc-request@lists.ozlabs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send openbmc mailing list submissions to<br>
<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/listinfo/openbmc</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openbmc-request@lists.ozlabs.org" target="_blank">openbmc-request@lists.ozlabs.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openbmc-owner@lists.ozlabs.org" target="_blank">openbmc-owner@lists.ozlabs.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openbmc digest..."<br>
Today's Topics:<br>
<br>
1. Re: [PATCH] ARM: dts: nuvoton: Fix flash layout (Tomer Maimon)<br>
2. Re: any in-progress Redfish TelemetryService enhancements?<br>
(Brad Bishop)<br>
3. (Aspeed2600) Booting with a SPL loading U-boot fitImage<br>
(Klaus Heinrich Kiwi)<br>
<br><br><br>---------- Forwarded message ----------<br>From: Tomer Maimon <<a href="mailto:tmaimon77@gmail.com" target="_blank">tmaimon77@gmail.com</a>><br>To: Anton Kachalov <<a href="mailto:gmouse@google.com" target="_blank">gmouse@google.com</a>><br>Cc: Benjamin Fair <<a href="mailto:benjaminfair@google.com" target="_blank">benjaminfair@google.com</a>>, Avi Fishman <<a href="mailto:avifishman70@gmail.com" target="_blank">avifishman70@gmail.com</a>>, Tali Perry <<a href="mailto:tali.perry1@gmail.com" target="_blank">tali.perry1@gmail.com</a>>, Patrick Venture <<a href="mailto:venture@google.com" target="_blank">venture@google.com</a>>, Nancy Yuen <<a href="mailto:yuenn@google.com" target="_blank">yuenn@google.com</a>>, Rob Herring <<a href="mailto:robh%2Bdt@kernel.org" target="_blank">robh+dt@kernel.org</a>>, OpenBMC Maillist <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>>, devicetree <<a href="mailto:devicetree@vger.kernel.org" target="_blank">devicetree@vger.kernel.org</a>>, Linux Kernel Mailing List <<a href="mailto:linux-kernel@vger.kernel.org" target="_blank">linux-kernel@vger.kernel.org</a>><br>Bcc: <br>Date: Mon, 1 Mar 2021 15:36:58 +0200<br>Subject: Re: [PATCH] ARM: dts: nuvoton: Fix flash layout<br><div dir="ltr">Hi Anton,<div><br></div><div>The reason the u-boot Env is at 0x100000 address is that some costumers have:</div><div>one copy of Bootblock and U-boot at 0x0 - 0x80000</div><div>second copy of Bootblock and U-boot at 0x80000 - 0x100000.</div><div><br></div><div>we have two options;</div><div>1. Modify the OpenBMC device tree flash layout u-boot Env address to 0x100000.<br></div><div>2. Add a patch to OpnBMC platform that using openbmc flash layout to modify <span style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre-wrap">CONFIG_ENV_OFFSET </span><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif">in the u-boot.</font></span></div><div><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif"><br></font></span></div><div><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif">Thanks,</font></span></div><div><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif"><br></font></span></div><div><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif">Tomer</font></span></div><div><span style="box-sizing:border-box;white-space:pre-wrap"><font face="arial, sans-serif"><br></font></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 26 Feb 2021 at 22:10, Anton Kachalov <<a href="mailto:gmouse@google.com" target="_blank">gmouse@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello, Tomer.<br></div><div dir="ltr"><div><br></div><div>Seems like Nuvoton's u-boot expects the uboot-env at different address comparing to openbmc-flash-layout.dtsi:</div><div><br></div><div><a href="https://github.com/Nuvoton-Israel/u-boot/blob/npcm7xx-v2019.01/include/configs/poleg.h#L30" target="_blank">https://github.com/Nuvoton-Israel/u-boot/blob/npcm7xx-v2019.01/include/configs/poleg.h#L30</a><br></div><div><br></div><div>Vs.</div><div><br></div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/openbmc-flash-layout.dtsi#n13" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/openbmc-flash-layout.dtsi#n13</a><br></div><div><br></div><div>The change is more about making partitions naming the same as expected by OpenBMC.</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 21 Feb 2021 at 17:40, Tomer Maimon <<a href="mailto:tmaimon77@gmail.com" target="_blank">tmaimon77@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Benjamin and Anton,<div><br></div><div>Sorry for the late reply,</div><div><br></div><div><p class="MsoNormal" style="margin:0cm 0cm 0.0001pt"><font face="arial, sans-serif">The EVB FIU0-CS0
partitioning is used for testing the EVB and this is why it is
different than the OpenBMC flash layout.</font></p>
<p class="MsoNormal" style="margin:0cm 0cm 0.0001pt"><font face="arial, sans-serif"> </font></p>
<p class="MsoNormal" style="margin:0cm 0cm 0.0001pt"><font face="arial, sans-serif">Are you using the NPCM7XX EVB for
OpenBMC? if yes we can consider to modify the flash partition to OpenBMC use.</font></p></div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 18 Feb 2021 at 19:11, Benjamin Fair <<a href="mailto:benjaminfair@google.com" target="_blank">benjaminfair@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 18 Feb 2021 at 04:42, <<a href="mailto:gmouse@google.com" target="_blank">gmouse@google.com</a>> wrote:<br>
><br>
> From: "Anton D. Kachalov" <<a href="mailto:gmouse@google.com" target="_blank">gmouse@google.com</a>><br>
><br>
> This change satisfy OpenBMC requirements for flash layout.<br>
><br>
> Signed-off-by: Anton D. Kachalov <<a href="mailto:gmouse@google.com" target="_blank">gmouse@google.com</a>><br>
> ---<br>
> arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 28 +++++++----------------<br>
> 1 file changed, 8 insertions(+), 20 deletions(-)<br>
><br>
> diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts<br>
> index bd1eb6ee380f..741c1fee8552 100644<br>
> --- a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts<br>
> +++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts<br>
> @@ -182,8 +182,8 @@ bbuboot2@80000 {<br>
> reg = <0x0080000 0x80000>;<br>
> read-only;<br>
> };<br>
> - envparam@100000 {<br>
> - label = "env-param";<br>
> + ubootenv@100000 {<br>
> + label = "u-boot-env";<br>
> reg = <0x0100000 0x40000>;<br>
> read-only;<br>
> };<br>
> @@ -195,25 +195,13 @@ kernel@200000 {<br>
> label = "kernel";<br>
> reg = <0x0200000 0x400000>;<br>
> };<br>
> - rootfs@600000 {<br>
> - label = "rootfs";<br>
> - reg = <0x0600000 0x700000>;<br>
> + rofs@780000 {<br>
> + label = "rofs";<br>
> + reg = <0x0780000 0x1680000>;<br>
> };<br>
> - spare1@D00000 {<br>
> - label = "spare1";<br>
> - reg = <0x0D00000 0x200000>;<br>
> - };<br>
> - spare2@0F00000 {<br>
> - label = "spare2";<br>
> - reg = <0x0F00000 0x200000>;<br>
> - };<br>
> - spare3@1100000 {<br>
> - label = "spare3";<br>
> - reg = <0x1100000 0x200000>;<br>
> - };<br>
> - spare4@1300000 {<br>
> - label = "spare4";<br>
> - reg = <0x1300000 0x0>;<br>
> + rwfs@1e00000 {<br>
> + label = "rwfs";<br>
> + reg = <0x1e00000 0x200000>;<br>
> };<br>
<br>
I recommend just including the openbmc-flash-layout.dtsi file here<br>
instead since that contains the common flash layout for most OpenBMC<br>
systems.<br>
<br></blockquote><div>Good <font face="arial, sans-serif">solution</font>, </div><div>Do you mean nuvoton-openbmc-flash-layout?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> };<br>
> };<br>
> --<br>
> 2.30.0.478.g8a0d178c01-goog<br>
><br></blockquote><div><br></div><div>Thanks,</div><div><br></div><div>Tomer </div></div></div>
</blockquote></div></div>
</blockquote></div>
<br><br><br>---------- Forwarded message ----------<br>From: Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com" target="_blank">bradleyb@fuzziesquirrel.com</a>><br>To: "Wludzik, Jozef" <<a href="mailto:jozef.wludzik@linux.intel.com" target="_blank">jozef.wludzik@linux.intel.com</a>><br>Cc: <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>Bcc: <br>Date: Mon, 1 Mar 2021 10:05:52 -0500<br>Subject: Re: any in-progress Redfish TelemetryService enhancements?<br>On Wed, Feb 24, 2021 at 01:09:56PM +0100, Wludzik, Jozef wrote:<br>
>Hi, "Append" is on the list of to dos and should be ready till summer<br>
>(might be ready). <br>
<br>
That's great! Any chance you could you provide any hints on how you <br>
expect it to be implemented - I'm not sure if I can wait that long to <br>
get started. I would like to make sure that if I start working on it, <br>
it will have your approval from a high level view. If you have not <br>
given it any thought, no problem - I'll come up with a proposal and <br>
report back here.<br>
<br>
<br><br><br>---------- Forwarded message ----------<br>From: Klaus Heinrich Kiwi <<a href="mailto:klaus@linux.vnet.ibm.com" target="_blank">klaus@linux.vnet.ibm.com</a>><br>To: <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>, Joel Stanley <<a href="mailto:joel@jms.id.au" target="_blank">joel@jms.id.au</a>>, Andrew Jeffery <<a href="mailto:andrew@aj.id.au" target="_blank">andrew@aj.id.au</a>>, Ryan Chen <<a href="mailto:ryan_chen@aspeedtech.com" target="_blank">ryan_chen@aspeedtech.com</a>><br>Cc: <br>Bcc: <br>Date: Mon, 1 Mar 2021 16:25:03 -0300<br>Subject: (Aspeed2600) Booting with a SPL loading U-boot fitImage<br>Has anyone been able to successfully bring-up U-boot proper as a fitImage from the SPL, when using U-boot from the 2019.4 Aspeed SDK?<br>
<br>
The current configuration for Rainier (ast2600_openbmc_spl_emmc_defconfig) has, among other things, CONFIG_SPL_LOAD_FIT=y which at the end of the build process should produce a spl/u-boot-spl.bin file (which is really the concatenation of u-boot-spl-nodtb.bin + u-boot-spl.dtb) and a u-boot.img file, which is a FIT image created with 'mkimage -f auto -A arm -T firmware -C none -O u-boot -a 0x10000 -e 0 -n "U-Boot 2019.04"" for evb_ast2600a1 board" -E -d u-boot-nodtb.bin u-boot.img'<br>
<br>
I tried loading this pair using qemu-system-arm (Aspeed 6.0 branch from Cedric Legoater), the SPL loads but fails to load the U-boot fit Image apparently:<br>
<br>
----<br>
$ dd of=mmc-image.img if=/dev/zero bs=1M count=128<br>
$ dd of=mmc-image.img if=../uboot-build/spl/u-boot-spl.bin conv=notrunc<br>
54454 bytes (54 kB, 53 KiB) copied<br>
$ dd of=mmc-image.img if=../uboot-build/u-boot.img conv=notrunc bs=1K seek=64<br>
429640 bytes (430 kB, 420 KiB) copied<br>
$ xzdec tmp/deploy/images/rainier/obmc-phosphor-image-rainier.wic.xz | dd of=mmc-image.img conv=notrunc bs=1M seek=2<br>
$ truncate --size 16G mmc-image.img<br>
$ qemu-system-arm -M rainier-bmc -nographic -drive file=mmc-image.img,if=sd,format=raw,id=sd0,index=2 -nodefaults -serial mon:stdio<br>
<..snip..><br>
aspeed_sdhci_probe: CLK 200000000<br>
ofnode_read_u32: bus-width: x (4)<br>
ofnode_read_u32: sdhci-drive-type: x (1)<br>
clock is disabled (0Hz)<br>
clock is enabled (400000Hz)<br>
clock is enabled (25000000Hz)<br>
blk_find_device: if_type=6, devnum=0: emmc_slot0@100.blk, 6, 0<br>
Jumping to U-Boot<br>
SPL malloc() used 0xf4 bytes (0 KB)<br>
loaded - jumping to U-Boot...<br>
image entry point: 0x81000000<br>
-----<br>
<br>
At this point it just sits there with no progress..<br>
<br>
Another interesting point here is that if I use a legacy uboot image (the concatenation of u-boot-nodtb.bin + u-boot.dtb), I can bring-up u-boot proper and it will work just fine, even if the same defconfig has '# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set'<br>
<br>
----<br>
clock is enabled (25000000Hz)<br>
blk_find_device: if_type=6, devnum=0: emmc_slot0@100.blk, 6, 0<br>
Jumping to U-Boot<br>
SPL malloc() used 0xf4 bytes (0 KB)<br>
loaded - jumping to U-Boot...<br>
image entry point: 0x81000000<br>
<br>
<br>
U-Boot 2019.04 (Feb 27 2021 - 15:21:29 +0000)<br>
<br>
SOC: AST2600-A1<br>
eSPI Mode: SIO:Enable : SuperIO-2e<br>
Eth: MAC0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI<br>
Model: Rainier<br>
DRAM: already initialized, 1008 MiB (capacity:1024 MiB, VGA:64 MiB), ECC off<br>
MMC: emmc_slot0@100: 0<br>
Loading Environment from MMC... OK<br>
In: serial@1e784000<br>
Out: serial@1e784000<br>
Err: serial@1e784000<br>
Model: Rainier<br>
Net: No MDIO found.<br>
ftgmac100_probe - NCSI detected<br>
----<br>
<br>
That probably explains why we have been able to boot the rainier OpenBMC image (even if u-boot is configured to use SPL + U-Boot FIT, the kernel-fitimage.bbclass creates a "new" u-boot image by concatenating the aforementioned binaries).<br>
<br>
I tried a few different settings for the .config and also tried debugging the SPL, but it's a very constrained environment and at this point I'm a bit out of ideas.<br>
<br>
So has anyone been able to make this work?<br>
<br>
<br>
<br>
<br>
-- <br>
Klaus Heinrich Kiwi <<a href="mailto:klaus@linux.vnet.ibm.com" target="_blank">klaus@linux.vnet.ibm.com</a>><br>
<br>
</blockquote></div></div>