RE: (Aspeed2600) Booting with a SPL loading U-boot fitImage

RE: (Aspeed2600) Booting with a SPL loading U-boot fitImage

[Dan Zhang]

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

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@lists.ozlabs.org> wrote:

> Send openbmc mailing list submissions to
>         openbmc@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@lists.ozlabs.org
>
> You can reach the person managing the list at
>         openbmc-owner@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@gmail.com>
> To: Anton Kachalov <gmouse@google.com>
> Cc: Benjamin Fair <benjaminfair@google.com>, Avi Fishman <
> avifishman70@gmail.com>, Tali Perry <tali.perry1@gmail.com>, Patrick
> Venture <venture@google.com>, Nancy Yuen <yuenn@google.com>, Rob Herring <
> robh+dt@kernel.org>, OpenBMC Maillist <openbmc@lists.ozlabs.org>,
> devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <
> linux-kernel@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@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@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@google.com>
>>> wrote:
>>>
>>>> On Thu, 18 Feb 2021 at 04:42, <gmouse@google.com> wrote:
>>>> >
>>>> > From: "Anton D. Kachalov" <gmouse@google.com>
>>>> >
>>>> > This change satisfy OpenBMC requirements for flash layout.
>>>> >
>>>> > Signed-off-by: Anton D. Kachalov <gmouse@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@80000 {
>>>> >                                 reg = <0x0080000 0x80000>;
>>>> >                                 read-only;
>>>> >                                 };
>>>> > -                       envparam@100000 {
>>>> > -                               label = "env-param";
>>>> > +                       ubootenv@100000 {
>>>> > +                               label = "u-boot-env";
>>>> >                                 reg = <0x0100000 0x40000>;
>>>> >                                 read-only;
>>>> >                                 };
>>>> > @@ -195,25 +195,13 @@ kernel@200000 {
>>>> >                                 label = "kernel";
>>>> >                                 reg = <0x0200000 0x400000>;
>>>> >                                 };
>>>> > -                       rootfs@600000 {
>>>> > -                               label = "rootfs";
>>>> > -                               reg = <0x0600000 0x700000>;
>>>> > +                       rofs@780000 {
>>>> > +                               label = "rofs";
>>>> > +                               reg = <0x0780000 0x1680000>;
>>>> >                                 };
>>>> > -                       spare1@D00000 {
>>>> > -                               label = "spare1";
>>>> > -                               reg = <0x0D00000 0x200000>;
>>>> > -                               };
>>>> > -                       spare2@0F00000 {
>>>> > -                               label = "spare2";
>>>> > -                               reg = <0x0F00000 0x200000>;
>>>> > -                               };
>>>> > -                       spare3@1100000 {
>>>> > -                               label = "spare3";
>>>> > -                               reg = <0x1100000 0x200000>;
>>>> > -                               };
>>>> > -                       spare4@1300000 {
>>>> > -                               label = "spare4";
>>>> > -                               reg = <0x1300000 0x0>;
>>>> > +                       rwfs@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@fuzziesquirrel.com>
> To: "Wludzik, Jozef" <jozef.wludzik@linux.intel.com>
> Cc: openbmc@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@linux.vnet.ibm.com>
> To: openbmc@lists.ozlabs.org, Joel Stanley <joel@jms.id.au>, Andrew
> Jeffery <andrew@aj.id.au>, Ryan Chen <ryan_chen@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@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@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@100: 0
> Loading Environment from MMC... OK
> In:    serial@1e784000
> Out:   serial@1e784000
> Err:   serial@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@linux.vnet.ibm.com>
>
>

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

Re: (Aspeed2600) Booting with a SPL loading U-boot fitImage

[Klaus Heinrich Kiwi]

On 3/2/2021 4:54 AM, Dan Zhang wrote:

> 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.

I think it's not that simple. See my answer (to myself) in this same thread with new information.
  
> 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.

Verified boot should work if you are having u-boot proper validating the Linux Kernel fitimage, but I don't see how the Aspeed 2600 SPL would be able to load and verify the u-boot proper fitimage - the code simply isn't there..

It seems to me that the SPL_LOAD_FIT code should handle recognizing the fitimage, moving it's 'loadables' images into memory and setting the entry point accordingly.

  -Klaus

Re: (Aspeed2600) Booting with a SPL loading U-boot fitImage

[Dan Zhang]

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

FB/Verified-boot uses u-boot proper fit-image to reuse the fit sign and
verification code to load and verify u-boot and subordinate keys.
the booting and verify process is:
SPL :
 1. verify subordinate-keys within the u-boot proper fitimage.
 2. use the verified subordinate-keys to verify the u-boot and load it.
U-boot proper:
  1. use subordinate-keys verify os ( kernel, rootfs and fdt).

Refer to code below for how to create the u-boot proper fit-image.
https://github.com/facebook/openbmc/blob/helium/meta-aspeed/classes/kernel_fitimage.bbclass

Refer to code below for SPL verify and load u-boot proper fit. This is
quite a hack, not using the SPL image loading framework.
https://github.com/facebook/openbmc-uboot/blob/2fcac0176e5542a47e06e15d5052e6fb78c7432e/board/aspeed/ast-g5/ast-g5-spl.c#L483

BRs
Dan

On Tue, Mar 2, 2021 at 5:21 AM Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
wrote:

>
>
> On 3/2/2021 4:54 AM, Dan Zhang wrote:
>
> > 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.
>
> I think it's not that simple. See my answer (to myself) in this same
> thread with new information.
>
> > 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.
>
> Verified boot should work if you are having u-boot proper validating the
> Linux Kernel fitimage, but I don't see how the Aspeed 2600 SPL would be
> able to load and verify the u-boot proper fitimage - the code simply isn't
> there..
>
> It seems to me that the SPL_LOAD_FIT code should handle recognizing the
> fitimage, moving it's 'loadables' images into memory and setting the entry
> point accordingly.
>
>   -Klaus
>

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

Re: (Aspeed2600) Booting with a SPL loading U-boot fitImage

[Klaus Heinrich Kiwi]

On 3/1/2021 4:25 PM, Klaus Heinrich Kiwi wrote:
> 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?


I spent a bit more time reading through the Aspeed SDK U-boot code and I think this is simply not implemented, and actually might explain why a Legacy Uboot image loads, even if Legacy Image is not enabled in the config...

So arch/arm/mach-aspeed/ast2600/utils.S defines the ast2600 ast_bootmode() to be one of 'AST_BOOTMODE_UART', 'AST_BOOTMODE_SPI' or 'AST_BOOTMODE_EMMC' based on hw strapping info and arch/arm/mach-aspeed/ast2600/spl.c:spl_boot_device() uses that to instruct the SPL which (of these 3 methods) to use...

The SPL is being built with multiple (redundant?) image loaders:

0000e5d0 D _u_boot_list_2_spl_image_loader_2_aspeed_spl_mmc_load_image0ASPEED_BOOT_DEVICE_MMC
0000e5dc D _u_boot_list_2_spl_image_loader_2_aspeed_spl_ram_load_image0ASPEED_BOOT_DEVICE_RAM
0000e5e8 D _u_boot_list_2_spl_image_loader_2_aspeed_spl_ymodem_load_image0ASPEED_BOOT_DEVICE_UART
0000e5f4 D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC1
0000e600 D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC2
0000e60c D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC2_2
0000e618 D _u_boot_list_2_spl_image_loader_2_spl_ram_load_image0BOOT_DEVICE_RAM
0000e624 D _u_boot_list_2_spl_image_loader_2_spl_ymodem_load_image0BOOT_DEVICE_UART

But the ast_bootmode() causes only the aspeed_spl_*_load_image() to be really used.

And if we compare the aspeed versions (from arch/arm/mach-aspeed/ast2600/spl_boot.c) with the common versions (common/spl/spl_mmc.c), we clearly see that the common version has the infrastructure to detect and load the FIT, while the aspeed version is simply loading the raw contents of the mmc into RAM and setting the entry point to it's start (that means: treating the mmc contents as a legacy u-boot image regardless).

I guess that the amount of coding required to catch-up 'aspeed_secboot_spl_*_load_image' with the necessary SPL_LOAD_FIT infrastructure is not trivial, so I'm hoping that the other way around (using the common infrastructure) is easier - Joel, Ryan, any comments?

It would also help in avoiding redundant symbols, since the way it is we cannot fit everything we need in the SPL + SPL DTB in 64KB anyway...

  -Klaus

-- 
Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>

(Aspeed2600) Booting with a SPL loading U-boot fitImage

[Klaus Heinrich Kiwi]

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@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@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@100: 0
Loading Environment from MMC... OK
In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@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@linux.vnet.ibm.com>