Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook

---> That said, I don't understand why it would matter that binaries
are built with Armv5. U-boot should only care about the filesystem
type (e.g. ZFS). So you should be able to build your own filesystem.

I also don't understand why. I'm trying to do is exactly what has been
suggested to do in the site below :

https://forum.doozan.com/read.php?3,49039

scroll down and search these words :

Whether you use "go" or "bootelf", you will need to have some
knowledge about what files are the kernel files in your ARMV5
rootfs.The BSD rootfs must be built for this architecture. And how to
pass parameters to the kernel. Bootelf with API is more powerful, "go"
is primitive.

---> It is it not clear to me whether the last sentence is from you or Elliott

It is from Elliott. I wanted you to know what has been done and what's
missing from the FreeBSD code for arm 32 patched by Elliott. I don't
understand what's the easiest thing to do to fix the problem. I can
barely understand from Elliott's words that fixing the missing low
level hypercalls for arm32 seems to be easy.

What I don't understand is if it requires modifying some code that's
inside the Elliott's github :

https://gitlab.com/ehem/freebsd-src.git

It seems that he patched everything inside his github,but since
something is changed on the FreeBSD side,he won't fix the problem
within his github because he thinks that it is a waste of time. Can
you clone his repo and can you fix what's broken there ? thanks.

---> If you plan to use U-boot, then I recommend you first focus on
U-boot. Then you could look at FreeBSD.

That's the point. I don't know what's the easiest way to go. To use
the off the tree u-boot code (that unfortunately requires to install a
a lot of old packages on FreeBSD 11 because the rootfs require to be
compiled using armv5) or the code that needs to be fixed to allow
FreeBSD to boot as an zImage kernel file. If for you it does not take
a lot of time,I think that would be a nice idea to take the bull by
the horns,allowing FreeBSD to boot as Domu without u-boot,but booting
it as if it was an zImage file.

---> This is likely the culprit. I haven't used FreeBSD for a while,so
I can't advise on how to fix it. If it were me, I would try to
revert the commiting removing the step to create kernel.bin.

No idea about how to do this. I don't even know if I can do that.


On Sat, Dec 30, 2023 at 9:00 PM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 30/12/2023 12:44, Mario Marietto wrote:
> >> https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/
> >
> >> This source code has no support for Xen guests. This was only added in 2020. Can you clarify why you can't use the latest upstream U-boot?
> >
> > It's true. I've got the source code of that custom u-boot
> > implementation in the wrong place. This is the right place :
> >
> > https://forum.doozan.com/read.php?3,49039
> >
> > an u-boot / xen developer suggested to me to explore that site because
> > there is the one and only u-boot customized and off the tree version
> > that can chainload the freebsd bootloader "ubldr". Unfortunately to
> > work the FreeBSD rootfs should be compiled with armV5,but my ARM
> > Chromebook works with armV7. I don't know if armV7 is retrocompatible
> > with armV5.
> > In addition,armV5 has been removed from FreeBSD starting from version
> > 12. Infact Balanga used FreeBSD 11.2. FreeBSD 11 has gone EOL for
> > several years and it's very hard to make it in a usable state today.
>
> I am not entirely sure. The Arm Arm implies that there are some sort of
> compatibility between Armv5 and Armv7, but they also removed some features.
>
> That said, I don't understand why it would matter that binaries are
> built with Armv5. U-boot should only care about the filesystem type
> (e.g. ZFS). So you should be able to build your own filesystem.
>
> >
> > ---> In fact, there are some missing low-level layers (e.g.
> > hypercalls) in order to properly use it for 32-bit domU. I don't know
> > if there is support out-of-tree.
> >
> > @Elliott Mitchell some time ago concerning that point,said :
> >
> > I've only ever tried arm64, but since arm32 didn't appear to need much
> > to be operational I tried to make it possible.  In theory it
> > /should/work on arm32, but I've never tried it.  What was missing was
> > I had never added it to the configuration and one link was needed.
> > Updated "submit" branch has a tiny adjustment. (the only difference is
> > the hypercall wrappers, register naming and where the op code goes,
> > very simple compatibility)
> >
> > I'm not experienced,but it seems to me that only a few patches are
> > needed to make the job done.
>
> It is it not clear to me whether the last sentence is from you or
> Elliott. Regardless that, I think we are talking about two different
> things. Elliott seems to refer to FreeBSD whereas I was referring to U-boot.
>
> If you plan to use U-boot, then I recommend to first focus on U-boot.
> Then you could look at FreeBSD.
>
> > ---> Do you have a tree with FreeBSD + your patches? I would like to
> > check the zImage code.
> >
> > my patches ? Are you talking about the patches that should have been
> > used on the @Elliott Mitchell github ?
>
> I am referring to what ever you are trying.
>
> >
> > https://gitlab.com/ehem/freebsd-src.git
> >
> > yes,I tried to use his code but I've got the same error "invalid kernel"
>
> [...]
>
> > He said that it should work,but I get the error "invalid kernel".
>
> [...]
>
> > It appears FreeBSD-CURRENT removed the last step converting the kernel
> > file to kernel.bin.The patch can be readily rebased, but without
> > kernel.bin that doesn't do too much. So,without a rebase of that patch
> > the first option is not applicable.
>
> This is likely the culprit. I haven't used FreeBSD for a while, so I
> can't advise on how to fix it. If it were me, I would try to revert the
> commiting removing the step to create kernel.bin.
>
> Cheers,
>
> --
> Julien Grall



--
Mario.