Booting fails on the sandbox

Heinrich Schuchardt xypron.glpk at gmx.de
Mon Dec 18 17:19:22 CET 2023



Am 18. Dezember 2023 16:01:36 MEZ schrieb Simon Glass <sjg at chromium.org>:
>Hi Heinrich,
>
>On Sat, 16 Dec 2023 at 14:08, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> On 12/16/23 19:45, Simon Glass wrote:
>> > Hi Heinrich,
>> >
>> > On Sat, 16 Dec 2023 at 07:50, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> >>
>> >> Hello Simon,
>> >>
>> >> I have built sandbox_defconfig with PREBOOT='host bind 0 ../sct.img'
>> >>
>> >> On the image I have an ESP with file EFI/BOOT/BOOTX64.EFI.
>> >>
>> >> I would expect the sandbox to boot from the ESP.
>> >>
>> >> But when starting the sandbox is does not boot. Instead it shows a menu
>> >> with some Fedora related entry:
>> >>
>> >> Fedora-Workstation-armhfp-31-1.9 Boot Options.
>> >> 1:      Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl)
>> >>
>> >> This makes absolutely no sense on an x86_64 system. Could you, please,
>> >> fix sandbox_defconfig to boot according to distroboot.
>> >
>> > What sort of 'fix' are you thinking of? You should be able to discover
>> > all the options with 'bootflow scan' and then use 'bootflow select' or
>> > 'bootflow menu' to choose which one you want.
>> >
>> > The Fedora thing is used for testing and development.
>>
>> I want to autoboot the sandbox without manual intervention. This
>> requires a sane state.
>
>Well, stop doing that :-)
>
>Really, sandbox is for development and CI testing. It is not designed
>to boot anything automatically.

It is the fastest way to run the UEFI SCT. But that requires an EFI compliant dandbox.

How do you want to test the EFI bootflow on the sandbox  when wrecking it?

>
>>
>> If that Fedora thingy is only needed in CI, can't we put it into a
>> config segment that only used by the CI scripts and have the sandbox in
>> a generally usable state? Or can we let the Python tests add the
>> otherwise not needed bootflow?
>
>Yes, we could. We have some extra mmc devices which are manually
>enabled in tests.
>
>But it is handy to be able to try out a distro without doing anything
>special. I suppose we could add a sandbox command to enable an mmc
>device in test.dts
>
>If you have ideas / patches that is fine...it's just that I do want to
>be able to use sandbox for basic development and trying things out.
>
>Regards,
>Simon


More information about the U-Boot mailing list