Mailing List Archive

>
> Julien said that I could try to revert the commiting removing the step
> to create kernel.bin,but I don't know what it means,I don't know how
> to do that and I haven't found anyone who wants to explain to me how
> to do it. And I'm not sure that it will be enough.
>

You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file.
We turned that off by default since most people don't need/can't use that
file.

Warner

Thanks Warner. But the kernel.bin file should be used instead of the u-boot
file as bootloader ? and will it work as expected ? even if i have patched
the elliott code with the wrong patch ? thats because I havent a working
patch to use that can allow the frrebsd code to be threated as an zImage
file ?

Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com> ha scritto:

> Julien said that I could try to revert the commiting removing the step
>> to create kernel.bin,but I don't know what it means,I don't know how
>> to do that and I haven't found anyone who wants to explain to me how
>> to do it. And I'm not sure that it will be enough.
>>
>
> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file.
> We turned that off by default since most people don't need/can't use that
> file.
>
> Warner
>

So kernel.bin is expected to be loaded, by u-boot, using the 'load' command
at a specific address. On arm, this can be any 2MB boundary. Once it is
loaded, you jump to the _start address woth the 'go' command. The
kernel.bin file doesn't have symbols, so you'll need to see where _start
winds up at.

So, let's say that the memory starts at 0x80000000 and _start is something
like 0xc0000020 when you nm kernel | grep start you'd do something like:

u-boot> load kernel.bin 0x80000000
u-boot> go 0x80000020

Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen can
load it at a specific spot (and maybe your hunch is right that you can
replace uboot with this binary... ive never xen booted like this so i don't
know if you need the low level steps uboot preforms to be done or not). I
suspect that it might and my info is just for raw hardware...

Warner

On Mon, Jan 1, 2024, 12:47?PM Mario Marietto <marietto2008@gmail.com> wrote:

> Thanks Warner. But the kernel.bin file should be used instead of the
> u-boot file as bootloader ? and will it work as expected ? even if i have
> patched the elliott code with the wrong patch ? thats because I havent a
> working patch to use that can allow the frrebsd code to be threated as an
> zImage file ?
>
> Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com> ha scritto:
>
>> Julien said that I could try to revert the commiting removing the step
>>> to create kernel.bin,but I don't know what it means,I don't know how
>>> to do that and I haven't found anyone who wants to explain to me how
>>> to do it. And I'm not sure that it will be enough.
>>>
>>
>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file.
>> We turned that off by default since most people don't need/can't use that
>> file.
>>
>> Warner
>>
>

I still see too many variables in the equation. I need to eliminate
some of them. So :

1) Do I need to patch the file locore-v6.S with the Julien's patch ?
---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd

2) What kind of u-boot are you talking about ? Where should I get it ?

@balanga (a nice enthusiastic 'hacker') helped me to solve half part
of the u-boot equation,giving to me this suggestion :


"If you simply want me to extract :

http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2-RELEASE/src.txz

and run make TARGET_ARCH=armv5 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel"


so,theoretically in this way I have the ARMv5 rootfs (and the freebsd
kernel file) that will boot with the proper version of u-boot,as has
been explained here :
https://forum.doozan.com/read.php?3,49039,136530#msg-136530


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


The other half part of the equation is related to u-boot. On the
doozan forum has been explained that has been created the Kirkwood
(Armv5) u-boot. I've asked the link where to grab it,because I could
try to chainload "ubldr" using that version of u-boot with the ARMv5
rootfs that balanga explained to me how to create.

I could try,but I don't see the utility. Infact armV5 is dead as well
as FreeBSD 11.2 for i386. I think that to follow the road of using
u-boot for Kirkwood is a waste of time. I think that the right thing
to do is to fix the main problems which FreeBSD is affected by : that
it can't be booted as an zImage file by xen. It needs to be patched.
And there are some missing hypercalls for arm32.

Using u-boot for armV5 complicates things a lot and forces me to use a
dead version of FreeBSD.

On Mon, Jan 1, 2024 at 9:48?PM Warner Losh <imp@bsdimp.com> wrote:
>
> So kernel.bin is expected to be loaded, by u-boot, using the 'load' command at a specific address. On arm, this can be any 2MB boundary. Once it is loaded, you jump to the _start address woth the 'go' command. The kernel.bin file doesn't have symbols, so you'll need to see where _start winds up at.
>
> So, let's say that the memory starts at 0x80000000 and _start is something like 0xc0000020 when you nm kernel | grep start you'd do something like:
>
> u-boot> load kernel.bin 0x80000000
> u-boot> go 0x80000020
>
> Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen can load it at a specific spot (and maybe your hunch is right that you can replace uboot with this binary... ive never xen booted like this so i don't know if you need the low level steps uboot preforms to be done or not). I suspect that it might and my info is just for raw hardware...
>
> Warner
>
> On Mon, Jan 1, 2024, 12:47?PM Mario Marietto <marietto2008@gmail.com> wrote:
>>
>> Thanks Warner. But the kernel.bin file should be used instead of the u-boot file as bootloader ? and will it work as expected ? even if i have patched the elliott code with the wrong patch ? thats because I havent a working patch to use that can allow the frrebsd code to be threated as an zImage file ?
>>
>> Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com> ha scritto:
>>>>
>>>> Julien said that I could try to revert the commiting removing the step
>>>> to create kernel.bin,but I don't know what it means,I don't know how
>>>> to do that and I haven't found anyone who wants to explain to me how
>>>> to do it. And I'm not sure that it will be enough.
>>>
>>>
>>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file.
>>> We turned that off by default since most people don't need/can't use that
>>> file.
>>>
>>> Warner



--
Mario.

Anyway,the suggestion of @balanga didn't work. This is what happened
when I tried :

# mv /usr/src /usr/src-old
# cd /usr
# wget http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2-RELEASE/src.txz
# xz -d src.txz
# cd src
# make TARGET_ARCH=armv5 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel

make[1] : "/usr/src/Makefile.inc1" line 405 : unknown target armv5:armv5.
Error code 1.

On Tue, Jan 2, 2024 at 12:03?AM Mario Marietto <marietto2008@gmail.com> wrote:
>
> I still see too many variables in the equation. I need to eliminate
> some of them. So :
>
> 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
> ---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>
> 2) What kind of u-boot are you talking about ? Where should I get it ?
>
> @balanga (a nice enthusiastic 'hacker') helped me to solve half part
> of the u-boot equation,giving to me this suggestion :
>
>
> "If you simply want me to extract :
>
> http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2-RELEASE/src.txz
>
> and run make TARGET_ARCH=armv5 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel"
>
>
> so,theoretically in this way I have the ARMv5 rootfs (and the freebsd
> kernel file) that will boot with the proper version of u-boot,as has
> been explained here :
> https://forum.doozan.com/read.php?3,49039,136530#msg-136530
>
>
> "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"
>
>
> The other half part of the equation is related to u-boot. On the
> doozan forum has been explained that has been created the Kirkwood
> (Armv5) u-boot. I've asked the link where to grab it,because I could
> try to chainload "ubldr" using that version of u-boot with the ARMv5
> rootfs that balanga explained to me how to create.
>
> I could try,but I don't see the utility. Infact armV5 is dead as well
> as FreeBSD 11.2 for i386. I think that to follow the road of using
> u-boot for Kirkwood is a waste of time. I think that the right thing
> to do is to fix the main problems which FreeBSD is affected by : that
> it can't be booted as an zImage file by xen. It needs to be patched.
> And there are some missing hypercalls for arm32.
>
> Using u-boot for armV5 complicates things a lot and forces me to use a
> dead version of FreeBSD.
>
> On Mon, Jan 1, 2024 at 9:48?PM Warner Losh <imp@bsdimp.com> wrote:
> >
> > So kernel.bin is expected to be loaded, by u-boot, using the 'load' command at a specific address. On arm, this can be any 2MB boundary. Once it is loaded, you jump to the _start address woth the 'go' command. The kernel.bin file doesn't have symbols, so you'll need to see where _start winds up at.
> >
> > So, let's say that the memory starts at 0x80000000 and _start is something like 0xc0000020 when you nm kernel | grep start you'd do something like:
> >
> > u-boot> load kernel.bin 0x80000000
> > u-boot> go 0x80000020
> >
> > Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen can load it at a specific spot (and maybe your hunch is right that you can replace uboot with this binary... ive never xen booted like this so i don't know if you need the low level steps uboot preforms to be done or not). I suspect that it might and my info is just for raw hardware...
> >
> > Warner
> >
> > On Mon, Jan 1, 2024, 12:47?PM Mario Marietto <marietto2008@gmail.com> wrote:
> >>
> >> Thanks Warner. But the kernel.bin file should be used instead of the u-boot file as bootloader ? and will it work as expected ? even if i have patched the elliott code with the wrong patch ? thats because I havent a working patch to use that can allow the frrebsd code to be threated as an zImage file ?
> >>
> >> Il lun 1 gen 2024, 20:39 Warner Losh <imp@bsdimp.com> ha scritto:
> >>>>
> >>>> Julien said that I could try to revert the commiting removing the step
> >>>> to create kernel.bin,but I don't know what it means,I don't know how
> >>>> to do that and I haven't found anyone who wants to explain to me how
> >>>> to do it. And I'm not sure that it will be enough.
> >>>
> >>>
> >>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file.
> >>> We turned that off by default since most people don't need/can't use that
> >>> file.
> >>>
> >>> Warner
>
>
>
> --
> Mario.



--
Mario.

Hi,

On 01/01/2024 23:03, Mario Marietto wrote:
> I still see too many variables in the equation. I need to eliminate
> some of them. So :
>
> 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
> ---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd

I believe so otherwise XL will not know how to load the binary file (see
below).

>
> 2) What kind of u-boot are you talking about ? Where should I get it ?
You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to
load it from the dom0 filesystem. The option in the xl configuration is

kernel='<path-to-binary>'

Cheers,

--
Julien Grall

@Warner Losh :

Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
tried in several ways,but it is not accepted :

$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
WITH_KERNEL_BIN = wrong

$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
buildkernel = wrong

$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong

$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong

How is it ?



On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 01/01/2024 23:03, Mario Marietto wrote:
> > I still see too many variables in the equation. I need to eliminate
> > some of them. So :
> >
> > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
> > ---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>
> I believe so otherwise XL will not know how to load the binary file (see
> below).
>
> >
> > 2) What kind of u-boot are you talking about ? Where should I get it ?
> You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to
> load it from the dom0 filesystem. The option in the xl configuration is
>
> kernel='<path-to-binary>'
>
> Cheers,
>
> --
> Julien Grall



--
Mario.

Ok. I've found the solution reading here :

https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2

So on FreeBSD 15.0-CURRENT I did :

nano /etc/src.conf
WITH_KERNEL_BIN=1
(WITH_KERNEL_BIN is wrong)

$ cd /usr
$ git clone https://gitlab.com/ehem/freebsd-src.git
$ cd freebsd-src
$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
installkernel

Unfortunately I get this error :

*kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*

and the kernel.bin file is not generated.

experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
/etc/src.conf ;

I've added the parameter :

makeoptions WITH_KERNEL_BIN=1

to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"

and then I've launched again the compilation :

$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
$ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
installkernel

Unfortunately I've got the same error as before and the kernel.bin file
hasn't been produced as well.


On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> @Warner Losh :
>
> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
> tried in several ways,but it is not accepted :
>
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
> WITH_KERNEL_BIN = wrong
>
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
> buildkernel = wrong
>
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>
> How is it ?
>
>
>
> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
> >
> > Hi,
> >
> > On 01/01/2024 23:03, Mario Marietto wrote:
> > > I still see too many variables in the equation. I need to eliminate
> > > some of them. So :
> > >
> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
> > > --->
> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
> >
> > I believe so otherwise XL will not know how to load the binary file (see
> > below).
> >
> > >
> > > 2) What kind of u-boot are you talking about ? Where should I get it ?
> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to
> > load it from the dom0 filesystem. The option in the xl configuration is
> >
> > kernel='<path-to-binary>'
> >
> > Cheers,
> >
> > --
> > Julien Grall
>
>
>
> --
> Mario.
>


--
Mario.

Sorry I forgot to change the name of the kernel :

# cd /usr/freebsd-src/sys/arm/conf
# cp GENERIC MYKERNEL

# nano MYKERNEL
makeoptions WITH_KERNEL_BIN=1

# make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
# make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
installkernel

same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
relocation table found.*

On Fri, Jan 5, 2024 at 7:48?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Ok. I've found the solution reading here :
>
>
> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2
>
> So on FreeBSD 15.0-CURRENT I did :
>
> nano /etc/src.conf
> WITH_KERNEL_BIN=1
> (WITH_KERNEL_BIN is wrong)
>
> $ cd /usr
> $ git clone https://gitlab.com/ehem/freebsd-src.git
> $ cd freebsd-src
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> Unfortunately I get this error :
>
> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*
>
> and the kernel.bin file is not generated.
>
> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
> /etc/src.conf ;
>
> I've added the parameter :
>
> makeoptions WITH_KERNEL_BIN=1
>
> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"
>
> and then I've launched again the compilation :
>
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> Unfortunately I've got the same error as before and the kernel.bin file
> hasn't been produced as well.
>
>
> On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> @Warner Losh :
>>
>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
>> tried in several ways,but it is not accepted :
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>> WITH_KERNEL_BIN = wrong
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
>> buildkernel = wrong
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>>
>> How is it ?
>>
>>
>>
>> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>> >
>> > Hi,
>> >
>> > On 01/01/2024 23:03, Mario Marietto wrote:
>> > > I still see too many variables in the equation. I need to eliminate
>> > > some of them. So :
>> > >
>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
>> > > --->
>> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>> >
>> > I believe so otherwise XL will not know how to load the binary file (see
>> > below).
>> >
>> > >
>> > > 2) What kind of u-boot are you talking about ? Where should I get it ?
>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl' to
>> > load it from the dom0 filesystem. The option in the xl configuration is
>> >
>> > kernel='<path-to-binary>'
>> >
>> > Cheers,
>> >
>> > --
>> > Julien Grall
>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.

Thanks to your valuable help,I've been able to produce the kernel.bin
file,applying the patch of Julien Grall to the Elliott Mitchell code and
enabling the parameter "WITH_KERNEL_BIN=1" to the FreeBSD kernel config
file. At this point I created a freebsd.cfg file like this one :

name="freebsd"
kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

extra = "console=hvc0"
memory=512
vcpus=1
disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

and with this start-freebsd script :

xl create freebsd.cfg
xl console freebsd

and ran it :

# ./start-freebsd

Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found:
Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 3:cannot
(re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
3:Non-existent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 3:Unable
to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 3:Destruction
of domain failed
freebsd is an invalid domain identifier (rc=-6)

It seems the same error that I always get. Should I make some modification
inside the FreeBSD-13.2-RELEASE-armv7.img image file ? Because I haven't
touched it ; it still has the default booting system files.

On Fri, Jan 5, 2024 at 10:20?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Sorry I forgot to change the name of the kernel :
>
> # cd /usr/freebsd-src/sys/arm/conf
> # cp GENERIC MYKERNEL
>
> # nano MYKERNEL
> makeoptions WITH_KERNEL_BIN=1
>
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
> relocation table found.*
>
> On Fri, Jan 5, 2024 at 7:48?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Ok. I've found the solution reading here :
>>
>>
>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2
>>
>> So on FreeBSD 15.0-CURRENT I did :
>>
>> nano /etc/src.conf
>> WITH_KERNEL_BIN=1
>> (WITH_KERNEL_BIN is wrong)
>>
>> $ cd /usr
>> $ git clone https://gitlab.com/ehem/freebsd-src.git
>> $ cd freebsd-src
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>> installkernel
>>
>> Unfortunately I get this error :
>>
>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*
>>
>> and the kernel.bin file is not generated.
>>
>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
>> /etc/src.conf ;
>>
>> I've added the parameter :
>>
>> makeoptions WITH_KERNEL_BIN=1
>>
>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"
>>
>> and then I've launched again the compilation :
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>> installkernel
>>
>> Unfortunately I've got the same error as before and the kernel.bin file
>> hasn't been produced as well.
>>
>>
>> On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> @Warner Losh :
>>>
>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
>>> tried in several ways,but it is not accepted :
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> WITH_KERNEL_BIN = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
>>> buildkernel = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>>>
>>> How is it ?
>>>
>>>
>>>
>>> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On 01/01/2024 23:03, Mario Marietto wrote:
>>> > > I still see too many variables in the equation. I need to eliminate
>>> > > some of them. So :
>>> > >
>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
>>> > > --->
>>> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>>> >
>>> > I believe so otherwise XL will not know how to load the binary file
>>> (see
>>> > below).
>>> >
>>> > >
>>> > > 2) What kind of u-boot are you talking about ? Where should I get it
>>> ?
>>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl'
>>> to
>>> > load it from the dom0 filesystem. The option in the xl configuration is
>>> >
>>> > kernel='<path-to-binary>'
>>> >
>>> > Cheers,
>>> >
>>> > --
>>> > Julien Grall
>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>


--
Mario.

Hi,

On 05/01/2024 21:20, Mario Marietto wrote:
> Sorry I forgot to change the name of the kernel :
>
> # cd /usr/freebsd-src/sys/arm/conf
> # cp GENERIC MYKERNEL
>
> # nano MYKERNEL
> makeoptions WITH_KERNEL_BIN=1
>
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
> relocation table found.*

Are all the sections in ELF contiguous in memory? If so, you could try
to use manually objcopy. Something like:

objcopy -O binary -S <your-elf> <output-binary>

Then use 'file' to check if the format is recognized as zImage. If so,
you could use it in your xl configuration.

Note that this *might* be what KERNEL_BIN is doing underhood. But I
haven't checked not nor I am familiar with the area. I am only proposing
something that may get you unstuck for now. You can come back to fix the
problem afterwards.

Cheers,

--
Julien Grall

On 07/01/2024 22:41, Mario Marietto wrote:
> Thanks to your valuable help,I've been able to produce the kernel.bin
> file,applying the patch of Julien Grall to the Elliott Mitchell code and
> enabling the parameter "WITH_KERNEL_BIN=1" to the FreeBSD kernel config
> file. At this point I created a freebsd.cfg file like this one :
>
> name="freebsd"
> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
> extra = "console=hvc0"
> memory=512
> vcpus=1
> disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> and with this start-freebsd script :
>
> xl create freebsd.cfg
> xl console freebsd
>
> and ran it :
>
> # ./start-freebsd
>
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader
> found: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain
> 3:cannot (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> 3:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
> 3:Unable to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
> 3:Destruction of domain failed
> freebsd is an invalid domain identifier (rc=-6)
>
> It seems the same error that I always get. Should I make some
> modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ?
> Because I haven't touched it ; it still has the default booting system
> files.

What's the output of the command 'file'? Is this reporting an ELF or a
binary?

If the latter, can you check where the zImage header is added at the
front of the binary?

Cheers,

--
Julien Grall

# file kernel.bin
kernel.bin: data

---> If the latter, can you check where the zImage header is added at the
front of the binary ?

How ?

On Sun, Jan 7, 2024 at 11:46?PM Julien Grall <julien@xen.org> wrote:

>
>
> On 07/01/2024 22:41, Mario Marietto wrote:
> > Thanks to your valuable help,I've been able to produce the kernel.bin
> > file,applying the patch of Julien Grall to the Elliott Mitchell code and
> > enabling the parameter "WITH_KERNEL_BIN=1" to the FreeBSD kernel config
> > file. At this point I created a freebsd.cfg file like this one :
> >
> > name="freebsd"
> >
> kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"
> > extra = "console=hvc0"
> > memory=512
> > vcpus=1
> > disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
> >
> > and with this start-freebsd script :
> >
> > xl create freebsd.cfg
> > xl console freebsd
> >
> > and ran it :
> >
> > # ./start-freebsd
> >
> > Parsing config from freebsd.cfg
> > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader
> > found: Invalid kernel
> > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
> > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain
> > 3:cannot (re-)build domain: -3
> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> > 3:Non-existent domain
> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
> > 3:Unable to destroy guest
> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
> > 3:Destruction of domain failed
> > freebsd is an invalid domain identifier (rc=-6)
> >
> > It seems the same error that I always get. Should I make some
> > modification inside the FreeBSD-13.2-RELEASE-armv7.img image file ?
> > Because I haven't touched it ; it still has the default booting system
> > files.
>
> What's the output of the command 'file'? Is this reporting an ELF or a
> binary?
>
> If the latter, can you check where the zImage header is added at the
> front of the binary?
>
> Cheers,
>
> --
> Julien Grall
>


--
Mario.

Sorry for the late replies...

On Fri, Jan 5, 2024 at 2:20?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> Sorry I forgot to change the name of the kernel :
>
> # cd /usr/freebsd-src/sys/arm/conf
> # cp GENERIC MYKERNEL
>
> # nano MYKERNEL
> makeoptions WITH_KERNEL_BIN=1
>
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
> relocation table found.*
>

This error can be ignored... It's telling you it can't index the kernel.
That's fine. If this is kernel.bin in reality,
then it's to be expected: kernel.bin is a fully linked binary.

Warner


> On Fri, Jan 5, 2024 at 7:48?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Ok. I've found the solution reading here :
>>
>>
>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2
>>
>> So on FreeBSD 15.0-CURRENT I did :
>>
>> nano /etc/src.conf
>> WITH_KERNEL_BIN=1
>> (WITH_KERNEL_BIN is wrong)
>>
>> $ cd /usr
>> $ git clone https://gitlab.com/ehem/freebsd-src.git
>> $ cd freebsd-src
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>> installkernel
>>
>> Unfortunately I get this error :
>>
>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*
>>
>> and the kernel.bin file is not generated.
>>
>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
>> /etc/src.conf ;
>>
>> I've added the parameter :
>>
>> makeoptions WITH_KERNEL_BIN=1
>>
>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"
>>
>> and then I've launched again the compilation :
>>
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>> installkernel
>>
>> Unfortunately I've got the same error as before and the kernel.bin file
>> hasn't been produced as well.
>>
>>
>> On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> @Warner Losh :
>>>
>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
>>> tried in several ways,but it is not accepted :
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> WITH_KERNEL_BIN = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
>>> buildkernel = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>>>
>>> How is it ?
>>>
>>>
>>>
>>> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On 01/01/2024 23:03, Mario Marietto wrote:
>>> > > I still see too many variables in the equation. I need to eliminate
>>> > > some of them. So :
>>> > >
>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
>>> > > --->
>>> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>>> >
>>> > I believe so otherwise XL will not know how to load the binary file
>>> (see
>>> > below).
>>> >
>>> > >
>>> > > 2) What kind of u-boot are you talking about ? Where should I get it
>>> ?
>>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl'
>>> to
>>> > load it from the dom0 filesystem. The option in the xl configuration is
>>> >
>>> > kernel='<path-to-binary>'
>>> >
>>> > Cheers,
>>> >
>>> > --
>>> > Julien Grall
>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>

---> This error can be ignored... It's telling you it can't index the
kernel. That's fine. If this is kernel.bin in reality,then it's to be
expected: kernel.bin is a fully linked binary.

you can ignore this error. I made a mistake on the first try. I had applied
the patch badly.

On Mon, Jan 8, 2024 at 12:09?AM Warner Losh <imp@bsdimp.com> wrote:

> Sorry for the late replies...
>
> On Fri, Jan 5, 2024 at 2:20?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> Sorry I forgot to change the name of the kernel :
>>
>> # cd /usr/freebsd-src/sys/arm/conf
>> # cp GENERIC MYKERNEL
>>
>> # nano MYKERNEL
>> makeoptions WITH_KERNEL_BIN=1
>>
>> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>> installkernel
>>
>> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
>> relocation table found.*
>>
>
> This error can be ignored... It's telling you it can't index the kernel.
> That's fine. If this is kernel.bin in reality,
> then it's to be expected: kernel.bin is a fully linked binary.
>
> Warner
>
>
>> On Fri, Jan 5, 2024 at 7:48?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> Ok. I've found the solution reading here :
>>>
>>>
>>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2
>>>
>>> So on FreeBSD 15.0-CURRENT I did :
>>>
>>> nano /etc/src.conf
>>> WITH_KERNEL_BIN=1
>>> (WITH_KERNEL_BIN is wrong)
>>>
>>> $ cd /usr
>>> $ git clone https://gitlab.com/ehem/freebsd-src.git
>>> $ cd freebsd-src
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>>> installkernel
>>>
>>> Unfortunately I get this error :
>>>
>>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*
>>>
>>> and the kernel.bin file is not generated.
>>>
>>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
>>> /etc/src.conf ;
>>>
>>> I've added the parameter :
>>>
>>> makeoptions WITH_KERNEL_BIN=1
>>>
>>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"
>>>
>>> and then I've launched again the compilation :
>>>
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>>> installkernel
>>>
>>> Unfortunately I've got the same error as before and the kernel.bin file
>>> hasn't been produced as well.
>>>
>>>
>>> On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
>>> wrote:
>>>
>>>> @Warner Losh :
>>>>
>>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
>>>> tried in several ways,but it is not accepted :
>>>>
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>> WITH_KERNEL_BIN = wrong
>>>>
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
>>>> buildkernel = wrong
>>>>
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>>> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>>>>
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>>> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>>>>
>>>> How is it ?
>>>>
>>>>
>>>>
>>>> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > On 01/01/2024 23:03, Mario Marietto wrote:
>>>> > > I still see too many variables in the equation. I need to eliminate
>>>> > > some of them. So :
>>>> > >
>>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch ?
>>>> > > --->
>>>> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>>>> >
>>>> > I believe so otherwise XL will not know how to load the binary file
>>>> (see
>>>> > below).
>>>> >
>>>> > >
>>>> > > 2) What kind of u-boot are you talking about ? Where should I get
>>>> it ?
>>>> > You don't need U-boot if you have a zImage. Instead, you can ask 'xl'
>>>> to
>>>> > load it from the dom0 filesystem. The option in the xl configuration
>>>> is
>>>> >
>>>> > kernel='<path-to-binary>'
>>>> >
>>>> > Cheers,
>>>> >
>>>> > --
>>>> > Julien Grall
>>>>
>>>>
>>>>
>>>> --
>>>> Mario.
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>

--
Mario.

Can you imagine what could be wrong ?

On Mon, Jan 8, 2024 at 12:12?AM Mario Marietto <marietto2008@gmail.com>
wrote:

> ---> This error can be ignored... It's telling you it can't index the
> kernel. That's fine. If this is kernel.bin in reality,then it's to be
> expected: kernel.bin is a fully linked binary.
>
> you can ignore this error. I made a mistake on the first try. I had
> applied the patch badly.
>
> On Mon, Jan 8, 2024 at 12:09?AM Warner Losh <imp@bsdimp.com> wrote:
>
>> Sorry for the late replies...
>>
>> On Fri, Jan 5, 2024 at 2:20?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> Sorry I forgot to change the name of the kernel :
>>>
>>> # cd /usr/freebsd-src/sys/arm/conf
>>> # cp GENERIC MYKERNEL
>>>
>>> # nano MYKERNEL
>>> makeoptions WITH_KERNEL_BIN=1
>>>
>>> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>>> installkernel
>>>
>>> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
>>> relocation table found.*
>>>
>>
>> This error can be ignored... It's telling you it can't index the kernel.
>> That's fine. If this is kernel.bin in reality,
>> then it's to be expected: kernel.bin is a fully linked binary.
>>
>> Warner
>>
>>
>>> On Fri, Jan 5, 2024 at 7:48?PM Mario Marietto <marietto2008@gmail.com>
>>> wrote:
>>>
>>>> Ok. I've found the solution reading here :
>>>>
>>>>
>>>> https://cgit.freebsd.org/src/diff/share/man/man5/src.conf.5?id=ce37de8e05b233bc50de2c7678ee841573e6a7e2
>>>>
>>>> So on FreeBSD 15.0-CURRENT I did :
>>>>
>>>> nano /etc/src.conf
>>>> WITH_KERNEL_BIN=1
>>>> (WITH_KERNEL_BIN is wrong)
>>>>
>>>> $ cd /usr
>>>> $ git clone https://gitlab.com/ehem/freebsd-src.git
>>>> $ cd freebsd-src
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>>>> installkernel
>>>>
>>>> Unfortunately I get this error :
>>>>
>>>> *kldxref: /build-xen/boot/kernel/kernel: no ELF relocation table found*
>>>>
>>>> and the kernel.bin file is not generated.
>>>>
>>>> experiment n. 2 : I have removed the parameter WITH_KERNEL_BIN=1 from
>>>> /etc/src.conf ;
>>>>
>>>> I've added the parameter :
>>>>
>>>> makeoptions WITH_KERNEL_BIN=1
>>>>
>>>> to the kernel file called GENERIC on "/usr/freebsd-src/sys/amd64/conf"
>>>>
>>>> and then I've launched again the compilation :
>>>>
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
>>>> installkernel
>>>>
>>>> Unfortunately I've got the same error as before and the kernel.bin file
>>>> hasn't been produced as well.
>>>>
>>>>
>>>> On Wed, Jan 3, 2024 at 6:33?PM Mario Marietto <marietto2008@gmail.com>
>>>> wrote:
>>>>
>>>>> @Warner Losh :
>>>>>
>>>>> Can you explain where I should add the parameter "WITH_KERNEL_BIN" ? I
>>>>> tried in several ways,but it is not accepted :
>>>>>
>>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>> WITH_KERNEL_BIN = wrong
>>>>>
>>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7 WITH_KERNEL_BIN
>>>>> buildkernel = wrong
>>>>>
>>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>>>> DESTDIR=/build-xen WITH_KERNEL_BIN installkernel = wrong
>>>>>
>>>>> $ make KERNCONF=GENERIC TARGET=arm TARGET_ARCH=armv7
>>>>> DESTDIR=/build-xen installkernel WITH_KERNEL_BIN = wrong
>>>>>
>>>>> How is it ?
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 2, 2024 at 3:27?PM Julien Grall <julien@xen.org> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > On 01/01/2024 23:03, Mario Marietto wrote:
>>>>> > > I still see too many variables in the equation. I need to eliminate
>>>>> > > some of them. So :
>>>>> > >
>>>>> > > 1) Do I need to patch the file locore-v6.S with the Julien's patch
>>>>> ?
>>>>> > > --->
>>>>> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd
>>>>> >
>>>>> > I believe so otherwise XL will not know how to load the binary file
>>>>> (see
>>>>> > below).
>>>>> >
>>>>> > >
>>>>> > > 2) What kind of u-boot are you talking about ? Where should I get
>>>>> it ?
>>>>> > You don't need U-boot if you have a zImage. Instead, you can ask
>>>>> 'xl' to
>>>>> > load it from the dom0 filesystem. The option in the xl configuration
>>>>> is
>>>>> >
>>>>> > kernel='<path-to-binary>'
>>>>> >
>>>>> > Cheers,
>>>>> >
>>>>> > --
>>>>> > Julien Grall
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mario.
>>>>>
>>>>
>>>>
>>>> --
>>>> Mario.
>>>>
>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>


--
Mario.

On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:

> Hi,
>
> On 05/01/2024 21:20, Mario Marietto wrote:
> > Sorry I forgot to change the name of the kernel :
> >
> > # cd /usr/freebsd-src/sys/arm/conf
> > # cp GENERIC MYKERNEL
> >
> > # nano MYKERNEL
> > makeoptions WITH_KERNEL_BIN=1
> >
> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> > installkernel
> >
> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
> > relocation table found.*
>
> Are all the sections in ELF contiguous in memory? If so, you could try
> to use manually objcopy. Something like:
>
> objcopy -O binary -S <your-elf> <output-binary>
>
> Then use 'file' to check if the format is recognized as zImage. If so,
> you could use it in your xl configuration.
>
> Note that this *might* be what KERNEL_BIN is doing underhood. But I
> haven't checked not nor I am familiar with the area. I am only proposing
> something that may get you unstuck for now. You can come back to fix the
> problem afterwards.
>

# Generate the .bin (no elf headers) kernel as an extra build output.
# We must relink to generate the .bin kernel, because without headers the
# location of everything changes. We also strip the ARM marker symbols.
${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
@echo "linking ${.TARGET}"
@${SYSTEM_LD_BASECMD} \
--defsym='text_start=kernbase' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o
${SIZE} ${.TARGET}
@${OBJCOPY} \
--wildcard \
--strip-symbol='$$[adt]*' \
--output-target=binary \
${.TARGET}
@chmod 755 ${.TARGET}

is what makes it...

Warner


> Cheers,
>
> --
> Julien Grall
>

---> objcopy -O binary -S <your-elf> <output-binary>

What's "my elf" ? What's the output binary ? I don't understand which
values should be used there. I have only one file,kernel.bin,but two slots
to fill.


On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>
>> Hi,
>>
>> On 05/01/2024 21:20, Mario Marietto wrote:
>> > Sorry I forgot to change the name of the kernel :
>> >
>> > # cd /usr/freebsd-src/sys/arm/conf
>> > # cp GENERIC MYKERNEL
>> >
>> > # nano MYKERNEL
>> > makeoptions WITH_KERNEL_BIN=1
>> >
>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>> DESTDIR=/build-xen
>> > installkernel
>> >
>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
>> > relocation table found.*
>>
>> Are all the sections in ELF contiguous in memory? If so, you could try
>> to use manually objcopy. Something like:
>>
>> objcopy -O binary -S <your-elf> <output-binary>
>>
>> Then use 'file' to check if the format is recognized as zImage. If so,
>> you could use it in your xl configuration.
>>
>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>> haven't checked not nor I am familiar with the area. I am only proposing
>> something that may get you unstuck for now. You can come back to fix the
>> problem afterwards.
>>
>
> # Generate the .bin (no elf headers) kernel as an extra build output.
> # We must relink to generate the .bin kernel, because without headers the
> # location of everything changes. We also strip the ARM marker symbols.
> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
> @echo "linking ${.TARGET}"
> @${SYSTEM_LD_BASECMD} \
> --defsym='text_start=kernbase' \
> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
> ${SIZE} ${.TARGET}
> @${OBJCOPY} \
> --wildcard \
> --strip-symbol='$$[adt]*' \
> --output-target=binary \
> ${.TARGET}
> @chmod 755 ${.TARGET}
>
> is what makes it...
>
> Warner
>
>
>> Cheers,
>>
>> --
>> Julien Grall
>>
>

--
Mario.

On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
wrote:

> ---> objcopy -O binary -S <your-elf> <output-binary>
>
> What's "my elf" ? What's the output binary ? I don't understand which
> values should be used there. I have only one file,kernel.bin,but two slots
> to fill.
>

I think he means the 'kernel' file.

was the 'kernel' file deleted if you only have kernel.bin? It isn't
normally.

Warner


> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>
>>> Hi,
>>>
>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>> > Sorry I forgot to change the name of the kernel :
>>> >
>>> > # cd /usr/freebsd-src/sys/arm/conf
>>> > # cp GENERIC MYKERNEL
>>> >
>>> > # nano MYKERNEL
>>> > makeoptions WITH_KERNEL_BIN=1
>>> >
>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>> DESTDIR=/build-xen
>>> > installkernel
>>> >
>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
>>> > relocation table found.*
>>>
>>> Are all the sections in ELF contiguous in memory? If so, you could try
>>> to use manually objcopy. Something like:
>>>
>>> objcopy -O binary -S <your-elf> <output-binary>
>>>
>>> Then use 'file' to check if the format is recognized as zImage. If so,
>>> you could use it in your xl configuration.
>>>
>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>> haven't checked not nor I am familiar with the area. I am only proposing
>>> something that may get you unstuck for now. You can come back to fix the
>>> problem afterwards.
>>>
>>
>> # Generate the .bin (no elf headers) kernel as an extra build output.
>> # We must relink to generate the .bin kernel, because without headers the
>> # location of everything changes. We also strip the ARM marker symbols.
>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>> @echo "linking ${.TARGET}"
>> @${SYSTEM_LD_BASECMD} \
>> --defsym='text_start=kernbase' \
>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>> ${SIZE} ${.TARGET}
>> @${OBJCOPY} \
>> --wildcard \
>> --strip-symbol='$$[adt]*' \
>> --output-target=binary \
>> ${.TARGET}
>> @chmod 755 ${.TARGET}
>>
>> is what makes it...
>>
>> Warner
>>
>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>
> --
> Mario.
>

ok. So :

# objcopy -O binary -S kernel kernels
# file kernels
kernels: data

On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> ---> objcopy -O binary -S <your-elf> <output-binary>
>>
>> What's "my elf" ? What's the output binary ? I don't understand which
>> values should be used there. I have only one file,kernel.bin,but two slots
>> to fill.
>>
>
> I think he means the 'kernel' file.
>
> was the 'kernel' file deleted if you only have kernel.bin? It isn't
> normally.
>
> Warner
>
>
>> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>>> > Sorry I forgot to change the name of the kernel :
>>>> >
>>>> > # cd /usr/freebsd-src/sys/arm/conf
>>>> > # cp GENERIC MYKERNEL
>>>> >
>>>> > # nano MYKERNEL
>>>> > makeoptions WITH_KERNEL_BIN=1
>>>> >
>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>>> DESTDIR=/build-xen
>>>> > installkernel
>>>> >
>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no
>>>> ELF
>>>> > relocation table found.*
>>>>
>>>> Are all the sections in ELF contiguous in memory? If so, you could try
>>>> to use manually objcopy. Something like:
>>>>
>>>> objcopy -O binary -S <your-elf> <output-binary>
>>>>
>>>> Then use 'file' to check if the format is recognized as zImage. If so,
>>>> you could use it in your xl configuration.
>>>>
>>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>>> haven't checked not nor I am familiar with the area. I am only
>>>> proposing
>>>> something that may get you unstuck for now. You can come back to fix
>>>> the
>>>> problem afterwards.
>>>>
>>>
>>> # Generate the .bin (no elf headers) kernel as an extra build output.
>>> # We must relink to generate the .bin kernel, because without headers the
>>> # location of everything changes. We also strip the ARM marker symbols.
>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>>> @echo "linking ${.TARGET}"
>>> @${SYSTEM_LD_BASECMD} \
>>> --defsym='text_start=kernbase' \
>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>>> ${SIZE} ${.TARGET}
>>> @${OBJCOPY} \
>>> --wildcard \
>>> --strip-symbol='$$[adt]*' \
>>> --output-target=binary \
>>> ${.TARGET}
>>> @chmod 755 ${.TARGET}
>>>
>>> is what makes it...
>>>
>>> Warner
>>>
>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Julien Grall
>>>>
>>>
>>
>> --
>> Mario.
>>
>

--
Mario.

# objcopy -O binary -S kernel.bin kernels.bin
objcopy: file format not recognized

On Mon, Jan 8, 2024 at 1:56?AM Mario Marietto <marietto2008@gmail.com>
wrote:

> ok. So :
>
> # objcopy -O binary -S kernel kernels
> # file kernels
> kernels: data
>
> On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> ---> objcopy -O binary -S <your-elf> <output-binary>
>>>
>>> What's "my elf" ? What's the output binary ? I don't understand which
>>> values should be used there. I have only one file,kernel.bin,but two slots
>>> to fill.
>>>
>>
>> I think he means the 'kernel' file.
>>
>> was the 'kernel' file deleted if you only have kernel.bin? It isn't
>> normally.
>>
>> Warner
>>
>>
>>> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>>>> > Sorry I forgot to change the name of the kernel :
>>>>> >
>>>>> > # cd /usr/freebsd-src/sys/arm/conf
>>>>> > # cp GENERIC MYKERNEL
>>>>> >
>>>>> > # nano MYKERNEL
>>>>> > makeoptions WITH_KERNEL_BIN=1
>>>>> >
>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>>>> DESTDIR=/build-xen
>>>>> > installkernel
>>>>> >
>>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no
>>>>> ELF
>>>>> > relocation table found.*
>>>>>
>>>>> Are all the sections in ELF contiguous in memory? If so, you could try
>>>>> to use manually objcopy. Something like:
>>>>>
>>>>> objcopy -O binary -S <your-elf> <output-binary>
>>>>>
>>>>> Then use 'file' to check if the format is recognized as zImage. If so,
>>>>> you could use it in your xl configuration.
>>>>>
>>>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>>>> haven't checked not nor I am familiar with the area. I am only
>>>>> proposing
>>>>> something that may get you unstuck for now. You can come back to fix
>>>>> the
>>>>> problem afterwards.
>>>>>
>>>>
>>>> # Generate the .bin (no elf headers) kernel as an extra build output.
>>>> # We must relink to generate the .bin kernel, because without headers
>>>> the
>>>> # location of everything changes. We also strip the ARM marker symbols.
>>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>>>> @echo "linking ${.TARGET}"
>>>> @${SYSTEM_LD_BASECMD} \
>>>> --defsym='text_start=kernbase' \
>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>>>> ${SIZE} ${.TARGET}
>>>> @${OBJCOPY} \
>>>> --wildcard \
>>>> --strip-symbol='$$[adt]*' \
>>>> --output-target=binary \
>>>> ${.TARGET}
>>>> @chmod 755 ${.TARGET}
>>>>
>>>> is what makes it...
>>>>
>>>> Warner
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Julien Grall
>>>>>
>>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>


--
Mario.

If I have understood well,the message : file format not recognized is good
because it is in elf format,right ? if it is,why it cant boot the rest of
the system ?

Il lun 8 gen 2024, 01:58 Mario Marietto <marietto2008@gmail.com> ha scritto:

> # objcopy -O binary -S kernel.bin kernels.bin
> objcopy: file format not recognized
>
> On Mon, Jan 8, 2024 at 1:56?AM Mario Marietto <marietto2008@gmail.com>
> wrote:
>
>> ok. So :
>>
>> # objcopy -O binary -S kernel kernels
>> # file kernels
>> kernels: data
>>
>> On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
>>> wrote:
>>>
>>>> ---> objcopy -O binary -S <your-elf> <output-binary>
>>>>
>>>> What's "my elf" ? What's the output binary ? I don't understand which
>>>> values should be used there. I have only one file,kernel.bin,but two slots
>>>> to fill.
>>>>
>>>
>>> I think he means the 'kernel' file.
>>>
>>> was the 'kernel' file deleted if you only have kernel.bin? It isn't
>>> normally.
>>>
>>> Warner
>>>
>>>
>>>> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>>>>> > Sorry I forgot to change the name of the kernel :
>>>>>> >
>>>>>> > # cd /usr/freebsd-src/sys/arm/conf
>>>>>> > # cp GENERIC MYKERNEL
>>>>>> >
>>>>>> > # nano MYKERNEL
>>>>>> > makeoptions WITH_KERNEL_BIN=1
>>>>>> >
>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>>>>> DESTDIR=/build-xen
>>>>>> > installkernel
>>>>>> >
>>>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no
>>>>>> ELF
>>>>>> > relocation table found.*
>>>>>>
>>>>>> Are all the sections in ELF contiguous in memory? If so, you could
>>>>>> try
>>>>>> to use manually objcopy. Something like:
>>>>>>
>>>>>> objcopy -O binary -S <your-elf> <output-binary>
>>>>>>
>>>>>> Then use 'file' to check if the format is recognized as zImage. If
>>>>>> so,
>>>>>> you could use it in your xl configuration.
>>>>>>
>>>>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>>>>> haven't checked not nor I am familiar with the area. I am only
>>>>>> proposing
>>>>>> something that may get you unstuck for now. You can come back to fix
>>>>>> the
>>>>>> problem afterwards.
>>>>>>
>>>>>
>>>>> # Generate the .bin (no elf headers) kernel as an extra build output.
>>>>> # We must relink to generate the .bin kernel, because without headers
>>>>> the
>>>>> # location of everything changes. We also strip the ARM marker
>>>>> symbols.
>>>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>>>>> @echo "linking ${.TARGET}"
>>>>> @${SYSTEM_LD_BASECMD} \
>>>>> --defsym='text_start=kernbase' \
>>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>>>>> ${SIZE} ${.TARGET}
>>>>> @${OBJCOPY} \
>>>>> --wildcard \
>>>>> --strip-symbol='$$[adt]*' \
>>>>> --output-target=binary \
>>>>> ${.TARGET}
>>>>> @chmod 755 ${.TARGET}
>>>>>
>>>>> is what makes it...
>>>>>
>>>>> Warner
>>>>>
>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> --
>>>>>> Julien Grall
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Mario.
>>>>
>>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>

Hi!
I think its worth trying something like this: arm-none-eabi-objcopy -O binary -S kernel kernel.bin
objcopy expects your host (x86_amd64?) elf format....
Mario Marietto wrote:
If I have understood well,the message : file format not recognized is good because it is in elf format,right ? if it is,why it cant boot the rest of the system ?
Il lun 8 gen 2024, 01:58 Mario Marietto <marietto2008@gmail.com <mailto:marietto2008@gmail.com> > ha scritto:
# objcopy -O binary -S kernel.bin kernels.bin
objcopy: file format not recognized
On Mon, Jan 8, 2024 at 1:56?AM Mario Marietto <marietto2008@gmail.com <mailto:marietto2008@gmail.com> > wrote:
ok. So :
# objcopy -O binary -S kernel kernels
# file kernels
kernels: data
On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com> > wrote:
On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com <mailto:marietto2008@gmail.com> > wrote:
---> objcopy -O binary -S <your-elf> <output-binary>
What's "my elf" ? What's the output binary ? I don't understand which values should be used there. I have only one file,kernel.bin,but two slots to fill.
I think he means the 'kernel' file.
was the 'kernel' file deleted if you only have kernel.bin? It isn't normally.
Warner

On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com> > wrote:
On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org <mailto:julien@xen.org> > wrote:
Hi,
On 05/01/2024 21:20, Mario Marietto wrote:
> Sorry I forgot to change the name of the kernel :
>
> # cd /usr/freebsd-src/sys/arm/conf
> # cp GENERIC MYKERNEL
>
> # nano MYKERNEL
> makeoptions WITH_KERNEL_BIN=1
>
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
> # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 DESTDIR=/build-xen
> installkernel
>
> same error as before : *kldxref: /build-xen/boot/kernel/kernel: no ELF
> relocation table found.*
Are all the sections in ELF contiguous in memory? If so, you could try
to use manually objcopy. Something like:
objcopy -O binary -S <your-elf> <output-binary>
Then use 'file' to check if the format is recognized as zImage. If so,
you could use it in your xl configuration.
Note that this *might* be what KERNEL_BIN is doing underhood. But I
haven't checked not nor I am familiar with the area. I am only proposing
something that may get you unstuck for now. You can come back to fix the
problem afterwards.
# Generate the .bin (no elf headers) kernel as an extra build output.
# We must relink to generate the .bin kernel, because without headers the
# location of everything changes. We also strip the ARM marker symbols.
${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
@echo "linking ${.TARGET}"
@${SYSTEM_LD_BASECMD} \
--defsym='text_start=kernbase' \
-o ${.TARGET} ${SYSTEM_OBJS} vers.o
${SIZE} ${.TARGET}
@${OBJCOPY} \
--wildcard \
--strip-symbol='$$[adt]*' \
--output-target=binary \
${.TARGET}
@chmod 755 ${.TARGET}
is what makes it...
Warner

Cheers,
--
Julien Grall
--
Mario.
--
Mario.
--
Mario.

Directly on the Chromebook :

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders#
mv kernel.bin kernel.bin.old

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders#
objcopy -O binary -S kernel kernel.bin

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
./start-freebsd

Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found:
Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 4:cannot
(re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
4:Non-existent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable
to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction
of domain failed
freebsd is an invalid domain identifier (rc=-6)

freebsd.cfg :

name="freebsd"
kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/kernel.bin"

extra = "console=hvc0"
memory=512
vcpus=1
disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

On Mon, Jan 8, 2024 at 10:34?AM Stanislav Silnicki <
stanislav.silnicki@mailgate.us> wrote:

> Hi!
> I think its worth trying something like this: arm-none-eabi-objcopy -O
> binary -S kernel kernel.bin
> objcopy expects your host (x86_amd64?) elf format....
>
> Mario Marietto wrote:
>
>
> If I have understood well,the message : file format not recognized is good
> because it is in elf format,right ? if it is,why it cant boot the rest of
> the system ?
>
> Il lun 8 gen 2024, 01:58 Mario Marietto <marietto2008@gmail.com> ha
> scritto:
>
>> # objcopy -O binary -S kernel.bin kernels.bin
>> objcopy: file format not recognized
>>
>> On Mon, Jan 8, 2024 at 1:56?AM Mario Marietto <marietto2008@gmail.com>
>> wrote:
>>
>>> ok. So :
>>>
>>> # objcopy -O binary -S kernel kernels
>>> # file kernels
>>> kernels: data
>>>
>>> On Mon, Jan 8, 2024 at 1:37?AM Warner Losh <imp@bsdimp.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Jan 7, 2024 at 5:17?PM Mario Marietto <marietto2008@gmail.com>
>>>> wrote:
>>>>
>>>>> ---> objcopy -O binary -S <your-elf> <output-binary>
>>>>>
>>>>> What's "my elf" ? What's the output binary ? I don't understand which
>>>>> values should be used there. I have only one file,kernel.bin,but two slots
>>>>> to fill.
>>>>>
>>>>
>>>> I think he means the 'kernel' file.
>>>>
>>>> was the 'kernel' file deleted if you only have kernel.bin? It isn't
>>>> normally.
>>>>
>>>> Warner
>>>>
>>>>
>>>>> On Mon, Jan 8, 2024 at 1:00?AM Warner Losh <imp@bsdimp.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 7, 2024 at 3:44?PM Julien Grall <julien@xen.org> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 05/01/2024 21:20, Mario Marietto wrote:
>>>>>>> > Sorry I forgot to change the name of the kernel :
>>>>>>> >
>>>>>>> > # cd /usr/freebsd-src/sys/arm/conf
>>>>>>> > # cp GENERIC MYKERNEL
>>>>>>> >
>>>>>>> > # nano MYKERNEL
>>>>>>> > makeoptions WITH_KERNEL_BIN=1
>>>>>>> >
>>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7 buildkernel
>>>>>>> > # make KERNCONF=MYKERNEL TARGET=arm TARGET_ARCH=armv7
>>>>>>> DESTDIR=/build-xen
>>>>>>> > installkernel
>>>>>>> >
>>>>>>> > same error as before : *kldxref: /build-xen/boot/kernel/kernel: no
>>>>>>> ELF
>>>>>>> > relocation table found.*
>>>>>>>
>>>>>>> Are all the sections in ELF contiguous in memory? If so, you could
>>>>>>> try
>>>>>>> to use manually objcopy. Something like:
>>>>>>>
>>>>>>> objcopy -O binary -S <your-elf> <output-binary>
>>>>>>>
>>>>>>> Then use 'file' to check if the format is recognized as zImage. If
>>>>>>> so,
>>>>>>> you could use it in your xl configuration.
>>>>>>>
>>>>>>> Note that this *might* be what KERNEL_BIN is doing underhood. But I
>>>>>>> haven't checked not nor I am familiar with the area. I am only
>>>>>>> proposing
>>>>>>> something that may get you unstuck for now. You can come back to fix
>>>>>>> the
>>>>>>> problem afterwards.
>>>>>>>
>>>>>>
>>>>>> # Generate the .bin (no elf headers) kernel as an extra build output.
>>>>>> # We must relink to generate the .bin kernel, because without headers
>>>>>> the
>>>>>> # location of everything changes. We also strip the ARM marker
>>>>>> symbols.
>>>>>> ${KERNEL_KO}.bin: ${SYSTEM_DEP} vers.o
>>>>>> @echo "linking ${.TARGET}"
>>>>>> @${SYSTEM_LD_BASECMD} \
>>>>>> --defsym='text_start=kernbase' \
>>>>>> -o ${.TARGET} ${SYSTEM_OBJS} vers.o
>>>>>> ${SIZE} ${.TARGET}
>>>>>> @${OBJCOPY} \
>>>>>> --wildcard \
>>>>>> --strip-symbol='$$[adt]*' \
>>>>>> --output-target=binary \
>>>>>> ${.TARGET}
>>>>>> @chmod 755 ${.TARGET}
>>>>>>
>>>>>> is what makes it...
>>>>>>
>>>>>> Warner
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> --
>>>>>>> Julien Grall
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mario.
>>>>>
>>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>

--
Mario.