(Aspeed2600) Booting with a SPL loading U-boot fitImage
Dan Zhang
dz4list at gmail.com
Tue Mar 2 18:54:27 AEDT 2021
I think within A FIT image, the u-boot binary is not located at your entry
point 0x81000000,
it is behind the fit header, somewhere. This means the entry_point and
load_addr is not the same as spl_boot.c defined.
spl_image->entry_point = CONFIG_ASPEED_UBOOT_DRAM_BASE;
spl_image->load_addr = CONFIG_ASPEED_UBOOT_DRAM_BASE;
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.
In fb/OpenBMC, verified boot implementation, use mkimage option:
-p => place external data at a static position,
thus we specify the somewhere to a static offset , then you can set the
entry_point = load_addr + offset.
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.
BRs
Dan
On Mon, Mar 1, 2021 at 11:26 AM <openbmc-request at lists.ozlabs.org> wrote:
> Send openbmc mailing list submissions to
> openbmc at lists.ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.ozlabs.org/listinfo/openbmc
> or, via email, send a message with subject or body 'help' to
> openbmc-request at lists.ozlabs.org
>
> You can reach the person managing the list at
> openbmc-owner at lists.ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openbmc digest..."
> Today's Topics:
>
> 1. Re: [PATCH] ARM: dts: nuvoton: Fix flash layout (Tomer Maimon)
> 2. Re: any in-progress Redfish TelemetryService enhancements?
> (Brad Bishop)
> 3. (Aspeed2600) Booting with a SPL loading U-boot fitImage
> (Klaus Heinrich Kiwi)
>
>
>
> ---------- Forwarded message ----------
> From: Tomer Maimon <tmaimon77 at gmail.com>
> To: Anton Kachalov <gmouse at google.com>
> Cc: Benjamin Fair <benjaminfair at google.com>, Avi Fishman <
> avifishman70 at gmail.com>, Tali Perry <tali.perry1 at gmail.com>, Patrick
> Venture <venture at google.com>, Nancy Yuen <yuenn at google.com>, Rob Herring <
> robh+dt at kernel.org>, OpenBMC Maillist <openbmc at lists.ozlabs.org>,
> devicetree <devicetree at vger.kernel.org>, Linux Kernel Mailing List <
> linux-kernel at vger.kernel.org>
> Bcc:
> Date: Mon, 1 Mar 2021 15:36:58 +0200
> Subject: Re: [PATCH] ARM: dts: nuvoton: Fix flash layout
> Hi Anton,
>
> The reason the u-boot Env is at 0x100000 address is that some
> costumers have:
> one copy of Bootblock and U-boot at 0x0 - 0x80000
> second copy of Bootblock and U-boot at 0x80000 - 0x100000.
>
> we have two options;
> 1. Modify the OpenBMC device tree flash layout u-boot Env address to
> 0x100000.
> 2. Add a patch to OpnBMC platform that using openbmc flash layout to
> modify CONFIG_ENV_OFFSET in the u-boot.
>
> Thanks,
>
> Tomer
>
>
> On Fri, 26 Feb 2021 at 22:10, Anton Kachalov <gmouse at google.com> wrote:
>
>> Hello, Tomer.
>>
>> Seems like Nuvoton's u-boot expects the uboot-env at different address
>> comparing to openbmc-flash-layout.dtsi:
>>
>>
>> https://github.com/Nuvoton-Israel/u-boot/blob/npcm7xx-v2019.01/include/configs/poleg.h#L30
>>
>> Vs.
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/openbmc-flash-layout.dtsi#n13
>>
>> The change is more about making partitions naming the same as expected by
>> OpenBMC.
>>
>> On Sun, 21 Feb 2021 at 17:40, Tomer Maimon <tmaimon77 at gmail.com> wrote:
>>
>>> Hi Benjamin and Anton,
>>>
>>> Sorry for the late reply,
>>>
>>> The EVB FIU0-CS0 partitioning is used for testing the EVB and this is
>>> why it is different than the OpenBMC flash layout.
>>>
>>>
>>>
>>> Are you using the NPCM7XX EVB for OpenBMC? if yes we can consider to
>>> modify the flash partition to OpenBMC use.
>>>
>>> On Thu, 18 Feb 2021 at 19:11, Benjamin Fair <benjaminfair at google.com>
>>> wrote:
>>>
>>>> On Thu, 18 Feb 2021 at 04:42, <gmouse at google.com> wrote:
>>>> >
>>>> > From: "Anton D. Kachalov" <gmouse at google.com>
>>>> >
>>>> > This change satisfy OpenBMC requirements for flash layout.
>>>> >
>>>> > Signed-off-by: Anton D. Kachalov <gmouse at google.com>
>>>> > ---
>>>> > arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 28
>>>> +++++++----------------
>>>> > 1 file changed, 8 insertions(+), 20 deletions(-)
>>>> >
>>>> > diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>>>> b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>>>> > index bd1eb6ee380f..741c1fee8552 100644
>>>> > --- a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>>>> > +++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
>>>> > @@ -182,8 +182,8 @@ bbuboot2 at 80000 {
>>>> > reg = <0x0080000 0x80000>;
>>>> > read-only;
>>>> > };
>>>> > - envparam at 100000 {
>>>> > - label = "env-param";
>>>> > + ubootenv at 100000 {
>>>> > + label = "u-boot-env";
>>>> > reg = <0x0100000 0x40000>;
>>>> > read-only;
>>>> > };
>>>> > @@ -195,25 +195,13 @@ kernel at 200000 {
>>>> > label = "kernel";
>>>> > reg = <0x0200000 0x400000>;
>>>> > };
>>>> > - rootfs at 600000 {
>>>> > - label = "rootfs";
>>>> > - reg = <0x0600000 0x700000>;
>>>> > + rofs at 780000 {
>>>> > + label = "rofs";
>>>> > + reg = <0x0780000 0x1680000>;
>>>> > };
>>>> > - spare1 at D00000 {
>>>> > - label = "spare1";
>>>> > - reg = <0x0D00000 0x200000>;
>>>> > - };
>>>> > - spare2 at 0F00000 {
>>>> > - label = "spare2";
>>>> > - reg = <0x0F00000 0x200000>;
>>>> > - };
>>>> > - spare3 at 1100000 {
>>>> > - label = "spare3";
>>>> > - reg = <0x1100000 0x200000>;
>>>> > - };
>>>> > - spare4 at 1300000 {
>>>> > - label = "spare4";
>>>> > - reg = <0x1300000 0x0>;
>>>> > + rwfs at 1e00000 {
>>>> > + label = "rwfs";
>>>> > + reg = <0x1e00000 0x200000>;
>>>> > };
>>>>
>>>> I recommend just including the openbmc-flash-layout.dtsi file here
>>>> instead since that contains the common flash layout for most OpenBMC
>>>> systems.
>>>>
>>>> Good solution,
>>> Do you mean nuvoton-openbmc-flash-layout?
>>>
>>>> > };
>>>> > };
>>>> > --
>>>> > 2.30.0.478.g8a0d178c01-goog
>>>> >
>>>>
>>>
>>> Thanks,
>>>
>>> Tomer
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: Brad Bishop <bradleyb at fuzziesquirrel.com>
> To: "Wludzik, Jozef" <jozef.wludzik at linux.intel.com>
> Cc: openbmc at lists.ozlabs.org
> Bcc:
> Date: Mon, 1 Mar 2021 10:05:52 -0500
> Subject: Re: any in-progress Redfish TelemetryService enhancements?
> On Wed, Feb 24, 2021 at 01:09:56PM +0100, Wludzik, Jozef wrote:
> >Hi, "Append" is on the list of to dos and should be ready till summer
> >(might be ready).
>
> That's great! Any chance you could you provide any hints on how you
> expect it to be implemented - I'm not sure if I can wait that long to
> get started. I would like to make sure that if I start working on it,
> it will have your approval from a high level view. If you have not
> given it any thought, no problem - I'll come up with a proposal and
> report back here.
>
>
>
>
> ---------- Forwarded message ----------
> From: Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>
> To: openbmc at lists.ozlabs.org, Joel Stanley <joel at jms.id.au>, Andrew
> Jeffery <andrew at aj.id.au>, Ryan Chen <ryan_chen at aspeedtech.com>
> Cc:
> Bcc:
> Date: Mon, 1 Mar 2021 16:25:03 -0300
> Subject: (Aspeed2600) Booting with a SPL loading U-boot fitImage
> 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?
>
> 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'
>
> 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:
>
> ----
> $ dd of=mmc-image.img if=/dev/zero bs=1M count=128
> $ dd of=mmc-image.img if=../uboot-build/spl/u-boot-spl.bin conv=notrunc
> 54454 bytes (54 kB, 53 KiB) copied
> $ dd of=mmc-image.img if=../uboot-build/u-boot.img conv=notrunc bs=1K
> seek=64
> 429640 bytes (430 kB, 420 KiB) copied
> $ xzdec tmp/deploy/images/rainier/obmc-phosphor-image-rainier.wic.xz | dd
> of=mmc-image.img conv=notrunc bs=1M seek=2
> $ truncate --size 16G mmc-image.img
> $ qemu-system-arm -M rainier-bmc -nographic -drive
> file=mmc-image.img,if=sd,format=raw,id=sd0,index=2 -nodefaults -serial
> mon:stdio
> <..snip..>
> aspeed_sdhci_probe: CLK 200000000
> ofnode_read_u32: bus-width: x (4)
> ofnode_read_u32: sdhci-drive-type: x (1)
> clock is disabled (0Hz)
> clock is enabled (400000Hz)
> clock is enabled (25000000Hz)
> blk_find_device: if_type=6, devnum=0: emmc_slot0 at 100.blk, 6, 0
> Jumping to U-Boot
> SPL malloc() used 0xf4 bytes (0 KB)
> loaded - jumping to U-Boot...
> image entry point: 0x81000000
> -----
>
> At this point it just sits there with no progress..
>
> 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'
>
> ----
> clock is enabled (25000000Hz)
> blk_find_device: if_type=6, devnum=0: emmc_slot0 at 100.blk, 6, 0
> Jumping to U-Boot
> SPL malloc() used 0xf4 bytes (0 KB)
> loaded - jumping to U-Boot...
> image entry point: 0x81000000
>
>
> U-Boot 2019.04 (Feb 27 2021 - 15:21:29 +0000)
>
> SOC: AST2600-A1
> eSPI Mode: SIO:Enable : SuperIO-2e
> Eth: MAC0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI
> Model: Rainier
> DRAM: already initialized, 1008 MiB (capacity:1024 MiB, VGA:64 MiB), ECC
> off
> MMC: emmc_slot0 at 100: 0
> Loading Environment from MMC... OK
> In: serial at 1e784000
> Out: serial at 1e784000
> Err: serial at 1e784000
> Model: Rainier
> Net: No MDIO found.
> ftgmac100_probe - NCSI detected
> ----
>
> 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).
>
> 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.
>
> So has anyone been able to make this work?
>
>
>
>
> --
> Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210301/889a95a7/attachment-0001.htm>
More information about the openbmc
mailing list