From nobody Sun Dec 17 00:27:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4St3hX1kWrz53jWT for ; Sun, 17 Dec 2023 00:28:12 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4St3hV6885z3Llw for ; Sun, 17 Dec 2023 00:28:10 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=MbstH7b9; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 1EC4B7A625 for ; Sun, 17 Dec 2023 03:28:08 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1702772889; bh=bQS3ESzuyZoq+UsCBlVi/pzKMEMduCSj5N9LSKYvtg8=; h=From:Subject:To:References:Date; b=MbstH7b94MOT9V7Ew9PrH6ca8BKbfwxCkXW45jm/qTOhB+mr2T5zoH7bsgniUxhkn XIemq05uady02Ejm4cchWPW+IQ3/BwujIIzAn+G4zqWgRFbbmlMZnMdXyHRilGYR5B w872uJVBcvxRkWW03emi582nltvKX1k8I3H3vcQY= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17027728790910.910944075536489" From: Stanislav Silnicki Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook X-Type: replyAll To: freebsd-arm@freebsd.org User-Agent: Desktop Message-Id: References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Dec 2023 00:27:58 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[mailgate.us:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[mailgate.us]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4St3hV6885z3Llw X-Spamd-Bar: --- ------sinikael-?=_1-17027728790910.910944075536489 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm not an expert in the topic, I only know, that ARM has divided hardware = into two worlds - Secure and Not-So, strictly limiting any software, = running in non-secure world with access to functions and resources. = https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hardwa= re-architecture=3Flang=3Den I'm not sure, that I'm getting you right, as I don't understand what you = mean under =22the first u-boot=22. As I understand, virtualization (HYP) is running in non-secure world = (https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectur= e/The-System-Level-Programmers--Model/The-Virtualization-Extensions), so my= guess (only guess!!!), virtualization software has to prepare (configure) = HW platform in the way, that FreeBSD kernel will not lack any resources, = required to configure MPU, VA, etc. So, if you lucky to boot virtualizer, which is aware of target OS, that = maybe you can boot the kernel. Although, I doubt, that you need to boot = 'second' u-boot to boot the kernel - there is simply ubldr, which you can = hook somehow from virtualizer.... Stan Mario Marietto wrote: ---> As I understand, it makes sure that u-boot keeps in secure mode during= boot and passes control to ubldr, which boots FreeBSD kernel, in that mode= . Can you elaborate your sentence more =3F I know that the bootloader secure = mode is bypassed by the virtual open systems u-boot. Are you saying that = when the control passes to the second u-boot,it will happen in secure mode,= so that the bypass that happened loading the first u-boot,is annulled =3F = If this is true,maybe can I boot FreeBSD using the virtual-open-system = custom u-boot =3F Is this compatible with FreeBSD =3F Where can I find the = u-boot.bin that the xen developer talked about =3F thanks bro'.=20 On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki > wrote: Hi Mario, U-Boot beast is hiding in this den: https://source.denx.de/u-boot/u-boot.= git =20 I took a brief look at your post and it seems to me, that option = CONFIG=5FCMO=5FBY=5FVA=5FONLY is irrelevant to your target armv7 32 bit = platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/a= rmv8/Kconfig=3Fref=5Ftype=3Dheads#L3 =20 As for compiling the u-boot, it is a doable task, given that you understand= what you are doing. There are no specific options in u-boot devoted to = FreeBSD. It is a boot loader, whose mission to make basic hardware = initialization, read you kernel file from some media into RAM and then pass= it control.=20 Basically, you can grab some defconfig, prepared for any other Exynos5250 = based board (say, this one: https://source.denx.de/u-boot/u-boot/-/blob/mas= ter/configs/arndale=5Fdefconfig=3Fref=5Ftype=3Dheads) and adopt it somehow. As per my experience, you have to respect these two options, compiling = u-boot for FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysu= tils/u-boot-master/files/FreeBSD=5FFragment =20 As I understand, it makes sure, that u-boot keeps in secure mode during = boot and passes control to ubldr, which boots FreBSD kernel, in that mode. = Otherwise, there a lot of surprises you may realize. Hope, this will help to progress you tasks Stan Mario Marietto wrote: Hello. I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. = Basically there are two ways to accomplish this task : 1) to write a patch that allows the FreeBSD kernel to boot as a zImage file= . This could be accomplished applying this patch to a specific file that's = on the source code of FreeBSD : https://xenbits.xen.org/gitweb/=3Fp=3Dp...8;hb=3D0782e25d98cc1391472717035f= 986c979edef0c9 =20 This patch was written by Julien Grall a lot of time ago and now it does = not work anymore. This is the reason : 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.=20 So,without a rebase of that patch the first option is not applicable. And = I'm not able to fix it. 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : I was trying to explain why and how Julien's patch works so that you could = be the one to re-do something similar or fix the patch on the FreeBSD = kernel that you are working with. I am happy to help review and write = patches but I don't work with the FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a suggestion. Do you know if = FreeBSD can be booted by U-Boot =3F Because U-Boot definitely boots as Xen = on ARM guest firmware/bootloader. You should be able to build U-Boot and = use the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD = from disk or network and start it. For instance as domU config file: kernel=3D=22/home/petalinux/u-boot.bin=22 disk =3D [ '/home/petalinux/test.img,raw,xvda' ] I know it is important to build u-boot with the following config to make it= work on Xen. CONFIG=5FCMO=5FBY=5FVA=5FONLY=3Dy=20 This option seems more doable to me according to my knowledge. But I need = to understand how to do it. Well,let's say that on the ARM Chromebook I'm forced to use and install a = customized version of u-boot,created by virtual open systems,because it is = the only one that allows bypassing its bootloader protection. You can find = more information here : http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/=3F= vos=3Dtech =20 This is the relevant section to read : Bootloader : If you wish to skip this chapter you can download a pre-compiled binary of = the bootloader: $ wget http://www.virtualopensystems.com/downloads/guides/kvm=5Fon=5Fchrome= book/nv=5Fu-boot-snow.kpart =20 To be able to run KVM on ARM platforms, the kernel has to be booted in = hypervisor mode. Because of this relatively recent requirement (due to the = introduction of the virtualization extensions), up until now all booting = methods would boot the kernel in the standard Supervisor mode. For the ARM = Chromebook the default boot procedure doesn't allow us to boot in = hypervisor mode. Although the laptop's boot mechanism is based on the = frequently used u-boot, the binary is located in RO memory. Fortunately, a = chained u-boot mechanism can be used (i.e. starting another u-boot after = the original). We can then enter hypervisor mode from our custom iteration = of u-boot and subsequently load our kernel and userspace. Checkout the needed u-boot code : $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ ./scripts/build.sh If successful, a message about how to copy the bootloader on the USB flash = disk or SD card will appear. We will use it later when preparing the boot = medium to start our system. If you have followed the Setting up the boot = medium chapter and you have a prepared boot device, then you can update = u-boot by running : $ sudo dd if=3Dnv=5Fuboot-snow.kpart of=3D/dev/sdX1=20 so,the needed u-boot that we must use should be installed on the first = partition of the sd card. There is another relevant section to read : Setting up the boot medium Now it is time to copy all the relevant files that we created in the = previous chapters,and use them to boot Chromebook with a different kernel = and OS. In all these examples the device /dev/sdX is used. Take extra care = to change the examples to the device that you have attached. Insert the = boot medium on your workstation and carefully execute the following step. = First we need to properly format the boot medium. In the uboot source directory : $ sudo ./scripts/sdcard.sh /dev/sdX This will erase all data and create 4 partitions in the medium, along with = copying the u-boot binary to the first partition: Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) Partition 2 =3D not used Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250-snow= .dtb) Partition 4 =3D EXT4 partition for userspace files With u-boot being copied, next is the kernel image and DTB file. From the = kernel source execute : $ mkdir ../mnt/ $ sudo mount /dev/sdX3 ../mnt/ $ sudo cp arch/arm/boot/uImage ../mnt/ $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ $ sudo umount /dev/sdX3 Finally, we have to copy the Ubuntu userspace filesystem that we created = earlier: $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount = /dev/sdX4=20 Now,my idea is to chainload the already chain loaded u-boot created by V.O.= S to the new u-boot that we need for booting FreeBSD and that can be = installed in the partition n.2,as shown in this scheme,because it is not = used : Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) Partition 2 =3D not used (maybe we can install the u-boot for arm 32 bit,= compatible with FreeBSD on this partition) Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250-snow= .dtb) Partition 4 =3D EXT4 partition for userspace files Take in consideration that default boot string is hardcoded here,in the = snow.h file of the custom u-boot created by VOS : https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/sno= w.h#L101 =20 and it needs to be recompiled because it should point to the partition n.2,= where I will install the u-boot files as explained here : https://wiki.freebsd.org/arm/Chromebook =20 I have some questions to ask before I start working on this. 1) The xen developer said : You should be able to build U-Boot and use the U-Boot binary as Xen guest = kernel...=20 where is the u-boot binary,according to this document =3F https://wiki.freebsd.org/arm/Chromebook =20 I don't see it. 2) where is the source code of the file that I can get here : http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv= =5Fuboot-snow-simplefb.kpart.bz2 I need the source code if I want to recompile u-boot so that it can point = to the partition 4. Maybe it can be found on this link : http://linux-exynos.org/dist/chromebook/nv=5Fuboot/ =20 but it can't be opened.... 3) in this specific scenario the source code of u-boot should run on arm 32= bit,not on arm 64,because I have the Samsung Chromebook =22SNOW=22 model = XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15) = Soc. 4) I'm not sure if I can chainload the customized u-boot created by V.O.S = that should be installed on the first partition with the u-boot tailored = for booting FreeBSD that should be installed on the partition 2.... 5) the xen developer said that u-boot should be compiled enabling this = option : Code:=20 CONFIG=5FCMO=5FBY=5FVA=5FONLY=3Dy=20 Well,can you provide some good source that can help me to understand how I = can recompile u-boot for FreeBSD =3F thanks. --=20 Mario. --=20 Mario. ------sinikael-?=_1-17027728790910.910944075536489 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=20 =20 =20 =20 =20 =20
I'm not an expert in the topic, I only know, that ARM has = divided hardware into two worlds - Secure and Not-So, strictly limiting any= software, running in non-secure world with access to functions and = resources. https://developer.arm.com/documentation/den0013/d/Security/= TrustZone-hardware-architecture=3Flang=3Den

I'm not sure, that I'm getting you right, as I = don't understand what you mean under =22the first u-boot=22.

As I understand, = virtualization (HYP) is running in non-secure world (https://developer.arm.= com/documentation/ddi0406/c/System-Level-Architecture/The-System-Level-Prog= rammers--Model/The-Virtualization-Extensions), so my guess (only guess!!!),= virtualization software has to prepare (configure) HW platform in the way,= that FreeBSD kernel will not lack any resources, required to configure MPU= , VA, etc.
So, if = you lucky to boot virtualizer, which is aware of target OS, that maybe you = can boot the kernel. Although, I doubt, that you need to boot 'second' = u-boot to boot the kernel - there is simply ubldr, which you can hook = somehow from virtualizer....

Stan



Mario Marietto = wrote:


---> As=20 I understand, it makes sure that u-boot keeps in secure mode during = boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.=

Can you elaborate your sentence more =3F I know = that the bootloader secure mode is bypassed by the virtual open systems = u-boot. Are you saying that when the control passes to the second u-boot,it= will happen in secure mode,so that the bypass that happened loading the = first u-boot,is annulled =3F If this is true,maybe can I boot FreeBSD using= the virtual-open-system custom u-boot =3F Is this compatible with FreeBSD = =3F Where can I find the u-boot.bin that the xen developer talked about =3F= thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.= silnicki@mailgate.us> wrote:
= =20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot&nb= sp; beast is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.= git
I took a brief look at your post and it = seems to me, that=20 option CONFIG=5FCMO=5FBY=5FVA=5FONLY is= irrelevant to=20 your target armv7 32 bit=20 platform: https://source.denx.de/u-boot/u-boot/-/blob/master/= arch/arm/cpu/armv8/Kconfig=3Fref=5Ftype=3Dheads#L3

As=20 for compiling the u-boot, it is a doable task, given that you = understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then = pass=20 it control.

Basically, you can grab some defconfig,=20 prepared for any other Exynos5250 based board  (say, this one: https://sour= ce.denx.de/u-boot/u-boot/-/blob/master/configs/arndale=5Fdefconfig=3Fref=5F= type=3Dheads)=20 and adopt it somehow.

As per my experience, = you have to respect=20 these two options, compiling u-boot for FreeBSD: https://github= .com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD= =5FFragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during = boot=20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.

Hope, this=20 will help to progress you tasks
Stan

Mario=20 Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.=20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.= xen.org/gitweb/=3Fp=3Dp...8;hb=3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it = does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. = And=20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :


=09
=09
I was trying to explain why and how Julien's patch works so that you=20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn't be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot =3F Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D=22/home/petalinux/u-boot.bin=22
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make = it=20 work on Xen.

CONFIG=5FCMO=5FBY=5FVA=5FONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I = need=20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and install a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http://www.virtualopensystems.= com/en/solutions/guides/kvm-on-chromebook/=3Fvos=3Dtech

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary = of=20 the bootloader:


$ wget http://www.virtualopensystems.= com/downloads/guides/kvm=5Fon=5Fchromebook/nv=5Fu-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to=20 boot in hypervisor mode. Although the laptop's boot mechanism is based=20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.= git$ cd=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv=5Fuboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along = with=20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From = the=20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we = created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.= com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.= h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.= org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document =3F

https://wiki.freebsd.= org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/di= stfiles/nv=5Fuboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can = point=20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.= org/dist/chromebook/nv=5Fuboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook =22SNOW=22 = model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex=20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG=5FCMO=5FBY=5FVA=5FONLY=3Dy
=


Well,can you provide some good source that can help me to understand how = I=20 can recompile u-boot for FreeBSD =3F=20 thanks.
--
Mario.=
=20 =20 =20 =20 =20

--
Mario.
=20 =20 =20 ------sinikael-?=_1-17027728790910.910944075536489-- From nobody Sun Dec 17 06:41:55 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StD033syFz54B51 for ; Sun, 17 Dec 2023 06:42:11 +0000 (UTC) (envelope-from atma@convalesco.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4StD0200D7z4L3j for ; Sun, 17 Dec 2023 06:42:09 +0000 (UTC) (envelope-from atma@convalesco.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=convalesco.org header.s=fm1 header.b=BW8oqnfx; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=eCnkQ7zh; spf=pass (mx1.freebsd.org: domain of atma@convalesco.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=atma@convalesco.org; dmarc=pass (policy=reject) header.from=convalesco.org Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A0A005C0073 for ; Sun, 17 Dec 2023 01:42:08 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 17 Dec 2023 01:42:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=convalesco.org; h=cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1702795328; x=1702881728; bh=ZzrvFM241VZBx1gB0re6ymiX4tk76YCv 6dFMxo6HLa8=; b=BW8oqnfxd0pZx/NS94bLmAlx5CuwJANZ+dDgc2sp/81Q79gG Zcw9KhVGWwywvV22JoZOapRt0N+IskejLcmN2AiyVkdGGfU+9XigAy6hVArcUaJG JiiWALyB/Kev2nsj5xTf1fDqBpcib5ZogOG8BJrvGp1sLjoMMh1H+WYFib5BuV9Z VDHdHSXL9l2UtkHkb3Txk7FjjQBAdRJBdAFNJZPRGMr7cDxOdj0VXau9B3qcA7jS fSn2BlKAFis86Kr/7x8A6IoIwEZAqOaHvA8VwEbXgFvAE8FvUGCaQqOGrkN+xwcD iOufp+Mo2BDpUFAg09SQKJWrOTvmTPAjxJ7ztw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1702795328; x=1702881728; bh=ZzrvFM241VZBx1gB0re6ymiX4tk76YCv6dF Mxo6HLa8=; b=eCnkQ7zhBXuxGZRS/ubS7Giox4vxeX0RAF7d2Q87xOnMxwYD5lm 8Sy4R5FeNBbs39RsDoG3xPI2H/HMFRKz2UqS40J+AJ90gC7SLoaQ3usIXW+QuzjP vz+OMh953x+vmRuQXTNsmHT3738WvaqY0r36Ciou+2rUkhtCt6y04gCFHoMGwgvG J/ksjbcITMsTxVtgK6TEFAVwXbR5R/0m8Zp3NUM/ZOlTRqUaNzPBnXUezmOkpOE5 8bwEP98qCDv1/cDEHofFt3T1XFG4tRvNOk2Wb4mVDdzZRob5oe8DuAaaDZUamBGM XqpvVsHc4J5Bh0rBQhPK0lcjXrYHjbM4U5A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddthedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffkfffvofesrgdtmherhh dtjeenucfhrhhomheprfgrnhgrghhiohhtihhsucetthhmrghtiihiughishcuoegrthhm rgestghonhhvrghlvghstghordhorhhgqeenucggtffrrghtthgvrhhnpeehfeetveekvd euudettedufeejfeevffehhfduueehjeevhfehtdejfedufeeuhfenucffohhmrghinhep fhhrvggvsghsugdrohhrghdptghonhhvrghlvghstghordhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghtmhgrsegtohhnvhgrlhgv shgtohdrohhrgh X-ME-Proxy: Feedback-ID: if8a042fc:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 17 Dec 2023 01:42:07 -0500 (EST) From: Panagiotis Atmatzidis Content-Type: multipart/alternative; boundary="Apple-Mail=_7C0140E9-529A-4C1F-838F-AE289A9EC039" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: FreeRadius SQL driver undefined symbol __aeabi_uidivmod Message-Id: <5331A126-5DF4-4758-A607-31F23DD5C5B7@convalesco.org> Date: Sun, 17 Dec 2023 08:41:55 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[convalesco.org,reject]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; R_DKIM_ALLOW(-0.20)[convalesco.org:s=fm1,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[convalesco.org:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4StD0200D7z4L3j X-Spamd-Bar: --- --Apple-Mail=_7C0140E9-529A-4C1F-838F-AE289A9EC039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I=E2=80=99m trying to setup FreeRadius3 on RPi2 (armv6) running = FreeBSD-13.2. I=E2=80=99m using MySQL as a backend because it runs = nicely on a low resource hardware. Enabling the SQL driver yields the following error: ``` Could not link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: = Undefined symbol "__aeabi_uidivmod" Make sure it (and all its dependent libraries!) are in the search path = of your system's ld /usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation failed for = module =E2=80=9Csql" ``` There is a discussion in bugtraq[^1] about this exact issue and there = seems to be a patch as well[^2]. Can someone help me apply this patch or = point me to a tutorial? I used =E2=80=9Cpkg=E2=80=9D to install "mysql80-server" and = "freeradius3-mysql=E2=80=9C, however I have the ports collection = installed so I could use that if it helps. Kind regards, P. [^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087 [^2]: = https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&action=3Dv= iewall -- Panagiotis (atmosx) Atmatzidis email: atma@convalesco.org URL: http://www.convalesco.org GnuPG ID: 0x1A7BFEC5 gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5 "Everyone thinks of changing the world, but no one thinks of changing = himself.=E2=80=9D - Leo Tolstoy --Apple-Mail=_7C0140E9-529A-4C1F-838F-AE289A9EC039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I=E2=80=99m trying to = setup FreeRadius3 on RPi2 (armv6) running FreeBSD-13.2. I=E2=80=99m = using MySQL as a backend because it runs nicely on a low resource = hardware.

Enabling the SQL driver yields the = following error:

```
Could not = link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: Undefined = symbol "__aeabi_uidivmod"
Make sure it (and all its dependent = libraries!) are in the search path of your system's = ld
/usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation = failed for module = =E2=80=9Csql"
```

There is a = discussion in bugtraq[^1] about this exact issue and there seems to be a = patch as well[^2]. Can someone help me apply this patch or point me to a = tutorial?

I used =E2=80=9Cpkg=E2=80=9D to = install "mysql80-server" and "freeradius3-mysql=E2=80=9C, however I have = the ports collection installed so I could use that if it = helps.

Kind = regards,

P.


[^1]: https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087
[^2]:&n= bsp;https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&ac= tion=3Dviewall

--
Panagiotis (atmosx) = Atmatzidis

email: atma@convalesco.org
URL: = http://www.convalesco.org
GnuPG ID: 0x1A7BFEC5
gpg = --keyserver pgp.mit.edu --recv-keys 1A7BFEC5

"Everyone = thinks of changing the world, but no one thinks of changing = himself.=E2=80=9D - Leo Tolstoy





= --Apple-Mail=_7C0140E9-529A-4C1F-838F-AE289A9EC039-- From nobody Sun Dec 17 07:35:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StF9S3r1Rz54F68 for ; Sun, 17 Dec 2023 07:35:24 +0000 (UTC) (envelope-from atma@convalesco.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4StF9R4NXyz4Tny for ; Sun, 17 Dec 2023 07:35:23 +0000 (UTC) (envelope-from atma@convalesco.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=convalesco.org header.s=fm1 header.b=sjPwsfMD; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="flgiD/ro"; spf=pass (mx1.freebsd.org: domain of atma@convalesco.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=atma@convalesco.org; dmarc=pass (policy=reject) header.from=convalesco.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 508425C0102 for ; Sun, 17 Dec 2023 02:35:23 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 17 Dec 2023 02:35:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=convalesco.org; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1702798523; x=1702884923; bh=PV3ihMFSn4 vyyKxo3e9VgesoXeFSDWCzAKozFAbkSHE=; b=sjPwsfMDFPjmbNUm3CPBY9N4L6 NmN+/MaK991AuXFZc3Ks3tBGEfzOxFz9Xc4oANJzJUxKISuz202QRhtkWEyTpa6J FvMz9b98imIGXKHFYflXO+WlBw6no45AX3jY8oUmsxYvLb7WavfuJkunzldbTwAu 5d9URQLngiFOYjKR3GZ/5diVU0gkIUgSzBzpavZ0zH4NJzyane+TSxrb7E4KYETy iwU3Pcoeyyqu57GpivIkstskalpn5WOA7SVXb95aKPosQdnIbwUAwARhp+k9n0SP Ja6kHRueT1Q8Zs/MGUiY0/i8pnTO83abW+OCEP5V58WeXmGjLTqtMZLkUFNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1702798523; x=1702884923; bh=PV3ihMFSn4vyyKxo3e9VgesoXeFS DWCzAKozFAbkSHE=; b=flgiD/roIbf0l6EP4v9rR8w/8MGXsKiP+4wVgsnmJKie 7WVKZm53Z07NdkpDPU8Q1tBFqDiTBAkt16nvZ0TmA44v2WPUVty3VQ5d+Dsb4iG/ 5rZuJ/yZwUQ2IImVQvdHOlBBEII/qruthkQuUbYac+HMYpCeeow6+lGCAEX+wrlh 88hdQW2peYnnybgdyv7brovL8rP6cTXhZdIyUXk7KqkA/Srgvqka1+aGcjFwqrwl c1/DbSl1xh2KCakiRdMtidspJ3T153o0ylzYj2IvFdgxTe0mweDjsJxa7vbNkw/W gudCRLSe8oTpTy/cM4OvwuQ9/tx7+wA1aq5xlbsRcQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddthedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfuffhfvfgjkffosegrtd hmrehhtdejnecuhfhrohhmpefrrghnrghgihhothhishcutehtmhgrthiiihguihhsuceo rghtmhgrsegtohhnvhgrlhgvshgtohdrohhrgheqnecuggftrfgrthhtvghrnhepueefue ffvedujedvvdejgfdvudduvedugeeftedtieevkeeileehgfejgfejieefnecuffhomhgr ihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghtmhgrsegtohhnvhgrlhgvshgtohdrohhrgh X-ME-Proxy: Feedback-ID: if8a042fc:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 17 Dec 2023 02:35:22 -0500 (EST) From: Panagiotis Atmatzidis Content-Type: multipart/alternative; boundary="Apple-Mail=_BB2B61D2-0678-49F0-B1F6-6A955D67B861" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: FreeRadius SQL driver undefined symbol __aeabi_uidivmod Date: Sun, 17 Dec 2023 09:35:10 +0200 References: <5331A126-5DF4-4758-A607-31F23DD5C5B7@convalesco.org> To: freebsd-arm@freebsd.org In-Reply-To: <5331A126-5DF4-4758-A607-31F23DD5C5B7@convalesco.org> Message-Id: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[convalesco.org,reject]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; R_DKIM_ALLOW(-0.20)[convalesco.org:s=fm1,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[convalesco.org:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4StF9R4NXyz4Tny X-Spamd-Bar: --- --Apple-Mail=_BB2B61D2-0678-49F0-B1F6-6A955D67B861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Dec 2023, at 8:41 AM, Panagiotis Atmatzidis = wrote: >=20 > Hello, >=20 > I=E2=80=99m trying to setup FreeRadius3 on RPi2 (armv6) running = FreeBSD-13.2. I=E2=80=99m using MySQL as a backend because it runs = nicely on a low resource hardware. >=20 > Enabling the SQL driver yields the following error: >=20 > ``` > Could not link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: = Undefined symbol "__aeabi_uidivmod" > Make sure it (and all its dependent libraries!) are in the search path = of your system's ld > /usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation failed for = module =E2=80=9Csql" > ``` >=20 > There is a discussion in bugtraq[^1] about this exact issue and there = seems to be a patch as well[^2]. Can someone help me apply this patch or = point me to a tutorial? >=20 > I used =E2=80=9Cpkg=E2=80=9D to install "mysql80-server" and = "freeradius3-mysql=E2=80=9C, however I have the ports collection = installed so I could use that if it helps. >=20 > Kind regards, >=20 > P. >=20 >=20 > [^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087 > [^2]: = https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&action=3Dv= iewall >=20 Going through a similar request[^1] in the forums and a bit of browsing = the kernel tree helped figure things out. Sharing the solution = step-by-step for posterity. Copy the patch (diff file) and place the patch to the home dir e.g. " = /home/atma/arithmetic_symbols.patch=E2=80=9D and then then: ``` [root@aeschylus /usr/src]# cd /usr/src [root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def |index d28e9042f744..b90bc705e3de 100644 |--- a/lib/libgcc_s/Versions.def |+++ b/lib/libgcc_s/Versions.def -------------------------- Patching file lib/libgcc_s/Versions.def using Plan A... Hunk #1 succeeded at 32 (offset 1 line). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/lib/libgcc_s/arm/Symbol.map b/lib/libgcc_s/arm/Symbol.map |index 92b54761d810..49b0820b2a73 100644 |--- a/lib/libgcc_s/arm/Symbol.map |+++ b/lib/libgcc_s/arm/Symbol.map -------------------------- Patching file lib/libgcc_s/arm/Symbol.map using Plan A... Hunk #1 succeeded at 16 (offset 1 line). done ``` -- Panagiotis (atmosx) Atmatzidis GPG: gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5 --Apple-Mail=_BB2B61D2-0678-49F0-B1F6-6A955D67B861 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 = Dec 2023, at 8:41 AM, Panagiotis Atmatzidis <atma@convalesco.org> = wrote:

Hello,

I=E2=80=99m = trying to setup FreeRadius3 on RPi2 (armv6) running FreeBSD-13.2. I=E2=80=99= m using MySQL as a backend because it runs nicely on a low resource = hardware.

Enabling the SQL driver yields the = following error:

```
Could not = link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: Undefined = symbol "__aeabi_uidivmod"
Make sure it (and all its dependent = libraries!) are in the search path of your system's = ld
/usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation = failed for module = =E2=80=9Csql"
```

There is a = discussion in bugtraq[^1] about this exact issue and there seems to be a = patch as well[^2]. Can someone help me apply this patch or point me to a = tutorial?

I used =E2=80=9Cpkg=E2=80=9D to = install "mysql80-server" and "freeradius3-mysql=E2=80=9C, however I have = the ports collection installed so I could use that if it = helps.

Kind = regards,

P.


[^1]: https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087
[^2]:&n= bsp;https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&ac= tion=3Dviewall


= Going through a similar request[^1] in the forums and a bit of =  browsing the kernel tree helped figure things out. Sharing the = solution step-by-step for posterity.

Copy the = patch (diff file) and place the patch to the home dir e.g. " /home/atma/arithmetic_symbols.patch=E2=80=9D and then = then:

```
[root@aeschylus /usr/src]# cd = /usr/src
[root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch
Hmm...  Looks like a = unified diff to me...
The text leading up to this = was:
--------------------------
|diff --git = a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def
|index = d28e9042f744..b90bc705e3de 100644
|--- = a/lib/libgcc_s/Versions.def
|+++ = b/lib/libgcc_s/Versions.def
--------------------------
Patching file lib/libgcc_s/Versions.def using Plan A...
Hunk = #1 succeeded at 32 (offset 1 line).
Hmm...  The next = patch looks like a unified diff to me...
The text leading up = to this was:
--------------------------
|diff --git = a/lib/libgcc_s/arm/Symbol.map = b/lib/libgcc_s/arm/Symbol.map
|index = 92b54761d810..49b0820b2a73 100644
|--- = a/lib/libgcc_s/arm/Symbol.map
|+++ = b/lib/libgcc_s/arm/Symbol.map
--------------------------
Patching file lib/libgcc_s/arm/Symbol.map using Plan = A...
Hunk #1 succeeded at 16 (offset 1 = line).
done
```

--
Panagiotis (atmosx) Atmatzidis
GPG:   =     gpg --keyserver pgp.mit.edu = --recv-keys 1A7BFEC5





= --Apple-Mail=_BB2B61D2-0678-49F0-B1F6-6A955D67B861-- From nobody Sun Dec 17 08:24:28 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StGGM3bBLz54Hsx for ; Sun, 17 Dec 2023 08:24:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StGGM1Wzvz3Ly5 for ; Sun, 17 Dec 2023 08:24:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-50bf69afa99so2491645e87.3 for ; Sun, 17 Dec 2023 00:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1702801480; x=1703406280; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=21o9QdFxLb4Za5QXqKxvJi6ZD2ORrUjpHZ95rR2V2MI=; b=bq/rTs70uxCkdzum+eU6xCtlMfVr3URKJ7GRDrZFawTksu/Y4YQGIHY34o2FOmcUUl Hqo/DSHUl7eo4Cppr23ScJBelAsVvFlzrIfBCcZbg0tdaJux/TvZ7tBy+fdbT/Z7fcHR pCYXpS9qo8UFidl3HLASxQjY0ewfnNoyctzT28hTJY7BG31wQDC/7XZejgfRJBHSFTDS mHHa7KTUa8UOZbelt1PSBnL6HO8F/BMjdRJiwlm18aX/vIXEU9YFGh+CnKLIWv3uoN/L 8Y1OUitSELVrzDLEYv4l3Ol33XWT7G4VnAajm9/qr7LXeQ9u5Ez3zA37V4l7UzKFMSkg RGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702801480; x=1703406280; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=21o9QdFxLb4Za5QXqKxvJi6ZD2ORrUjpHZ95rR2V2MI=; b=FjtuH1mqgkT9IYbJZafkOZFTluHzSzKfrMyDdaLB7EBF+NnIFhtBFjxaHa/1+2tpZ3 2J4eG45rceaRxa6L+Iosr1XA4x7BoKho0e0+zGq8lcPmdJ43FlSdocp4GFiEdypAv8Fw +2qiuhMjaQMHx8Ucw7x4pmH3f7cEXqH4VOOXZ4lTtOI4hd7KX6GOvojUXuU3l35sn1eB Ijd6T0emUanTGyei6ekjF6WOqkvN/H6IarKDm8na1Rl9NthBfvaWRL+33ooU2ONHJHRH ldgehomQRe5ovT3WPWlrxTd5Muaazh6H66LI9oPiuEyK8POkNWiXH8jYKvtmtd4Yli1n OK6A== X-Gm-Message-State: AOJu0YxWaQPLcdHmuiyc3iGx1/ng/Fq538kEwUD6zDlxCv7q+E+MO3IC SDvYAlBe1yHNT08LV2z8b/SLXGUKyxhgKljvrkmRA+UmeNdrBct+DSM= X-Google-Smtp-Source: AGHT+IGzZMK8Gg/6exM6zxlvEGqv4Q8iDISu4IrztlyzZuUvKnIwAcDDBtzYtG+XOsqzg/W5sOXO4w8zKd9xp/3FyZY= X-Received: by 2002:a05:6512:124c:b0:50d:1888:1e4b with SMTP id fb12-20020a056512124c00b0050d18881e4bmr9774069lfb.49.1702801479787; Sun, 17 Dec 2023 00:24:39 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <5331A126-5DF4-4758-A607-31F23DD5C5B7@convalesco.org> In-Reply-To: From: Warner Losh Date: Sun, 17 Dec 2023 01:24:28 -0700 Message-ID: Subject: Re: FreeRadius SQL driver undefined symbol __aeabi_uidivmod To: Panagiotis Atmatzidis Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000005377da060cb05df5" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4StGGM1Wzvz3Ly5 --0000000000005377da060cb05df5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 17, 2023, 12:35=E2=80=AFAM Panagiotis Atmatzidis wrote: > > > On 17 Dec 2023, at 8:41 AM, Panagiotis Atmatzidis > wrote: > > Hello, > > I=E2=80=99m trying to setup FreeRadius3 on RPi2 (armv6) running FreeBSD-1= 3.2. I=E2=80=99m > using MySQL as a backend because it runs nicely on a low resource hardwar= e. > > Enabling the SQL driver yields the following error: > > ``` > Could not link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: > Undefined symbol "__aeabi_uidivmod" > Make sure it (and all its dependent libraries!) are in the search path of > your system's ld > /usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation failed for modul= e > =E2=80=9Csql" > ``` > > There is a discussion in bugtraq[^1] about this exact issue and there > seems to be a patch as well[^2]. Can someone help me apply this patch or > point me to a tutorial? > > I used =E2=80=9Cpkg=E2=80=9D to install "mysql80-server" and "freeradius3= -mysql=E2=80=9C, however > I have the ports collection installed so I could use that if it helps. > > Kind regards, > > P. > > > [^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087 > [^2]: > https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&action=3D= viewall > > > Going through a similar request[^1] in the forums and a bit of browsing > the kernel tree helped figure things out. Sharing the solution step-by-st= ep > for posterity. > > Copy the patch (diff file) and place the patch to the home dir e.g. " /ho= me/atma/arithmetic_symbols.patch=E2=80=9D > and then then: > > ``` > [root@aeschylus /usr/src]# cd /usr/src > [root@aeschylus /usr/src]# patch -C < /home/atma/arithmetic_symbols.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def > |index d28e9042f744..b90bc705e3de 100644 > |--- a/lib/libgcc_s/Versions.def > |+++ b/lib/libgcc_s/Versions.def > -------------------------- > Patching file lib/libgcc_s/Versions.def using Plan A... > Hunk #1 succeeded at 32 (offset 1 line). > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/lib/libgcc_s/arm/Symbol.map b/lib/libgcc_s/arm/Symbol.map > |index 92b54761d810..49b0820b2a73 100644 > |--- a/lib/libgcc_s/arm/Symbol.map > |+++ b/lib/libgcc_s/arm/Symbol.map > -------------------------- > Patching file lib/libgcc_s/arm/Symbol.map using Plan A... > Hunk #1 succeeded at 16 (offset 1 line). > done > ``` > Ideally you'd do a full buildworld/installworld here. On these machines that takes a lot of time. You may be able to do: % cd lib/libgcc_s % make clean obj depend all % sudo make install But that assumes your system has all the compilers, libraries etc installed on it... If you are cross building, then just do a full buildworld since the above depends on make includes and possibly other things running first. If we still have armv6 snapshots, there's a chance that the /lib/libgcc_s.so.1 from it will have the fix and you can copy it over... but that might be more hassle and may be less safe than the above. Good luck. And make backups of /lib/libgcc_s.so.1 before starting (keep a copy in /lib, and use /rescue/sh if you mess this up and /bin/sh can't run for single-user). Warner -- > Panagiotis (atmosx) Atmatzidis > GPG: gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5 > > > > > > --0000000000005377da060cb05df5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 17, 2023, 12:35=E2=80=AFA= M Panagiotis Atmatzidis <atma@convalesco.org> wrote:


On 17 Dec 2023, at 8:41 AM, Panagiotis Atmatzidi= s <atma@convalesco.org> wrote:

Hello,

I=E2=80=99m trying to se= tup FreeRadius3 on RPi2 (armv6) running FreeBSD-13.2. I=E2=80=99m using MyS= QL as a backend because it runs nicely on a low resource hardware.

Enabling the SQL driver yields the following error:
<= div>
```
Could not link driver rlm_sql_mysql: = /usr/local/lib/libunwind.so.8: Undefined symbol "__aeabi_uidivmod"= ;
Make sure it (and all its dependent libraries!) are in the sear= ch path of your system's ld
/usr/local/etc/raddb/mods-enabled= /sql[27]: Instantiation failed for module =E2=80=9Csql"
```

There is a discussion in bugtraq[^1] about t= his exact issue and there seems to be a patch as well[^2]. Can someone help= me apply this patch or point me to a tutorial?

I = used =E2=80=9Cpkg=E2=80=9D to install "mysql80-server" and "= freeradius3-mysql=E2=80=9C, however I have the ports collection installed s= o I could use that if it helps.


Going through a sim= ilar request[^1] in the forums and a bit of =C2=A0browsing the kernel tree = helped figure things out. Sharing the solution step-by-step for posterity.<= /div>

Copy the patch (diff file) and place the patch to = the home dir e.g. "=C2=A0/home/atma/arithmetic_symbols.patch=E2=80=9D and then th= en:

```
[root@aeschylus /usr/src]# cd /usr/src
[root@= aeschylus /usr/src]# patch -C < /home/atma/arithmetic_symbols.patch
Hmm...=C2=A0 Looks like a unified diff to me...
The text le= ading up to this was:
--------------------------
|diff = --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def
|in= dex d28e9042f744..b90bc705e3de 100644
|--- a/lib/libgcc_s/Version= s.def
|+++ b/lib/libgcc_s/Versions.def
----------------= ----------
Patching file lib/libgcc_s/Versions.def using Plan A..= .
Hunk #1 succeeded at 32 (offset 1 line).
Hmm...=C2=A0= The next patch looks like a unified diff to me...
The text leadi= ng up to this was:
--------------------------
|diff --g= it a/lib/libgcc_s/arm/Symbol.map b/lib/libgcc_s/arm/Symbol.map
|i= ndex 92b54761d810..49b0820b2a73 100644
|--- a/lib/libgcc_s/arm/Sy= mbol.map
|+++ b/lib/libgcc_s/arm/Symbol.map
-----------= ---------------
Patching file lib/libgcc_s/arm/Symbol.map using P= lan A...
Hunk #1 succeeded at 16 (offset 1 line).
done<= /div>
```
<= br>
Ideally you'd do a full buildworld/installwo= rld here. On these machines that takes a lot of time.

You may be able to do:

% cd lib/libgcc_s
% mak= e clean obj depend all
% sudo make install

But that assumes your system has = all the compilers, libraries etc installed on it... If you are cross buildi= ng, then just do a full buildworld since the above depends on make includes= and possibly other things running first.

=
If we still have armv6 snapshots, there's a chance th= at the /lib/libgcc_s.so.1 from it will have the fix and you can copy it ove= r... but that might be more hassle and may be less safe than the above.

Good luck. And make backups of /lib/libg= cc_s.so.1 before starting (keep a copy in /lib, and use /rescue/sh if you m= ess this up and /bin/sh can't run for single-user).

Warner

--
Panagiotis (atmosx) AtmatzidisGPG: =C2=A0 =C2=A0 =C2=A0 gpg --keyserver pgp.mit.edu --recv-keys=C2=A01A7BF= EC5





--0000000000005377da060cb05df5-- From nobody Sun Dec 17 12:10:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StMGc1Z8fz54XHZ for ; Sun, 17 Dec 2023 12:10:16 +0000 (UTC) (envelope-from atma@convalesco.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4StMGb5DTTz3W8W for ; Sun, 17 Dec 2023 12:10:15 +0000 (UTC) (envelope-from atma@convalesco.org) Authentication-Results: mx1.freebsd.org; none Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D028C5C0135; Sun, 17 Dec 2023 07:10:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 17 Dec 2023 07:10:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=convalesco.org; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1702815013; x= 1702901413; bh=ethaED0lhAXWGCKQ/icFqJS3l01kNTTODuuK1/oNS9o=; b=O MBKeeR7fv5eHDkaa18QpS0DGq0g1/2Z2OCrACKe4ivWh/GAE/s194jLWBHq8/GOF v7ggOuRA8Wpk8Mb5F0ifKeJSBkqrFzvaG9ysDsA6kcBMYpRnDI7KJKlgDQEu7zOr RwWTVRoxbQQzOuxwMdfR+67XN1Q2oSalU3PIf4FAoOrEoeI3KiwlxIS3V4k5+4Xa maxESi5ATizQnspndyKMKg9iQ3+6G6k3Dj8zfDY6SebR9Hi9MSOMzs7Nv6iDiMGF BQlqbMOjt4o1h6mdUbTHfKnM6rTbfE0cVUytuZLMH6Ybcf+cMXYVcgzuuD74lkVl AxJv5dgUU7qyTm2T86Pug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1702815013; x=1702901413; bh=ethaED0lhAXWGCKQ/icFqJS3l01k NTTODuuK1/oNS9o=; b=mY45zG+eJCyxQXPhHnpaot4sQPi0YLMQ7qh7EUze9IXE J568cGWUBxjWHXYHl7dUhZBziqekHtA1bCrHtdRYQH3x6IUMOw0myoyvVzBmHKpR r8CqK42a2yQ6C3vBXeSWEq9RorTBux+wDPN86/XOkZNFphPruKUHMJcE1QcVz52v eh3ymhCVzcqi9/im52maWbKQCg8pt/FOtcLeyRYZFnSkhDJbiu1rhtmsiXEALCW1 MVNL0WE4gqN09a2xAxFxHZSCqxHG2+WunszOXrxonxc2kvt+WoD7AuDD6wfZldnP 3topvqr5LrrMR171Zvneq+WcGnQNfiy+r9ikkfHUig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddtiedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhkfgtggfuffgjvefvfhfosegrtd hmrehhtdejnecuhfhrohhmpefrrghnrghgihhothhishcutehtmhgrthiiihguihhsuceo rghtmhgrsegtohhnvhgrlhgvshgtohdrohhrgheqnecuggftrfgrthhtvghrnhepkeehte fhgfehhefggeekuefhveetffevvefgjefgvdeiffeuudelgeevvedtjeeknecuffhomhgr ihhnpehfrhgvvggsshgurdhorhhgpdhmihhtrdgvughunecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprghtmhgrsegtohhnvhgrlhgvshgtohdr ohhrgh X-ME-Proxy: Feedback-ID: if8a042fc:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 17 Dec 2023 07:10:12 -0500 (EST) From: Panagiotis Atmatzidis Message-Id: <292A20D8-94CB-47FE-B48B-D3EFF10079AC@convalesco.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDBF1E2A-F9B7-44D8-BE88-11DB7616FC1E" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: FreeRadius SQL driver undefined symbol __aeabi_uidivmod Date: Sun, 17 Dec 2023 14:10:00 +0200 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Warner Losh References: <5331A126-5DF4-4758-A607-31F23DD5C5B7@convalesco.org> X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4StMGb5DTTz3W8W --Apple-Mail=_BDBF1E2A-F9B7-44D8-BE88-11DB7616FC1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Warner, Thanks for the suggestions, worked like a charm! So here=E2=80=99s the = complete list of commands: ``` [root@aeschylus /usr/src]# mkdir /root/backup [root@aeschylus /usr/src]# cp /lib/libgcc_s.so.1 /root/backup/ [root@aeschylus /usr/src]# cp /usr/lib/debug/lib/libgcc_s.so.1.debug = /root/backup/ [root@aeschylus /usr/src]# cd /usr/src [root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch # dry-run mode Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def |index d28e9042f744..b90bc705e3de 100644 |--- a/lib/libgcc_s/Versions.def |+++ b/lib/libgcc_s/Versions.def -------------------------- Patching file lib/libgcc_s/Versions.def using Plan A... Hunk #1 succeeded at 32 (offset 1 line). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/lib/libgcc_s/arm/Symbol.map b/lib/libgcc_s/arm/Symbol.map |index 92b54761d810..49b0820b2a73 100644 |--- a/lib/libgcc_s/arm/Symbol.map |+++ b/lib/libgcc_s/arm/Symbol.map -------------------------- Patching file lib/libgcc_s/arm/Symbol.map using Plan A... Hunk #1 succeeded at 16 (offset 1 line). done [root@aeschylus /usr/src]# patch < /home/atma/arithmetic_symbols.patch # = apply the patch [=E2=80=A6] # same as above [root@aeschylus /usr/src]# patch < /home/atma/arithmetic_symbols.patch # = apply the patch [root@aeschylus /usr/src]# cd lib/libgcc_s [root@aeschylus /usr/src]# make clean obj depend all [=E2=80=A6] [root@aeschylus /usr/src]# sudo make install [=E2=80=A6] ``` Radius comes up without errors. The SQL driver works as expected. Thank you! > On 17 Dec 2023, at 10:24 AM, Warner Losh wrote: >=20 >=20 >=20 > On Sun, Dec 17, 2023, 12:35=E2=80=AFAM Panagiotis Atmatzidis = > wrote: >>=20 >>=20 >>> On 17 Dec 2023, at 8:41 AM, Panagiotis Atmatzidis = > wrote: >>>=20 >>> Hello, >>>=20 >>> I=E2=80=99m trying to setup FreeRadius3 on RPi2 (armv6) running = FreeBSD-13.2. I=E2=80=99m using MySQL as a backend because it runs = nicely on a low resource hardware. >>>=20 >>> Enabling the SQL driver yields the following error: >>>=20 >>> ``` >>> Could not link driver rlm_sql_mysql: /usr/local/lib/libunwind.so.8: = Undefined symbol "__aeabi_uidivmod" >>> Make sure it (and all its dependent libraries!) are in the search = path of your system's ld >>> /usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation failed for = module =E2=80=9Csql" >>> ``` >>>=20 >>> There is a discussion in bugtraq[^1] about this exact issue and = there seems to be a patch as well[^2]. Can someone help me apply this = patch or point me to a tutorial? >>>=20 >>> I used =E2=80=9Cpkg=E2=80=9D to install "mysql80-server" and = "freeradius3-mysql=E2=80=9C, however I have the ports collection = installed so I could use that if it helps. >>>=20 >>> Kind regards, >>>=20 >>> P. >>>=20 >>>=20 >>> [^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271087 >>> [^2]: = https://bugs.freebsd.org/bugzilla/attachment.cgi?bugid=3D271087&action=3Dv= iewall >>>=20 >>=20 >> Going through a similar request[^1] in the forums and a bit of = browsing the kernel tree helped figure things out. Sharing the solution = step-by-step for posterity. >>=20 >> Copy the patch (diff file) and place the patch to the home dir e.g. " = /home/atma/arithmetic_symbols.patch=E2=80=9D and then then: >>=20 >> ``` >> [root@aeschylus /usr/src]# cd /usr/src >> [root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch >> Hmm... Looks like a unified diff to me... >> The text leading up to this was: >> -------------------------- >> |diff --git a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def >> |index d28e9042f744..b90bc705e3de 100644 >> |--- a/lib/libgcc_s/Versions.def >> |+++ b/lib/libgcc_s/Versions.def >> -------------------------- >> Patching file lib/libgcc_s/Versions.def using Plan A... >> Hunk #1 succeeded at 32 (offset 1 line). >> Hmm... The next patch looks like a unified diff to me... >> The text leading up to this was: >> -------------------------- >> |diff --git a/lib/libgcc_s/arm/Symbol.map = b/lib/libgcc_s/arm/Symbol.map >> |index 92b54761d810..49b0820b2a73 100644 >> |--- a/lib/libgcc_s/arm/Symbol.map >> |+++ b/lib/libgcc_s/arm/Symbol.map >> -------------------------- >> Patching file lib/libgcc_s/arm/Symbol.map using Plan A... >> Hunk #1 succeeded at 16 (offset 1 line). >> done >> ``` >=20 >=20 > Ideally you'd do a full buildworld/installworld here. On these = machines that takes a lot of time. >=20 > You may be able to do: >=20 > % cd lib/libgcc_s > % make clean obj depend all > % sudo make install >=20 > But that assumes your system has all the compilers, libraries etc = installed on it... If you are cross building, then just do a full = buildworld since the above depends on make includes and possibly other = things running first. >=20 > If we still have armv6 snapshots, there's a chance that the = /lib/libgcc_s.so.1 from it will have the fix and you can copy it over... = but that might be more hassle and may be less safe than the above. >=20 > Good luck. And make backups of /lib/libgcc_s.so.1 before starting = (keep a copy in /lib, and use /rescue/sh if you mess this up and /bin/sh = can't run for single-user). >=20 > Warner >=20 >> -- >> Panagiotis (atmosx) Atmatzidis >> GPG: gpg --keyserver pgp.mit.edu = --recv-keys 1A7BFEC5 -- Panagiotis (atmosx) Atmatzidis GPG: gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5 --Apple-Mail=_BDBF1E2A-F9B7-44D8-BE88-11DB7616FC1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Warner,

Thanks for the suggestions, worked like a = charm! So here=E2=80=99s the complete list of = commands:

```
[root@aeschylus /usr/src]# mkdir = /root/backup
[root@aeschylus /usr/src]# cp = /lib/libgcc_s.so.1 /root/backup/
[root@aeschylus = /usr/src]# cp /usr/lib/debug/lib/libgcc_s.so.1.debug = /root/backup/
[root@aeschylus /usr/src]# cd = /usr/src
[root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch # dry-run mode
Hmm... =  Looks like a unified diff to me...
The text leading up = to this was:
--------------------------
|diff --git = a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def
|index = d28e9042f744..b90bc705e3de 100644
|--- = a/lib/libgcc_s/Versions.def
|+++ = b/lib/libgcc_s/Versions.def
--------------------------
Patching file lib/libgcc_s/Versions.def using Plan A...
Hunk = #1 succeeded at 32 (offset 1 line).
Hmm...  The next = patch looks like a unified diff to me...
The text leading up = to this was:
--------------------------
|diff --git = a/lib/libgcc_s/arm/Symbol.map = b/lib/libgcc_s/arm/Symbol.map
|index = 92b54761d810..49b0820b2a73 100644
|--- = a/lib/libgcc_s/arm/Symbol.map
|+++ = b/lib/libgcc_s/arm/Symbol.map
--------------------------
Patching file lib/libgcc_s/arm/Symbol.map using Plan = A...
Hunk #1 succeeded at 16 (offset 1 = line).
done

[root@aeschylus /usr/src]# patch < = /home/atma/arithmetic_symbols.patch # apply the = patch
[=E2=80=A6] # same as = above
[root@aeschylus /usr/src]# patch < = /home/atma/arithmetic_symbols.patch # apply the = patch
[root@aeschylus /usr/src]# cd = lib/libgcc_s
[root@aeschylus /usr/src]# make clean obj depend = all
[=E2=80=A6]
[root@aeschylus /usr/src]# sudo make = install
[=E2=80=A6]
```

Radius comes up without errors. The SQL driver = works as expected.

Thank = you!

On 17 Dec 2023, = at 10:24 AM, Warner Losh <imp@bsdimp.com> wrote:



On Sun, Dec 17, 2023, 12:35=E2=80=AFAM = Panagiotis Atmatzidis <atma@convalesco.org> = wrote:


On 17 Dec 2023, at 8:41 AM, Panagiotis Atmatzidis = <atma@convalesco.org> wrote:

Hello,

I=E2=80= =99m trying to setup FreeRadius3 on RPi2 (armv6) running FreeBSD-13.2. = I=E2=80=99m using MySQL as a backend because it runs nicely on a low = resource hardware.

Enabling the SQL driver = yields the following = error:

```
Could not link driver = rlm_sql_mysql: /usr/local/lib/libunwind.so.8: Undefined symbol = "__aeabi_uidivmod"
Make sure it (and all its dependent = libraries!) are in the search path of your system's = ld
/usr/local/etc/raddb/mods-enabled/sql[27]: Instantiation = failed for module = =E2=80=9Csql"
```

There is a = discussion in bugtraq[^1] about this exact issue and there seems to be a = patch as well[^2]. Can someone help me apply this patch or point me to a = tutorial?

I used =E2=80=9Cpkg=E2=80=9D to = install "mysql80-server" and "freeradius3-mysql=E2=80=9C, however I have = the ports collection installed so I could use that if it = helps.

Kind = regards,

P.


[^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2710= 87


Going through a similar request[^1] in the = forums and a bit of  browsing the kernel tree helped figure things = out. Sharing the solution step-by-step for = posterity.

Copy the patch (diff file) and place = the patch to the home dir e.g. " /home/atma/arithmetic_symbols.patch=E2=80=9D= and then then:

```
[root@aeschylus /usr/src]# cd = /usr/src
[root@aeschylus /usr/src]# patch -C < = /home/atma/arithmetic_symbols.patch
Hmm...  Looks like a = unified diff to me...
The text leading up to this = was:
--------------------------
|diff --git = a/lib/libgcc_s/Versions.def b/lib/libgcc_s/Versions.def
|index = d28e9042f744..b90bc705e3de 100644
|--- = a/lib/libgcc_s/Versions.def
|+++ = b/lib/libgcc_s/Versions.def
--------------------------
Patching file lib/libgcc_s/Versions.def using Plan A...
Hunk = #1 succeeded at 32 (offset 1 line).
Hmm...  The next = patch looks like a unified diff to me...
The text leading up = to this was:
--------------------------
|diff --git = a/lib/libgcc_s/arm/Symbol.map = b/lib/libgcc_s/arm/Symbol.map
|index = 92b54761d810..49b0820b2a73 100644
|--- = a/lib/libgcc_s/arm/Symbol.map
|+++ = b/lib/libgcc_s/arm/Symbol.map
--------------------------
Patching file lib/libgcc_s/arm/Symbol.map using Plan = A...
Hunk #1 succeeded at 16 (offset 1 = line).
done
```

Ideally you'd do a = full buildworld/installworld here. On these machines that takes a lot of = time.

You may be able = to do:

% cd = lib/libgcc_s
% make clean obj depend = all
% sudo make install

But that assumes your system = has all the compilers, libraries etc installed on it... If you are cross = building, then just do a full buildworld since the above depends on make = includes and possibly other things running first.

If we still have armv6 = snapshots, there's a chance that the /lib/libgcc_s.so.1 from it will = have the fix and you can copy it over... but that might be more hassle = and may be less safe than the above.

Good luck. And make backups of = /lib/libgcc_s.so.1 before starting (keep a copy in /lib, and use = /rescue/sh if you mess this up and /bin/sh can't run for = single-user).

Warner

--
Panagiotis (atmosx) = Atmatzidis
GPG:       gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5

--
Panagiotis (atmosx) Atmatzidis
GPG:   =     gpg --keyserver pgp.mit.edu = --recv-keys 1A7BFEC5





= --Apple-Mail=_BDBF1E2A-F9B7-44D8-BE88-11DB7616FC1E-- From nobody Sun Dec 17 12:21:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StMXC5gwfz54Xp1 for ; Sun, 17 Dec 2023 12:22:03 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StMXC4ypxz4Gdp for ; Sun, 17 Dec 2023 12:22:03 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702815723; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+ifFAnkisCJtTCcoYnGp1oGfpUGZ4XksWEJ2Wvz/itw=; b=xfaQAUSaSLDjrPZfwwoWbcFbPrS1xNZO6NaNOdtu/BONoRdtugrl+HgCPn+gSauZBcPYG6 IUuZ6sJ0oeCJUeYEmKd/d+0bZxwZd4XccYDN/VwmOrperjsJFZfrSNfP4TcG/CxwVLpk9a e3bHowPTOFjxxSBCOVvix3DIec4KdgkBldyCKvtzphkj5as+DQy1ap9Vk6AaLXtoGN3bV8 Snlx+KR4yrTkqwnkGqGsA0XihjHgKFS6gp5Jkr/3ooCnPe/2PK5gtnQIGSfb0gh2Z9VzP4 YxQoDgXf1Di0BK/GL/579+mOq8qG3Q2t0Ba+hHJBRQH+e5O+yM3Vutq1Kos4PQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702815723; a=rsa-sha256; cv=none; b=lbyIVogaVpQKkKB2NYqwOVedkqEXBP0STqWOlCFDIGGgY5s9LKxtsHOUpZXyo/RftV64RD sFnoXc6CDqhghli3jFDYOqPDSfXnrUFAFte77av0ik6c0QneT1gb2NA41EmQlO4zIylfqW KT/tAXDJG0/bSkAAIlCMCikHvjJbExeKpAf0ObQKSI8ZIgnKtxFxbPv+sTr6b2A2ZMJsdS kLL9m79ApuPM9Pti4lK4sJjpMufIvpGd+chTfZCFNHHjXv2z/b1qGSzQuFRMmxWvSd+IWX IcD768A7ZRHHpd4pdvBr4uxUd067iutjbOYj9TSnAKee7UpzwFkhhmKKpY9Qbw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702815723; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+ifFAnkisCJtTCcoYnGp1oGfpUGZ4XksWEJ2Wvz/itw=; b=bzeC0Nx2osM3trxSFZOB0GJ4xQ9xh0GVkPxjiT+pv0pFuIlgApHoRHpoALFekW59wQQD5X Cu9Q23pRxrTo5jCEu628BT8kt82ZuZn30o0GHVqdNws3ZSxmXBrej4HChe+lGO9GzrsSoy N3/uXdjZAGElQzsLAyQ+hNJunolZpz93N5ajlTtIqWU6MFC+m2LUhyB5wP81OoFP7Hrj/T 9rU4tr+Xn7CRVxInbKat8Fy5yVrbm2eojxFB9nNJDpshorjQ5PFBQjZ7fVP1qRHpVUbCl+ r8mejOTjgTq25d7ZwNQ6oc2FbkvmCemh4WuoqIN4YwhMPLhL88YNMH+B7yB1aw== Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4StMXC1XhJz19LG for ; Sun, 17 Dec 2023 12:22:03 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4260ba19a57so24147131cf.3 for ; Sun, 17 Dec 2023 04:22:03 -0800 (PST) X-Gm-Message-State: AOJu0Yw1hloOurFOhBlBRCcbrR8GYVq6lUtiq1J3eVVOKxi8V//vghvJ MAyN6kQh1l3Htz3C9IYHa8j9gLSUfteeodEDCZ4= X-Google-Smtp-Source: AGHT+IEH+go93L/lUOQEjPgfYykOEvxGr8h1OopKeuU7E3B2Qq9WaPDymCpQqmeYgihtw+M8bp/BGQInA6mkvJLXPxw= X-Received: by 2002:a05:622a:1b91:b0:425:8635:785b with SMTP id bp17-20020a05622a1b9100b004258635785bmr17644954qtb.71.1702815722148; Sun, 17 Dec 2023 04:22:02 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> <46c52d37-36ec-45fc-8098-1029996c717c@FreeBSD.org> <27c55e4e-21d2-44f7-9436-95fa1e5b4722@FreeBSD.org> <7daaaade-955d-4678-bec4-a34a196b27b7@FreeBSD.org> In-Reply-To: <7daaaade-955d-4678-bec4-a34a196b27b7@FreeBSD.org> From: Nuno Teixeira Date: Sun, 17 Dec 2023 12:21:50 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: firefox broken on arm64 To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003c98be060cb3ae72" --0000000000003c98be060cb3ae72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jesper, I've applied your reversed patch and used makepatch into a ready to use patch: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D247095 thanks Jesper Schmitz Mouridsen escreveu no dia s=C3=A1bado, 16/12/2023 =C3=A0(s) 22:08: > > > On 10.12.2023 14.08, Jesper Schmitz Mouridsen wrote: > > > > > > On 03.12.2023 11.59, Jesper Schmitz Mouridsen wrote: > >> > >> > >> On 03.12.2023 09.38, void wrote: > >>> On Sun, Dec 03, 2023 at 08:34:21AM +0100, Jesper Schmitz Mouridsen > >>> wrote: > >>>> > >>>> Just build firefox-esr-115.5.0_1,1 and firefox-116.0.3_1,2 the > >>>> first runs with aslr disabled, the latter signals 4. > >>>> > >>>> Any suggestions on what is going on are appreciated. > >>> > >>> What's the uname -aKU ? > >> > >> FreeBSD generic 14.0-RELEASE FreeBSD 14.0-RELEASE #0 > >> releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:12:14 UTC 2023 > >> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERI= C > arm64 1400097 1400097 > >> > >> did you build from ports or poudriere? > >> From ports. > >> > >> If the > >>> latter, what's the /etc/make.conf contain? > >>> > >>> Please post sysctl -a | grep aslr > >>> > >> > >> kern.elf32.aslr.shared_page: 0 > >> kern.elf32.aslr.stack: 1 > >> kern.elf32.aslr.honor_sbrk: 0 > >> kern.elf32.aslr.pie_enable: 0 > >> kern.elf32.aslr.enable: 0 > >> kern.elf64.aslr.shared_page: 1 > >> kern.elf64.aslr.stack: 1 > >> kern.elf64.aslr.honor_sbrk: 0 > >> kern.elf64.aslr.pie_enable: 1 > >> kern.elf64.aslr.enable: 1 > >> vm.aslr_restarts: 256 > >> > >> I did the esr build to test the build setup, since also the pkg in the > >> official pkg repo behaves the same i.e the one before 115.5 since > >> 115.5 did not hit the pkg repo yet, which works without aslr (set by > >> proccontrol) So unless 116 introduces something which requires sysctl > >> changes for the building tool chain while building my test should be > >> valid. > >> > >> Thanks > >> > >> /jsm > >> > >> > > Hi > > Just FYI > > I have managed to cross-compile firefox115-esr on amd64 to aaarhc64 so > > that takes me ~20 min compute time to compile as opposed to 5-7 hours o= n > > my arm boards... I think it broke somewhere between 115 and 116, but no= w > > bisecting is doable to the extend the port patches allows. Can someone > > btw tell me hove the libwebrtc patches are generated..? > > > I build and bisected with --disable-webrtc so I did not need the patches > for that.. > It breaks here: > changeset: 743155:5c5cf716aa0b > user: Jan de Mooij > date: Wed Jun 07 16:34:51 2023 +0000 > summary: Bug 1835876 part 2 - Disable code write protection in > content processes. r=3Dnbp > > [root@freebsd2 /tmp3/bisect/mozilla-unified]# hg log -r 743154 > changeset: 743154:028f981600d7 > user: Jan de Mooij > date: Wed Jun 07 16:34:51 2023 +0000 > summary: Bug 1835876 part 1 - Remove unused > ProtectionSetting::Protected. r=3Dnbp > > Related to w^x.. I can only make it work by reverting the whole of the > two above commits... > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271081#c7) Still > disabling aslr is required > /Jsm > > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000003c98be060cb3ae72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jesper,

I've appli= ed your reversed patch and used makepatch into a ready to use patch:

<= div dir=3D"ltr" class=3D"gmail_attr">Jesper Schmitz Mouridsen <jsm@freebsd.org> escreveu no dia s=C3=A1= bado, 16/12/2023 =C3=A0(s) 22:08:


On 10.12.2023 14.08, Jesper Schmitz Mouridsen wrote:
>
>
> On 03.12.2023 11.59, Jesper Schmitz Mouridsen wrote:
>>
>>
>> On 03.12.2023 09.38, void wrote:
>>> On Sun, Dec 03, 2023 at 08:34:21AM +0100, Jesper Schmitz Mouri= dsen
>>> wrote:
>>>>
>>>> Just build firefox-esr-115.5.0_1,1=C2=A0 and firefox-116.0= .3_1,2 the
>>>> first runs with aslr disabled, the latter signals 4.
>>>>
>>>> Any suggestions on what is going on are appreciated.
>>>
>>> What's the uname -aKU ?
>>
>> FreeBSD generic 14.0-RELEASE FreeBSD 14.0-RELEASE #0
>> releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:12:14 UTC 2023 >> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GE= NERIC arm64 1400097 1400097
>>
>> =C2=A0=C2=A0did you build from ports or poudriere?
>> =C2=A0From ports.
>>
>> If the
>>> latter, what's the /etc/make.conf contain?
>>>
>>> Please post sysctl -a | grep aslr
>>>
>>
>> kern.elf32.aslr.shared_page: 0
>> kern.elf32.aslr.stack: 1
>> kern.elf32.aslr.honor_sbrk: 0
>> kern.elf32.aslr.pie_enable: 0
>> kern.elf32.aslr.enable: 0
>> kern.elf64.aslr.shared_page: 1
>> kern.elf64.aslr.stack: 1
>> kern.elf64.aslr.honor_sbrk: 0
>> kern.elf64.aslr.pie_enable: 1
>> kern.elf64.aslr.enable: 1
>> vm.aslr_restarts: 256
>>
>> I did the esr build to test the build setup, since also the pkg in= the
>> official pkg repo behaves the same i.e the one before 115.5 since =
>> 115.5 did not hit the pkg repo yet, which works without aslr (set = by
>> proccontrol) So unless 116 introduces something which requires sys= ctl
>> changes for the building tool chain while building my test should = be
>> valid.
>>
>> Thanks
>>
>> /jsm
>>
>>
> Hi
> Just FYI
> I have managed to cross-compile firefox115-esr on amd64 to aaarhc64 so=
> that takes me ~20 min compute time to compile as opposed to 5-7 hours = on
> my arm boards... I think it broke somewhere between 115 and 116, but n= ow
> bisecting is doable to the extend the port patches allows. Can someone=
> btw tell me hove the libwebrtc patches are generated..?
>
I build and bisected with --disable-webrtc so I did not need the patches for that..
It breaks here:
changeset:=C2=A0 =C2=A0743155:5c5cf716aa0b
user:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan de Mooij <jdemooij@mozilla.com>
date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wed Jun 07 16:34:51 2023 +0000
summary:=C2=A0 =C2=A0 =C2=A0Bug 1835876 part 2 - Disable code write protect= ion in
content processes. r=3Dnbp

[root@freebsd2 /tmp3/bisect/mozilla-unified]# hg log -r 743154
changeset:=C2=A0 =C2=A0743154:028f981600d7
user:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan de Mooij <jdemooij@mozilla.com>
date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wed Jun 07 16:34:51 2023 +0000
summary:=C2=A0 =C2=A0 =C2=A0Bug 1835876 part 1 - Remove unused
ProtectionSetting::Protected. r=3Dnbp

Related to w^x.. I can only make it work by reverting the whole of the
two above commits...
(https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D271081#c7) Still
disabling aslr is required
/Jsm



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--0000000000003c98be060cb3ae72-- From nobody Sun Dec 17 14:08:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StPvd4sBBz53gxd for ; Sun, 17 Dec 2023 14:09:01 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StPvd2XLzz4Wj3; Sun, 17 Dec 2023 14:09:01 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702822141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+rvTKXohCLIYWjRylRF1Nr2AOfpa5uN2WsefBTcVXas=; b=axEy8FMpdeUYe9yO1TYmF9TElkyr4NSo3sH/3ALBZ3VUdzw4gT2+d3Su2puPCr02b1wvtH 35ntt6K4kmg4ZGYaSHUHdfzj3AHCgQ+j2LaW6kY4jRt0suMlW9PURkGHQmw+8ISPABCMrX YwSrEJpStH5rN9VwUVxCiZqiJRL6vInjKLTT47j+lEPzDoJB2lhu6qG0kke080gX8D5Zx5 wPw9bHnQ4l1dqsDXpz3dvctV7YGjGtcYtNyThwTlXaOdroZetLuF5FEo2WkkPNzfI3QOVO g/GdlrVOw/zJDBtt9t/Dm6pClDYK4fhVSLP9g2yVL234QuCVfv/Lz1JQxXKlaA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702822141; a=rsa-sha256; cv=none; b=EIs04MfkQgEa73tJH/Z+IIUTwvRxxlxJdlqBTXm/0AxXU7V3X3o3PnCv0lWB/kwpRL43Dn t+xOGg/M7O6FA7utYQ8HL7jhEshph4TvSGj3A+jezfqKz4N218yNxTGE9P6/fVsGRD8Bm1 aHi7ybEtAQieI9ywQn2YClZ+GAQYOzTXNrdYza9Qxsf+iawhHh2zjR2/mXZ3qcF1DX5IbC JLys8mgWKD/hRuPTPjiq9s3XKEIQPvphkyGfyPzbSZb0/Pbn7jcdrnl4CN4MKliiUFnIfl UKosNjeqoBfs5XlGx4TpnRhyKvdWXX2ZP//XC/Gm95/hDI0hhQA59lXN3D+Pxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702822141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+rvTKXohCLIYWjRylRF1Nr2AOfpa5uN2WsefBTcVXas=; b=DLteoasNzN2UwxR9kj7VaJjqUFDK3lswqb4YXXGW7Tf/ewXh6rIP9kcRPu0WnhyODFEcWi J8bN29tU+FZa9rBi8Fq+48VI4ha+qtV6u993bD4qfCv08XS4AKts7WEY7qpCX4RBMx5k7k oakwOWPzF3cHBKgl44elR4ozwScsxs9I1MC/DEvsyf4epVCqd4j3DqQcXcGDZdOS7+VtYL NN/2J5DNqQCKBf/ZIDn1h2MkP3s39gNSWIFsC2EbkwslBYpkNBNgxSsApa04E8tRoJeGE3 HuVq15m+R8lJI1FMvf6PTCHh4rknvBr8zhDaH5ZBO0YcioDBUNs6JJbmgu3F+g== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4StPvc63ygz1Bfl; Sun, 17 Dec 2023 14:09:00 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: Date: Sun, 17 Dec 2023 15:08:59 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: firefox broken on arm64 Content-Language: en-US To: Nuno Teixeira , freebsd-arm@freebsd.org References: <9518dc38-e44b-42ae-bf87-6039ac278ac8@FreeBSD.org> <46c52d37-36ec-45fc-8098-1029996c717c@FreeBSD.org> <27c55e4e-21d2-44f7-9436-95fa1e5b4722@FreeBSD.org> <7daaaade-955d-4678-bec4-a34a196b27b7@FreeBSD.org> From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Also see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081#c11 On 17.12.2023 13.21, Nuno Teixeira wrote: > Hello Jesper, > > I've applied your reversed patch and used makepatch into a ready to use > patch: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247095 > > > thanks > > Jesper Schmitz Mouridsen > > escreveu no dia sábado, 16/12/2023 à(s) 22:08: > > > > On 10.12.2023 14.08, Jesper Schmitz Mouridsen wrote: > > > > > > On 03.12.2023 11.59, Jesper Schmitz Mouridsen wrote: > >> > >> > >> On 03.12.2023 09.38, void wrote: > >>> On Sun, Dec 03, 2023 at 08:34:21AM +0100, Jesper Schmitz Mouridsen > >>> wrote: > >>>> > >>>> Just build firefox-esr-115.5.0_1,1  and firefox-116.0.3_1,2 the > >>>> first runs with aslr disabled, the latter signals 4. > >>>> > >>>> Any suggestions on what is going on are appreciated. > >>> > >>> What's the uname -aKU ? > >> > >> FreeBSD generic 14.0-RELEASE FreeBSD 14.0-RELEASE #0 > >> releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:12:14 UTC 2023 > >> > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 1400097 1400097 > >> > >>   did you build from ports or poudriere? > >>  From ports. > >> > >> If the > >>> latter, what's the /etc/make.conf contain? > >>> > >>> Please post sysctl -a | grep aslr > >>> > >> > >> kern.elf32.aslr.shared_page: 0 > >> kern.elf32.aslr.stack: 1 > >> kern.elf32.aslr.honor_sbrk: 0 > >> kern.elf32.aslr.pie_enable: 0 > >> kern.elf32.aslr.enable: 0 > >> kern.elf64.aslr.shared_page: 1 > >> kern.elf64.aslr.stack: 1 > >> kern.elf64.aslr.honor_sbrk: 0 > >> kern.elf64.aslr.pie_enable: 1 > >> kern.elf64.aslr.enable: 1 > >> vm.aslr_restarts: 256 > >> > >> I did the esr build to test the build setup, since also the pkg > in the > >> official pkg repo behaves the same i.e the one before 115.5 since > >> 115.5 did not hit the pkg repo yet, which works without aslr > (set by > >> proccontrol) So unless 116 introduces something which requires > sysctl > >> changes for the building tool chain while building my test > should be > >> valid. > >> > >> Thanks > >> > >> /jsm > >> > >> > > Hi > > Just FYI > > I have managed to cross-compile firefox115-esr on amd64 to > aaarhc64 so > > that takes me ~20 min compute time to compile as opposed to 5-7 > hours on > > my arm boards... I think it broke somewhere between 115 and 116, > but now > > bisecting is doable to the extend the port patches allows. Can > someone > > btw tell me hove the libwebrtc patches are generated..? > > > I build and bisected with --disable-webrtc so I did not need the > patches > for that.. > It breaks here: > changeset:   743155:5c5cf716aa0b > user:        Jan de Mooij > > date:        Wed Jun 07 16:34:51 2023 +0000 > summary:     Bug 1835876 part 2 - Disable code write protection in > content processes. r=nbp > > [root@freebsd2 /tmp3/bisect/mozilla-unified]# hg log -r 743154 > changeset:   743154:028f981600d7 > user:        Jan de Mooij > > date:        Wed Jun 07 16:34:51 2023 +0000 > summary:     Bug 1835876 part 1 - Remove unused > ProtectionSetting::Protected. r=nbp > > Related to w^x.. I can only make it work by reverting the whole of the > two above commits... > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081#c7 > ) Still > disabling aslr is required > /Jsm > > > > -- > Nuno Teixeira > FreeBSD Committer (ports) From nobody Sun Dec 17 14:33:27 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StQS552b0z53jFg for ; Sun, 17 Dec 2023 14:33:41 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StQS52cx4z3g1F for ; Sun, 17 Dec 2023 14:33:41 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 5AEA75F315; Sun, 17 Dec 2023 14:33:34 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id D31655EF19; Sun, 17 Dec 2023 14:33:30 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210204; Sun, 17 Dec 2023 15:33:27 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Sun, 17 Dec 2023 15:33:27 +0100 From: Alex Samorukov To: Mark Millard Cc: freebsd-arm Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4StQS52cx4z3g1F On 2023/12/16 18:23, Mark Millard wrote: > > Generally the quarterly 132releng-armv6 builds attempting the full > 34000+ packages resulted in "stopped:crashed". One completed: > > Tue, 01 Aug 2023 04:37:22 GMT crashed, having built: 14831 > Sat, 05 Aug 2023 04:40:30 GMT "done", having built: 26346 > Thu, 07 Sep 2023 02:38:44 GMT crashed, having built: 8272 > Thu, 05 Oct 2023 02:37:41 GMT crashed, having built: 8276 > > (It is harder to judge the total that were available after > an incremental build.) > > All of the 7 "done" quarterly 132releng-armv6 builds are > from 2023-August builds (after Aug-01) and from early > 2023-Sep builds. After that: all crashed. > > Quarterly 132releng-armv6 is the only type of armv6 build > attempted after Mon, 21 Aug 2023 15:02:47 GMT (the last > latest for main-armv6 build that has been attempted). > Long story short - I successfully reverted OS to 13.2 (monolithic nature of the FreeBSD makes it way easier compared to most of the Linux distros) and all works perfectly again. Do you know if i can help to fix crashed builds or contribute somehow to make armv6 packages built for 13.2? For myself, i found that building packages on poudriere running in native arm64 servers is way more efficient compared to qemu on amd64, and now I am running the full build on Azure instance. I know that we are using some arm64 build servers, happy to contribute to having armv6/armv7 builds running on them. Thank you, Oleksij From nobody Sun Dec 17 18:20:34 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StWVF4l0Dz540bg for ; Sun, 17 Dec 2023 18:20:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4StWVF0Rt6z4NcB for ; Sun, 17 Dec 2023 18:20:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702837250; bh=uQ6cVV91XSjTEiNGRxtQgzqlQ/D1rsDbhPsL8uMcreA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WvJCl5r/5HEV0xsE/Kb8InHcOy9grt0IxaNI3Ljhwp/YGqz7kwMrxie21jOCApTyC2E1EwCA6VMrXrFnxkWv3GT2p4cNkvk+8QNz5a+Us5F9IMXl3wub+Cuc+KoNhDA/1IyFuniLzxUCPPmQqh+bwybWIaVfgv4Jb392w27nYpcWQfEXAZdKZ7IKHojHW+Hu5TY8GT5PeA6lKxHn8yLk4jS/UyqOjhc7ZNu/YyJE8dHamiTPH1nYP48K3jTf0ET6QOJUKcaXPJWaZ21iZtSBn907XaMMjixhSGa+yZ3N4ezBS11iYHs9hHHXA0mObT42NV8CjFSD2tAP06YOHh/G+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702837250; bh=/+Eb+bxdVtd5kXHSIIrfbmoxGzWX7WeKB+WdezsCmUn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sOs4MXTGKdnvBiDk3hz+3IBb6GVtPtk0h46WdPOVsM2vwIAkhzOM8KaookItc/IcILZsaA1okSWLYPRT9VrtZIsCpNgleVf9mHVe2MiBctCJdR+n+5MBFspqSbpBqCkNL/rQOmHWzqXiKD204nVvDkWe/XZjU3c5Z22qoS60XdykOEI2VmOnts0edHNoirQm3TdZYDz0t9lOWbxwawgfmEGgUHz8erybfmFfQuHI5hS4d0SpeXPJRAsPwGgh+fYyeQDUkHytpOrJ514vH8M6KVSmi4NT70kyLmRKpu+hk2cQcZAuEUgpj2peyGqudTisSUhLgCTk2uKn71Lqz+e5bQ== X-YMail-OSG: NNPDHJAVM1kzTIT1oEwhrDiuQQBFhJMgcebpldp1aCeEPbPASgb6ip4Rz.qeylZ OeI2CS78avQ9M5GHI3L6RkqDx3nk7QlFqRjO3WdTyaJe5wj6iZuRoRUQfIBjFBrrPLvhEGoGgoT. 8_0t58rg_HAWR.EmuiBxwRLtICdaHg357TZfKqJY81j5pvbsCsaD1IQ3LfFh4kbwLLeNjF3sPq4_ CfpzW9qsk7Im9n0O6VbC1yFQN95f2ZwLbjUAxBg3oYOIaRrqZyQ58yDmaWHzEmCyneJQGRgcuVrK lK0EXcUIXFl0Gczc24Ya8lIA3lZmkQM2SWnWMs3jZ5FfbXv1yXqx4MIljZ.2r8rjXd.o9SKXijfi ugF_bR7TAWz.U.SpTJyMmgO6AFMjENJXMl0V3JNTmH93ryhgtHinX4yAPr2EhChyED0texJs1e8o C9XuepUZG0rx2dYltXsi0p48cuh1QL6s1j5DolH2yGTvW4RRUipZ3nvnfVCfi1JfssF8Y52k4ZSc q.ro6IaibGUSjFSd1SixWMz0eaz0xCd.JjSGiQd5dkfUFa4XAVvZTamlHO.ANHWP2JPwTJPZE09j Sz.Isxblafp0pxmBlqGaHdJB0qyWoJVPiLZmVT4Z1imWwsVZ23b9g1GKpuPPenH6hq2Y4USdhuh_ tEmroIsJ_uZR6_g6BC6I1VdRYnzp62XilGaIOrdWC0VuH21e8H5DiDtmbkeRoIUswhDhF5RFzydZ 7UOro61x5no3CVD5sDAa_iyIawYu6z6MDdEl6BLaVRCR.scCoo1jAP2LmOahjt5mzxfGzK3vQnUx _RCQlt0PYW.WlzoHCUuFZuLWwZ.3n_cVla_XFkJr0ZylKBY1nTV4kOID0TaVNSHu6g1rOMIIIccB j7R7oNeH1jZTdBfTW1a_SfvIVbpysLqCXnRWN3evOtEuxUVqb3HyvhPrfy4oaHwZ9mj2uJEfv7EJ yOQnmJj.vom9qLBkSkJppadIf1yS9NByDNZE3qNMp0hozEgx3FUI1lFMdc1_8ik80ZvEnQP64i0A rR1sRD5D7Nme8l_bqmi.oq4q7X034o3IjXv03PCdtJNFmyCj7dKjwLw.L9LN7PJkRkXhwtqHGZWq AQaj4h6VJCi7TFz_cGZpOPfyX.8b03xQWA2vsT1Ur_CZLjZQlJ8wG6.MIcmkQkw.oJduQHPo8wFA rsJe.4lcUfuTKoDQ7iBUvhWl8IzN_j.kVY2zCBsO1CwkNe_DeokvPC9GlyRTOpAZoWv9hs0Cc963 WR4x1_Y1Ck9pLHNQfoHlE1g2dBU2SuzvzVdAt_3zRm0k8DRNAlZkLMArLQO9lDBfcP6.qBaUNtks dT5jkyGfh1nIEO8lZcAOTizDXL5ROH2fJ7rwe7FluDVSXZ8plD3.aGwI0rRl72YG_AKPzXP6Jh77 X8M.N.7EfIALo9hGxJ23P4yHeMlrEU26l9RjSFXMy0Tzt_dCURyHzMnLTdQ4MbkuNSP8E843H8jH vpCOKxnUVolSAMjEv770bee.0x66Q7aILONjJF.0t3mBg.CXSCR9ixaAjUTS.BxSiQpMHifanrm_ fYBP9w9gbXJs_JnSqIbMGczMwB7c2DPMZibVV1S4v0YRVpvF3no1yQRE._logp.HCHud7b_84M.B mfMGYsF4a3mOuu7g.4f2eIHYMkAJGg4exf.NmoGoRq4bSDJkqqMM7vsLA8MOjzW.9R2BcFAfDvy_ F_Tc6uQdfVC1zRFOo7iO_9G2DXaSU.OrgRQX3T1hG9eJrgG_Vn2yv.3STvh6tGdsEXTWw9aacYym YpIW7Rvs51RpWc8DjHOUcHJeCzkV1J3S1myo8dLwrBBLEwKpZzUvftkWxHri0rQjGvuMgn2WMM0Q nmAF15TJWxGgtYBsiRnvYt.d8WXfDw_LlOB14j2doxxk2S7iLSItGhQo8TNXxKfQcsmC8wXwQViS .vTxPXOMfoGUhU9kqK7JO89S4c44EqTuMezrZ8qKEIJ181x3VqaE.ExaIBoJQ3x_nW3Vu29wXo45 KnJdqxHcLl38_pEhdFzMiNb6eb0bsUZH6DFYwLYsw5EpbYCD3meR_Tcbfh8z.XoEI0nXkrKQ4Zt3 vu6jbKR3ArzWWGYd5AY5eUyuHkaJCWMZFX2H1qNOYEOcXlaqzD8actYO4IT8StaLNpBJMrxv0dEM bkl0_dgFN1SKw_CEuh8SJRBzUECNND7GgYaGMJeXzipIaZGY11hZk_NGdTflFATSy1J8kZScb03G r9Q1huHOaL.b4USnQuXBBSf8JSV9Y9fhfxHxPHWKbSL2McJWzuqsn3212eeP6EGBkaAwEBk3xPQw KxA-- X-Sonic-MF: X-Sonic-ID: 985260c4-fa4b-42d9-b093-ec21cd17dbbd Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Dec 2023 18:20:50 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7473ad3af91ff898ff5578418755223b; Sun, 17 Dec 2023 18:20:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard In-Reply-To: Date: Sun, 17 Dec 2023 10:20:34 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4StWVF0Rt6z4NcB On Dec 17, 2023, at 06:33, Alex Samorukov wrote: > On 2023/12/16 18:23, Mark Millard wrote: >=20 >=20 >> Generally the quarterly 132releng-armv6 builds attempting the full >> 34000+ packages resulted in "stopped:crashed". One completed: >> Tue, 01 Aug 2023 04:37:22 GMT crashed, having built: 14831 >> Sat, 05 Aug 2023 04:40:30 GMT "done", having built: 26346 >> Thu, 07 Sep 2023 02:38:44 GMT crashed, having built: 8272 >> Thu, 05 Oct 2023 02:37:41 GMT crashed, having built: 8276 >> (It is harder to judge the total that were available after >> an incremental build.) >> All of the 7 "done" quarterly 132releng-armv6 builds are >> from 2023-August builds (after Aug-01) and from early >> 2023-Sep builds. After that: all crashed. >> Quarterly 132releng-armv6 is the only type of armv6 build >> attempted after Mon, 21 Aug 2023 15:02:47 GMT (the last >> latest for main-armv6 build that has been attempted). > Long story short - I successfully reverted OS to 13.2 (monolithic = nature of the FreeBSD makes it way easier compared to most of the Linux = distros) and all works perfectly again. >=20 > Do you know if i can help to fix crashed builds or contribute somehow = to make armv6 packages built for 13.2? For myself, i found that building = packages on poudriere running in native arm64 servers is way more = efficient compared to qemu on amd64, and now I am running the full build = on Azure instance. I know that we are using some arm64 build servers, = happy to contribute to having armv6/armv7 builds running on them. The standard FreeBSD kernel for arm64 also supports armv7 (if the hardware does) but not armv6. You can look via: # sysctl kern.supported_archs (But checking for the hardware actually supporting armv7 seems to be recent for contributing to the text generated so armv7 may be falsely claimed. armv6 will not be listed.) See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132#c13 for a suggested way of have FreeBSD support both armv7 and armv6 at the same time. (That is comment #13.) But that would have an implementation effort first. There is an existing way to change a #define and build a kernel that supports armv6 instead of armv7. See the earlier comment #11: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132#c11 I'll note that I've not done such since lib32 support for armv7 was added. armv6 lib32 was not added so using a non-lib32 build of world might be required. poudriere just requires the jail/chroot sort of support for armv6, not lib32 support. The FreeBSD build servers ( ampere[1-3] ) are not booted with such special kernels (or worlds). But they do build armv7 on arm64. armv7 also used to be built via qemu on amd64 and had the same sorts of problems back then that armv6 still has. If you read my other notes in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132 be aware that some later notes correct my errors in my earlier notes, making for a messy read. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 17 19:52:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StYXX5jL9z546XZ for ; Sun, 17 Dec 2023 19:53:00 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StYXX1kWvz4Jbm for ; Sun, 17 Dec 2023 19:53:00 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 841205F315; Sun, 17 Dec 2023 19:52:57 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 6E30D5EF19; Sun, 17 Dec 2023 19:52:55 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210245; Sun, 17 Dec 2023 20:52:51 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Sun, 17 Dec 2023 20:52:51 +0100 From: Alex Samorukov To: Mark Millard Cc: freebsd-arm Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> Message-ID: <7115fd399a58084266b71ecfbd400334@freebsd.org> X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4StYXX1kWvz4Jbm On 2023/12/17 19:20, Mark Millard wrote: root sort of support for armv6, not > lib32 support. > > The FreeBSD build servers ( ampere[1-3] ) are not booted with > such special kernels (or worlds). But they do build armv7 on > arm64. armv7 also used to be built via qemu on amd64 and had > the same sorts of problems back then that armv6 still has. > > If you read my other notes in: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256132 > > be aware that some later notes correct my errors in my earlier > notes, making for a messy read. > Thank you for reply. I had (possibly wrong) the impression that armv7 CPU is compatible with instructions. At least i can perfectly run armv6 binaries (e.g. rpi1 chroot) on armv7, despite the fact that it is "kern.supported_archs: aarch64 armv7". Also i was using this VM for a long time, just to build packages I am using for my old rpi1 (domoticz, ebusd, fresh libraries, etc). Now I am running full bulk and it seems to work fine. I did a small patch to poudrier to make it possible [1], but it seems that upstream does not care about patches anymore. Regarding bug 256132 - so far i cant find that it impacting my builds at all - binaries are running well. I could assume that some configure scripts could try to check (and enable) some flags for armv7 while building, but I think the chances are very low and it could be handled on ad-hoc basis. Please correct me if i am missing something. Thank you, Oleksij [1] https://github.com/freebsd/poudriere/pull/1063 > > === > Mark Millard > marklmi at yahoo.com From nobody Sun Dec 17 21:00:16 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Stb293W2Kz54Dpx for ; Sun, 17 Dec 2023 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Stb291gcNz3Y71 for ; Sun, 17 Dec 2023 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702846817; a=rsa-sha256; cv=none; b=xU3Ue0eviv4L2bOPegestBGEsP1xArNoQESALMuragbFh95RNopTI4sTHEr5drdWDw5w1g iIvGzeRFh39AzDQfPqEXK0Bh2EShJtEGDL6ivfm5284RwGNvZqhv+7MEZ4FSwbswLvhjSb Rnds/H/CLSvVSuRTDxPsF1jYBtBkcGweRbFV68qiCVBzzR8H5Lz210RBn82fTmCYrreaeQ mbC4svWa77X7RiOqq3hRBjwLTLh5clyIEcffQYqqHssJ9M8A88LH9hVtzevdwvqK/9f9pQ 6yuv9Sz5FTpem4DxAvzQHCddu5qqaSUuyvWamk/368oUHf3ZyEoVWF7CrBCQow== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702846817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=+WZWQ6qntMMutvCqWKW2VeLWHuf3412sSSLmhOzg8qU=; b=QN++MxyQzbbcKEIdYFyK6wwMdn+X22gMny0IgpDxOa5j7eGYWBsRdGis/QF1dY+xODMNRa T93KPdjY1CH/KKpXNX+i5rI/cnXdJR2bD3ZpJXbLv3i/ZO1LCEOZ4P0RJkNRRHxK3X6sxd YOv++Q3tgQmgUL3jcvNXWtaKtWClSjaC1LmwfHTa4FIYLn2ljGHq5z3T60V57Ex0xI7mHr XvZjmgUtADJUg3vU4cGyU7FGRNnrLTj44tmAnU2D9hvnPU5H6EB0is33LJeRhYNjTn/31I JapeGYr+yTMwCFheksXmHCa14vtRQnf2JKDiBworraQz1DslSFzZX72MWjl4AA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Stb290bm4zsgV for ; Sun, 17 Dec 2023 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BHL0HKB010254 for ; Sun, 17 Dec 2023 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BHL0H1T010252 for freebsd-arm@FreeBSD.org; Sun, 17 Dec 2023 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202312172100.3BHL0H1T010252@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 17 Dec 2023 21:00:16 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17028468165.F11bDb.8338" Content-Transfer-Encoding: 7bit --17028468165.F11bDb.8338 Date: Sun, 17 Dec 2023 21:00:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 271990 | Panic: IRQ mapping table is full after stress dev Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 256836 | powerd: Enable by default on Raspberry Pi images Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat Open | 264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc 5 problems total for which you should take action. --17028468165.F11bDb.8338 Date: Sun, 17 Dec 2023 21:00:16 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress |    271990 | Panic: IRQ mapping table is full after stress dev
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    256836 | powerd: Enable by default on Raspberry Pi images
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat
Open        |    264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc

5 problems total for which you should take action.
--17028468165.F11bDb.8338-- From nobody Mon Dec 18 00:41:36 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Stgxs06hGz54X7t for ; Mon, 18 Dec 2023 00:41:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Stgxr1BZdz4nyN for ; Mon, 18 Dec 2023 00:41:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702860108; bh=07KZj33r2n4abBCCjGa2yxXrHLbHBTQVlBQtTgnT438=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZMCO5SicEOjotJul6xtVSieETf0WLrh1xUtPGH+q7UlnuW3NoHVUARgvqDISIpwVD5Sh2uCfXxpAFsmYt3gapXAxlohRASrB71YXuwrqPo9SXYIO+XQTldUzP5rNNRZtY2SHTcPnv9uAXU5v2c3MVCpM52yeqV8FWjonRn1fSaobBxys+oC7nCUfQHiWmZcphIG9IvCQRcecwljJwW4LJ6V1xdOVYWjt/Mr7ZnL/Ivzdm7Y/veRu8Vtp7bxywGeoGSvDqgLmFCbyJcu8s6k5ENH0Thrs9HAC5Wz5mL0H0vMfXl/Q+5x9800rPTD76vqmJ6U7KZg0Zznom7/GmqbC+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702860108; bh=G9kVefttL+kxwEXNA7rSnRbke0TVWYHddLn/68pfiy5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RftSkRpWYZvXeR6CURdJur3DLT3whIYNKa+5FlHPZlfOoJlvGJEcNdUHW8aVWu6yt3arqPEBdWu0HCy6IDnUeL3A3ju/y5bUHerDUI+XiMtW8htSipsuS0KBIdjsjXL+r4ApM/xILVnwLTEVmCGv81xdQFZ7iso148BqLJYCXHGw0TABQmBlNEXWgkJjFdn+tx5t/9lyDfRkRZ9v3GoLtCvFro2KOf9vmtRC5tnYzsJ8mXGW6DQqt8P3zQFWXXrWhkVwvw8+7qkh9NSNvswPLjkX3Oa+Fgc3zpnbBqS68Vmuxf/IDbuoHAHIe7NsSQULnzKENbNB/4jdLwuWqwMyGw== X-YMail-OSG: VGI7kKEVM1mNYBDrY.0cnF4H2gp0e0gF5Yxh.rM33izSY0OoAd1rM2zVXuqPVHw ybsQu_2jei._MnSMU2ttVDC7iaEtHfOiwixsvSS97phZDHah.i6kD1k0_dbAJ_vItAIvw3lvgy0D nFfGXqqNcmz1msG02vxCU_jxersEpyttJLY2TC0WS04mL0h_thgICdbS24rV0P79XQs_8TXS2z7R BQMGvVoQi7sT5ibOrGj7cnnHnPlmBGARVcHGAjrX_KDovuRO8Px8jlepEtuRtFWXB4F1gNqO2_Hd KNmXTPOlQVkZckilgwC7.J13WLFVTFLlIZ3W8_JNOr3U.1DYoDPJm5PCpZh1JrGwAcqtkBm7m6Q4 Ibb3IBRWj50NIu8nw8fCWINJF3eyJ8Q.TC9q9k7WtddEgRlZPq1hL5t1qTIK_ZUDEWnLVVFyZC41 aCMJQXxcPq_rz7hrEoZelccRIIx89KvSMlSALLwgnMQQ7yiwWacdzI.dIK0dGzlOl9wGhn1YLnhn 1RbaMeGC7w_MkmI7aCDj4nAncQv4ogv4f4zIRo4EPNdHawPDNIVt84mK2tzEks75zfTm77IHYdBL rWzC_RvxydEwvr2WiLSC2afziDfo.JvtJ_CVUy.pRpwS8ddTXZ_7RMprjC4ebfQwz9_9rsz1gzfs K.eJGu5cPKRDowf2oOr2synC3imDgR8vFvTn353_QNw2gnWOx8GHjmpJWZ0Q8SgJU47e3zXcIkl_ Yy3DOh1oNl6v8yo2UgwvqhOeGuOPafBMdWaQONdFvbF.GOSn_TSn5skJMOfugr5wI4GFhex4uTx_ 5NaswbD3CBNwPsYjZN8p_Tu3b5QaxHd.xRfeK_cxgXgO.TLiLMPk8l.Qs6xZz8wS9ndocmeL5kCJ eqCraEd8YVZBZR.qLTCOHlY6DL4x4gku6Hq8XU3fHhqFfOI.byxgCaR498PH9yt4Y0wVT5KV0ByI gnZe6Gfp9I0hPZEi5TXPqOkdSFzboIz.5h8zhZGMRVkCibLSZi8G_DSJmT9gd22Z56TiDhYXefiG 1EXM7U9S3PSt2.YwtazG.f6ZPe9XpWCbsmVEXuSLM19_DwbLBTNyRj6cdF8JL3WvMXKQB30g6dDe 4bvTgUv0eFbgOLzrdTaf6LoDBKMCnvDngXGrbiREwC1hdljee8VxuyStgNq1xIT3k2hUHV7zHnr9 E_adi4_rikgGPP67XdAYO1nyEIATIvlZaATd859XseAU89a8XmUhZw4qVfHgxUSnf0O9mguY2sb. igj_tADdo0GkutrKD2tOxgKVVYmx23hPCwoEO_cbjNZF8fpDigBIBQ36odgpJU_O79v4paNEABYG p8ltAgAIKY8I9sJocH9dRN1Sfe5jMK4llPEZIpErN8CtM9BzsMbYHmigwTV9DJjYdP8juUy_ZRn3 6gzv734UpS4g6ZZKQQnSAer_OuHkjL57QlW124rOJTnANlARlfaxpXHZQyR4_Br4Offen16UUJ_r mwx0D9CXp.h0ZpLt12.CaKYO.q6Qo5wBjKdSn3j_b75FYpRe28EINhHJtdKUNW8HPWr4DRCmwpKk 3jwyFmmYEfHw0c9dDXDbPX8khv3BDaOdsteVFuvQKGn6_KS8s0tEtygY6fGUKZ01NG1u6wSCuTuZ y53LujH2gZhXllVblagEFuv1dLJqzsYaxn.8vR4gr3cbTRZikXF8OI42nj.M.7BDbTgWl52_OESM eZZsdZLtIT3eMle1JLmfPxofnnWEoSZrzxv.x8rIs41a4PgoPKx0wDqYNdJ.02nZD_8PlUkPX0cl _6syJrrPXpvWI1xn3vtGuaN8omLFzc11FdSavoEGwC2sgcig3ka9XrE6l.0a1PrVaKHKCdQsYBHX QZgsrbxR8fWNqQhGXG6T0u3MOFk7n2hNkzWshwdhD1z_dj5th6kdu_LdbaoSCECuV0GbZV2OQVwf g56Mr3JEjpi3TNN_okJ6d.fbaKXTIL395iO.o2ffDS9X38ALipT64FzeQ4J1ERWbL0tfGu3KZSZF U2WAxmLKvOyDqqt7TLeOMafoRTwkFYLy1uHa4bRsCt.bK7wLKBYJY3PlVRVPMju6mwv5e22BxztL cEL0tq1uagzzEc330mLWDHvoXN9tqIZ7jS24yrAenyNpB0gNQKtBLO5BC_3CQeYJE8nleuRKG2lp vrlTVJYfwj5qQOccRYhGPz3STngwbN2ubp2bulIziP_8cQqkjYmZoWPo98uxqH3jOq3aqPGuCKx1 9lOFkVr6uo6b76v9WhqleUeDrYAQIwePCAi2zD5e0ROFVC8ubZWRZNhLGAlxyriJ1NK8.PngzJvw _FA-- X-Sonic-MF: X-Sonic-ID: 3206c9b8-65bb-4720-b212-7731a8b38832 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Dec 2023 00:41:48 +0000 Received: by hermes--production-gq1-6949d6d8f9-dpfkp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e7a9be320b74ed88dfc576908b173d16; Mon, 18 Dec 2023 00:41:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard In-Reply-To: <7115fd399a58084266b71ecfbd400334@freebsd.org> Date: Sun, 17 Dec 2023 16:41:36 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Stgxr1BZdz4nyN On Dec 17, 2023, at 11:52, Alex Samorukov wrote: > On 2023/12/17 19:20, Mark Millard wrote: > root sort of support for armv6, not >> lib32 support. >> The FreeBSD build servers ( ampere[1-3] ) are not booted with >> such special kernels (or worlds). But they do build armv7 on >> arm64. armv7 also used to be built via qemu on amd64 and had >> the same sorts of problems back then that armv6 still has. >> If you read my other notes in: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132 >> be aware that some later notes correct my errors in my earlier >> notes, making for a messy read. >=20 > Thank you for reply. I had (possibly wrong) the impression that armv7 = CPU is compatible with instructions. But armv6 is not compatible with all armv7 instructions. The issue would be more of making sure armv7 specifics are not put to use so that the result is fully armv6 compatible. > At least i can perfectly run armv6 binaries (e.g. rpi1 chroot) on = armv7, despite the fact that it is "kern.supported_archs: aarch64 = armv7". Also i was using this VM for a long time, just to build packages = I am using for my old rpi1 (domoticz, ebusd, fresh libraries, etc). Now = I am running full bulk and it seems to work fine. I did a small patch = to poudrier to make it possible [1], but it seems that upstream does not = care about patches anymore. >=20 > Regarding bug 256132 - so far i cant find that it impacting my builds = at all - binaries are running well. Is all that testing only on an armv6-only processor? Testing on armv7 or aarch64-that-supports-armv7 would execute code that armv6 would not. > I could assume that some configure scripts could try to check (and = enable) some flags for armv7 while building, but I think the chances are = very low and it could be handled on ad-hoc basis. What have you done to avoid armv7 specific defaults from being used, instead causing armv6 defaults? > Please correct me if i am missing something. Thank you, Oleksij I'll note that I've never done such "armv6-only processor" testing. I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts until after something like 2024-Jan-01. > [1] https://github.com/freebsd/poudriere/pull/1063 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 18 07:16:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Strjj2g0Nz541yw for ; Mon, 18 Dec 2023 07:16:57 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Strjh3MtQz4qbw for ; Mon, 18 Dec 2023 07:16:56 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 724C95F315; Mon, 18 Dec 2023 07:16:55 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 1F7DA5EEAD; Mon, 18 Dec 2023 07:16:54 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210458; Mon, 18 Dec 2023 08:16:50 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 18 Dec 2023 08:16:50 +0100 From: Alex Samorukov To: Mark Millard Cc: freebsd-arm Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Strjh3MtQz4qbw On 2023/12/18 01:41, Mark Millard wrote: ch to poudrier to make it possible [1], but it seems that upstream does not care about patches anymore. >> >> Regarding bug 256132 - so far i cant find that it impacting my builds >> at all - binaries are running well. > > Is all that testing only on an armv6-only processor? Testing on armv7 > or aarch64-that-supports-armv7 would execute code that armv6 would > not. Testing was done on armv6 CPI, RPI1-B board I have. Of course i was not testing everything, as it hard to expect from 512Mb 1CPU board to run Java or Firefox. But at least things like boost, gdb, domoticz, busybox, nginx, ebusd and +-10 other ports I tried are working fine. Now i am running bulk -a to do more extensive checks. > >> I could assume that some configure scripts could try to check (and >> enable) some flags for armv7 while building, but I think the chances >> are very low and it could be handled on ad-hoc basis. > > What have you done to avoid armv7 specific defaults from being used, > instead causing armv6 defaults? I think it should be done out of the box. As I am using chroot from armv6 - the compiler by default should generate armv6 code, otherwise it would be cross-compilation which you have to specify explicitly. Also, it probably will be a good idea to add corresponding `-m` flags to default C/CXX flags. What I need to check - is if llvm* compiled from ports is still assuming that the target is the correct one. I will do that once my bulk run is complete and will let you know the results. I also think that this situation is not that much different from i386 compilation on amd64, potentially some "too smart" configure scripts may detect extensions that are not supposed to be present on i386 and build a broken binary, but in 90+% cases, it should not be the thing as compiler will have default target set correctly. > >> Please correct me if I am missing something. Thank you, Oleksij > > I'll note that I've never done such "armv6-only processor" testing. > I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts > until after something like 2024-Jan-01. Anyway, thank you for your help. Maybe I will get +1 board (they are very cheap now anyway) to set up as a playground and testing. Especially because we may get a very similar situation at some point with v8+ arms on 64-bit :) From nobody Mon Dec 18 07:34:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sts5S0Kjjz543G3 for ; Mon, 18 Dec 2023 07:34:04 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sts5R3CrMz3Y0s for ; Mon, 18 Dec 2023 07:34:03 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 803165F315; Mon, 18 Dec 2023 07:34:04 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 457A45EEAD; Mon, 18 Dec 2023 07:34:04 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210462; Mon, 18 Dec 2023 08:34:00 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 18 Dec 2023 08:34:00 +0100 From: Alex Samorukov To: Mark Millard Cc: freebsd-arm Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sts5R3CrMz3Y0s On 2023/12/18 01:41, Mark Millard wrote: > > I'll note that I've never done such "armv6-only processor" testing. > I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts > until after something like 2024-Jan-01. I also checked llvm compilation logs: -- LLVM host triple: armv6-portbld-freebsd13.2-gnueabihf -- LLVM default target triple: armv6-portbld-freebsd13.2-gnueabihf So I would expect it will not use armv7 instructions based on the "host" (jail) EABI. Also, I see that rust is failing to build: rust-1.74.1.log:=>> Ignoring lang/rust: is only for aarch64 amd64 armv7 i386 powerpc powerpc64 powerpc64le riscv64, while you are running armv6 (reason: requires prebuilt bootstrap compiler) Not sure if it's done due to qemu problem or not, maybe will try to remove ignore later and rebuild From nobody Mon Dec 18 11:35:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StyTD04Vlz54Mxq for ; Mon, 18 Dec 2023 11:36:32 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StyTB6Zgjz3Nkt for ; Mon, 18 Dec 2023 11:36:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BgJ9nWwZ; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a2339262835so146714066b.3 for ; Mon, 18 Dec 2023 03:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702899389; x=1703504189; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6zskf91JQlo9rv3pcoUGp34TFtNJeX/tHF+tTPRwehU=; b=BgJ9nWwZporMz8wJsZKi+0eDxrfISAm2ENETRc2NhJW0cDwDcMyH0taxxQVsa0n5LX x6TA69JwZ10JbjmvyNEMnley6AewM9pUv2Wie4TimIMLsBSnCuG/v3PTS3Aaogv5LTLf zG9WmlBvSXbjGaVnRv8IgoD/kPbxJ0gqoieT4FJ7a6cIqyzJIrImDLu7kXBdxHxs0aui IFFTBoYUVYBvytp3PwAbffWyq8loXwAN+C06y46NYM3+LZgsyY/H5pDlQZTQUnLEOBDo lL2T1f1i0K3CdnpOV0EDuYuyIu1czN8v5sxTnKLhgElqahq0Ns3u6gNVtQj3+HNlHFGt Ls9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702899389; x=1703504189; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6zskf91JQlo9rv3pcoUGp34TFtNJeX/tHF+tTPRwehU=; b=rIxjASLxYmQ+PM7YDH2XFpgclJ+ZC7RbEAHK0p5cHOl4ahPGxQ2oTcMjrl/zUAi4YY IpUkTIQnDSmil0248gue/eldGQn0JIzBAJTA2/8muj4VYbI+/UfSgllEgIwuUOEakdlD 7ioOFUMVFL/h1PvVCp0YjwEgeZ7g1nLeS7ASPihRAyYhP9Bt8SVSU2crMitrnK2kZ0Q4 Uup7UdL+rU24BKRUPC3lVDqSQaYQUknPBw1/EKNbNhZ86Tfd6scTVuqjiu8C63b8o3yZ TQ/JpqxuR6K+TaM8LG/DrGK32mVMM4d8ECvO27ePzsh214+bdwnfp1Mv6SpvNUt+TAlB VsYQ== X-Gm-Message-State: AOJu0YwuRnNyDJgAzZxcXixiFJ0k9rCF5wisqKAAHd5DAYEJu8jWfBrB JNrq29g6PMzl5WkPjoVmGZb67uCXqVTyVUEBSSZZBLRoWyShOg== X-Google-Smtp-Source: AGHT+IHkHqrE8tQgYDQ7WIvJVvEgv2MDB37UciQsCxBpLOsANlO5sEf0eHQ3URRYcD0u80FzTLMl7rLEWeSgKL9TnCM= X-Received: by 2002:a17:906:413:b0:a19:a19b:78bf with SMTP id d19-20020a170906041300b00a19a19b78bfmr7182700eja.130.1702899388796; Mon, 18 Dec 2023 03:36:28 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Mon, 18 Dec 2023 12:35:51 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000285706060cc729f7" X-Spamd-Result: default: False [-2.64 / 15.00]; URI_COUNT_ODD(1.00)[65]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_LONG(-0.97)[-0.969]; NEURAL_HAM_SHORT(-0.68)[-0.681]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4StyTB6Zgjz3Nkt X-Spamd-Bar: -- --000000000000285706060cc729f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> There are no specific options in u-boot devoted to FreeBSD This is an important factor. So,what about if,instead of compiling a new version of u-boot on the partition 2,I will recompile the u-boot customized version created by the virtual open system in 2014,that should be installed on the first partition ? It could work if there are no differences between the u-boot that should boot Linux and the u-boot that should boot FreeBSD. Can you give a look at the u-boot source code created by virtual open systems ? You can find it on my google drive : https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp= =3Dsharing I need to understand if I can recompile it without problem so that it can satisfy my needs (the ability of the file u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano Stabellini,the xen developer that suggested to me what I could do to have FreeBSD virtualized under Xen on my Arm Chromebook) ; otherwise the risk is to find later problems that will make me troubles and that I will not able to fix. I gave a look at the virtual open system u-boot and I didn't see any arndale_defconfig inside. So,If I have understood correctly,I should put that file inside the root of the u-boot source code,let's say here : marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls .checkpatch.conf README doc net .git api drivers onenand_ipl .gitignore arch dts post COPYING board examples rules.mk CREDITS boards.cfg fs scripts MAINTAINERS common include snapshot.commit MAKEALL config.mk lib spl Makefile cros mkconfig test PRESUBMIT.cfg disk nand_spl tools and I should do : make and make install ? and the file I need,u-boot.bin will be generated ? I didn't find any pre made configuration file inside : u-boot-vos # find . -type f -name "exynos*" ./include/exynos-fb.h ./include/configs/exynos5-common.h ./doc/device-tree-bindings/spi/exynos-spi.txt ./doc/device-tree-bindings/usb/exynos-usb.txt ./drivers/power/exynos-tmu.c ./drivers/power/exynos-cpufreq.c ./drivers/video/exynos-fb.c ./drivers/spi/exynos_spi.c ./board/samsung/dts/exynos5250-spring.dts ./board/samsung/dts/exynos5250-smdk5250.dts ./board/samsung/dts/exynos5250-snow.dts ./board/samsung/dts/exynos5250-daisy.dts ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h ./arch/arm/dts/exynos5250.dtsi ./arch/arm/dts/exynos-periph-id.dtsi ./arch/arm/cpu/armv7/exynos5/exynos_cache.c u-boot-vos # find . -type f -name "arndale*" For sure I can't use a newer version of u-boot because otherwise the patches needed to bypass the bootloader protections of the Arm Chromebook (such as a lot of different patches needed to boot correctly Linux) will be broken ; anyway,since it works,I don't need to use an updated version of u-boot. ----> As per my experience, you have to respect these two options, compiling u-boot for FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/f= iles/FreeBSD_Fragment It says that I should use these parameters : CONFIG_ARMV7_NONSEC=3Dn CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy These are the parameters used to configure a Linux kernel. I don't understand what's the relation between the compilation of a linux kernel and u-boot. In the past I tried to recompile u-boot,but I didn't have the need to set up those parameters,so I don't know how to do it (but I know how to recompile a Linux kernel). ---> I'm not sure that I'm getting you right, as I don't understand what you mean under "the first u-boot". I'm talking about first u-boot because the whole procedure to boot Linux on the ARM Chromebook,that's explained here : http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ at some point they say : To be able to run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to the introduction of the virtualization extensions), up until now all booting methods would boot the kernel in the standard Supervisor mode. For the ARM Chromebook the default boot procedure doesn't allow us to boot in hypervisor mode. Although the laptop's boot mechanism is based on the frequently used u-boot, the binary is located in RO memory. Fortunately, a chained u-boot mechanism can be used (i.e. starting another u-boot after the original). We can then enter hypervisor mode from our custom iteration of u-boot and subsequently load our kernel and userspace. So,the first u-boot is the u-boot provided by virtual open systems,that's able to chainload the "u-boot binary located in RO memory" , that does not boot Chrome OS in hypervisor mode. We don't need it if we want to boot Linux with kvm or xen enabled. On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < stanislav.silnicki@mailgate.us> wrote: > I'm not an expert in the topic, I only know, that ARM has divided hardwar= e > into two worlds - Secure and Not-So, strictly limiting any software, > running in non-secure world with access to functions and resources. > https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hard= ware-architecture?lang=3Den > > I'm not sure, that I'm getting you right, as I don't understand what you > mean under "the first u-boot". > > As I understand, virtualization (HYP) is running in non-secure world ( > https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectu= re/The-System-Level-Programmers--Model/The-Virtualization-Extensions), > so my guess (only guess!!!), virtualization software has to prepare > (configure) HW platform in the way, that FreeBSD kernel will not lack any > resources, required to configure MPU, VA, etc. > So, if you lucky to boot virtualizer, which is aware of target OS, that > maybe you can boot the kernel. Although, I doubt, that you need to boot > 'second' u-boot to boot the kernel - there is simply ubldr, which you can > hook somehow from virtualizer.... > > Stan > > > > Mario Marietto wrote: > > > ---> As I understand, it makes sure that u-boot keeps in secure mode > during boot and passes control to ubldr, which boots FreeBSD kernel, in > that mode. > > Can you elaborate your sentence more ? I know that the bootloader secure > mode is bypassed by the virtual open systems u-boot. Are you saying that > when the control passes to the second u-boot,it will happen in secure > mode,so that the bypass that happened loading the first u-boot,is annulle= d > ? If this is true,maybe can I boot FreeBSD using the virtual-open-system > custom u-boot ? Is this compatible with FreeBSD ? Where can I find the > u-boot.bin that the xen developer talked about ? thanks bro'. > > > > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > >> Hi Mario, >> >> U-Boot beast is hiding in this den: >> https://source.denx.de/u-boot/u-boot.git >> I took a brief look at your post and it seems to me, that option >> CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit >> platform: >> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kc= onfig?ref_type=3Dheads#L3 >> >> As for compiling the u-boot, it is a doable task, given that you >> understand what you are doing. There are no specific options in u-boot >> devoted to FreeBSD. It is a boot loader, whose mission to make basic >> hardware initialization, read you kernel file from some media into RAM a= nd >> then pass it control. >> >> Basically, you can grab some defconfig, prepared for any other Exynos525= 0 >> based board (say, this one: >> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defco= nfig?ref_type=3Dheads) >> and adopt it somehow. >> >> As per my experience, you have to respect these two options, compiling >> u-boot for FreeBSD: >> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-maste= r/files/FreeBSD_Fragment >> >> As I understand, it makes sure, that u-boot keeps in secure mode during >> boot and passes control to ubldr, which boots FreBSD kernel, in that mod= e. >> Otherwise, there a lot of surprises you may realize. >> >> Hope, this will help to progress you tasks >> Stan >> >> Mario Marietto wrote: >> >> >> Hello. >> >> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. >> Basically there are two ways to accomplish this task : >> >> 1) to write a patch that allows the FreeBSD kernel to boot as a zImage >> file. This could be accomplished applying this patch to a specific file >> that's on the source code of FreeBSD : >> >> >> >> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035= f986c979edef0c9 >> >> >> >> This patch was written by Julien Grall a lot of time ago and now it does >> not work anymore. This is the reason : >> >> >> 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. An= d >> I'm not able to fix it. >> >> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : >> >> >> I was trying to explain why and how Julien's patch works so that you >> could be the one to re-do something similar or fix the patch on the Free= BSD >> kernel that you are working with. I am happy to help review and write >> patches but I don't work with the FreeBSD kernel so I wouldn't be able t= o >> help you quickly. However, I might have a suggestion. Do you know if >> FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xen= on >> ARM guest firmware/bootloader. You should be able to build U-Boot and us= e >> the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD fr= om >> disk or network and start it. For instance as domU config file: >> >> kernel=3D"/home/petalinux/u-boot.bin" >> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >> >> I know it is important to build u-boot with the following config to make >> it work on Xen. >> >> CONFIG_CMO_BY_VA_ONLY=3Dy >> >> >> >> This option seems more doable to me according to my knowledge. But I nee= d >> to understand how to do it. >> >> Well,let's say that on the ARM Chromebook I'm forced to use and install = a >> customized version of u-boot,created by virtual open systems,because it = is >> the only one that allows bypassing its bootloader protection. You can fi= nd >> more information here : >> >> >> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/= ?vos=3Dtech >> >> This is the relevant section to read : >> >> >> Bootloader : >> >> If you wish to skip this chapter you can download a pre-compiled binary >> of the bootloader: >> >> >> $ wget >> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_= u-boot-snow.kpart >> >> >> To be able to run KVM on ARM platforms, the kernel has to be booted in >> hypervisor mode. Because of this relatively recent requirement (due to t= he >> introduction of the virtualization extensions), up until now all booting >> methods would boot the kernel in the standard Supervisor mode. For the A= RM >> Chromebook the default boot procedure doesn't allow us to boot in >> hypervisor mode. Although the laptop's boot mechanism is based on the >> frequently used u-boot, the binary is located in RO memory. Fortunately,= a >> chained u-boot mechanism can be used (i.e. starting another u-boot after >> the original). We can then enter hypervisor mode from our custom iterati= on >> of u-boot and subsequently load our kernel and userspace. >> >> Checkout the needed u-boot code : >> >> >> $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ >> ./scripts/build.sh >> >> >> If successful, a message about how to copy the bootloader on the USB >> flash disk or SD card will appear. We will use it later when preparing t= he >> boot medium to start our system. If you have followed the Setting up the >> boot medium chapter and you have a prepared boot device, then you can >> update u-boot by running : >> >> >> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >> >> >> >> so,the needed u-boot that we must use should be installed on the first >> partition of the sd card. >> >> There is another relevant section to read : >> >> >> Setting up the boot medium >> >> Now it is time to copy all the relevant files that we created in the >> previous chapters,and use them to boot Chromebook with a different kerne= l >> and OS. In all these examples the device /dev/sdX is used. Take extra ca= re >> to change the examples to the device that you have attached. Insert the >> boot medium on your workstation and carefully execute the following step= . >> First we need to properly format the boot medium. >> >> In the uboot source directory : >> >> >> $ sudo ./scripts/sdcard.sh /dev/sdX >> >> >> This will erase all data and create 4 partitions in the medium, along >> with copying the u-boot binary to the first partition: >> >> >> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >> Partition 2 =3D not used >> Partition 3 =3D EXT2 partition for u-boot files (uImage and >> exynos5250-snow.dtb) >> Partition 4 =3D EXT4 partition for userspace files >> >> >> With u-boot being copied, next is the kernel image and DTB file. From th= e >> kernel source execute : >> >> >> $ mkdir ../mnt/ >> $ sudo mount /dev/sdX3 ../mnt/ >> $ sudo cp arch/arm/boot/uImage ../mnt/ >> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >> $ sudo umount /dev/sdX3 >> >> >> Finally, we have to copy the Ubuntu userspace filesystem that we created >> earlier: >> >> >> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount >> /dev/sdX4 >> >> >> >> Now,my idea is to chainload the already chain loaded u-boot created by >> V.O.S to the new u-boot that we need for booting FreeBSD and that can be >> installed in the partition n.2,as shown in this scheme,because it is not >> used : >> >> >> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >> bit,compatible with FreeBSD on this partition) >> Partition 3 =3D EXT2 partition for u-boot files (uImage and >> exynos5250-snow.dtb) >> Partition 4 =3D EXT4 partition for userspace files >> >> >> Take in consideration that default boot string is hardcoded here,in the >> snow.h file of the custom u-boot created by VOS : >> >> >> >> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/= snow.h#L101 >> >> >> >> and it needs to be recompiled because it should point to the partition >> n.2,where I will install the u-boot files as explained here : >> >> >> https://wiki.freebsd.org/arm/Chromebook >> >> >> I have some questions to ask before I start working on this. >> >> 1) The xen developer said : >> >> >> You should be able to build U-Boot and use the U-Boot binary as Xen gues= t >> kernel... >> >> >> >> where is the u-boot binary,according to this document ? >> >> https://wiki.freebsd.org/arm/Chromebook >> >> I don't see it. >> >> >> 2) where is the source code of the file that I can get here : >> >> >> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/n= v_uboot-snow-simplefb.kpart.bz2 >> >> I need the source code if I want to recompile u-boot so that it can poin= t >> to the partition 4. >> >> Maybe it can be found on this link : >> >> http://linux-exynos.org/dist/chromebook/nv_uboot/ >> >> but it can't be opened.... >> >> >> 3) in this specific scenario the source code of u-boot should run on arm >> 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model >> XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A1= 5) >> Soc. >> >> >> 4) I'm not sure if I can chainload the customized u-boot created by V.O.= S >> that should be installed on the first partition with the u-boot tailored >> for booting FreeBSD that should be installed on the partition 2.... >> >> >> 5) the xen developer said that u-boot should be compiled enabling this >> option : >> >> >> Code: >> >> CONFIG_CMO_BY_VA_ONLY=3Dy >> >> >> >> Well,can you provide some good source that can help me to understand how >> I can recompile u-boot for FreeBSD ? thanks. >> >> -- >> Mario. >> >> > > -- > Mario. > > --=20 Mario. --000000000000285706060cc729f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> There are no specific options in u-boot devot= ed to=20 FreeBSD

This is an important factor. So,what = about if,instead of compiling a new version of u-boot on the partition 2,I = will recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first partition ? It could wor= k if there are no differences between the u-boot that should boot Linux and= the u-boot that should boot FreeBSD.

Can you give= a look at the u-boot source code created by virtual open systems ? You can= find it on my google drive :


I need to understand if I can = recompile it without problem so that it can satisfy my needs (the ability o= f the file u-boot.bin to boot FreeBSD as domU under Xen,as explained by Ste= fano Stabellini,the xen developer that suggested to me what I could do to h= ave FreeBSD virtualized under Xen on my Arm Chromebook) ; otherwise the ris= k is to find later problems that will make me troubles and that I will not = able to fix.

I gave a look at the virtual ope= n system u-boot and I didn't see any arndale_defconfig inside. So,I= f I have understood correctly,I should put that file inside the root of the= u-boot source code,let's say here :

marietto:/home= /marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls
<= div>=C2=A0
.check= patch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0net
.git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
.gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exa= mples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0rules.mk
CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0spl
Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0too= ls

and I should do : make and make install ? and the file I need,u-boot.bi= n will be generated ?=C2=A0

I didn't find any pre made configuration f= ile inside :

u-boot-vos # find . -type f -name "exynos*"=C2=A0

./include/exynos-fb.h
./include/configs/exynos5-common.h
./doc/device-tree-bindings/spi/exynos-spi.txt
./doc/device-tree-bindings/usb/exynos-usb.txt
./drivers/power/exynos-tmu.c
./drivers/power/exynos-cpufreq.c
./drivers/video/exynos-fb.c
./drivers/spi/exynos_spi.c
./board/samsung/dts/exynos5250-spring.dts
./board/samsung/dts/exynos5250-smdk5250.dts
./board/samsung/dts/exynos5250-snow.dts
./board/samsung/dts/exynos5250-daisy.dts
./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
./arch/arm/dts/exynos5250.dtsi
./arch/arm/dts/exynos-periph-id.dtsi
./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0

u-boot-vos # find . -type f -name "a= rndale*"

For sure I can't use a newer version of u-boot because otherwise the= patches needed to bypass the bootloader protections of the Arm Chromebook = (such as a lot of different patches needed to boot correctly Linux) will be= broken ; anyway,since it works,I don't need to use an updated version = of u-boot.

----> As per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

<= font size=3D"4">
<= div>It says that I should use these parameters :

C= ONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

These are the parameters used to configure a Linux kernel. I don'= ;t understand what's the relation between the compilation of a linux ke= rnel and u-boot. In the past I tried to recompile u-boot,but I didn't h= ave the need to set up those parameters,so I don't know how to do it (b= ut I know how to recompile a Linux kernel).


---> I'm not sure that I'm getting you right, as = I don't understand what you mean under "the first u-boot".

=


I'm talking about first u-boot because the whole proc= edure to boot Linux on the ARM Chromebook,that's explained here :

http://www.virtualopensystems.com/en/solutions/guides/kvm-on= -chromebook/


at some point they say :


To be able to run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.

For the ARM Chromebook the default boot procedure doesn't allow us t= o boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

So,the first u-boot is the u-boot provided by virtual= open systems,that's able to chainload the "u-boot binary located = in RO memory" , that does not boot Chrome OS in hypervisor mode. We do= n't need it if we want to boot Linux with kvm or xen enabled.

=
On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
I'm not an expert in the topic,= I only know, that ARM has divided hardware into two worlds - Secure and No= t-So, strictly limiting any software, running in non-secure world with acce= ss to functions and resources.=C2=A0https://developer.arm.com/documentation/den0013/d/Security= /TrustZone-hardware-architecture?lang=3Den

I= 'm not sure, that I'm getting you right, as I don't understand = what you mean under "the first u-boot".

As I understand, virtualization (HYP) is running in non-secure world (https://developer.arm.com/documentation/ddi0406/c/System= -Level-Architecture/The-System-Level-Programmers--Model/The-Virtualization-= Extensions), so my guess (only guess!!!), virtualization software has t= o prepare (configure) HW platform in the way, that FreeBSD kernel will not = lack any resources, required to configure MPU, VA, etc.
So, if y= ou lucky to boot virtualizer, which is aware of target OS, that maybe you c= an boot the kernel. Although, I doubt, that you need to boot 'second= 9; u-boot to boot the kernel - there is simply ubldr, which you can hook so= mehow from virtualizer....

Stan

<= /div>


Mario Marietto wrote:

---> As=20 I understand, it makes sure that u-boot keeps in secure mode during boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.

Can you elaborate your sentence more ? I know that the= bootloader secure mode is bypassed by the virtual open systems u-boot. Are= you saying that when the control passes to the second u-boot,it will happe= n in secure mode,so that the bypass that happened loading the first u-boot,= is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-op= en-system custom u-boot ? Is this compatible with FreeBSD ? Where can I fin= d the u-boot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM S= tanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot=C2=A0 beas= t is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that=20 option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to=20 your target armv7 32 bit=20 platform:=C2=A0https:/= /source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_= type=3Dheads#L3

As=20 for compiling the u-boot, it is a doable task, given that you understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then pass= =20 it control.

Basically, you can grab some defconfig,=20 prepared for any other Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads)=20 and adopt it somehow.

As per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during boot= =20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.

Hope, this=20 will help to progress you tasks
Stan
<= div dir=3D"auto" id=3D"m_-5077711917547611557m_-962663937491960362m_5085590= 471051268986tmjah_g_1299">
Mario=20 Marietto wrote:


H= ello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.= =20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And= =20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= =20 work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need= =20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of= =20 the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ c= d=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with= =20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the= =20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/dist= files/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point= =20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_= uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW&quo= t; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I= =20 can recompile u-boot for FreeBSD ?=20 thanks.
--
Mario.
=20 =20 =20 =20 =20

--
Mario.
=20 =20 =20

--
Mario.
--000000000000285706060cc729f7-- From nobody Mon Dec 18 11:39:47 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StyYk20pHz54N11 for ; Mon, 18 Dec 2023 11:40:26 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StyYj3FY0z3TMm for ; Mon, 18 Dec 2023 11:40:25 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=RVjWgCRy; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-552d39ac3ccso4804928a12.0 for ; Mon, 18 Dec 2023 03:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702899624; x=1703504424; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vHNN6VmG6sf9HCs5L8+gO72OusoD2FKHsQu+tzTMeKM=; b=RVjWgCRyEoHwW7xr0ffBW+nzNxObebw3585IiMF5FNo5V8WTqG3VO7UJNnnuoKxpe5 aOMLyHsUJj/OOzuM2Q/k+2U+0wz32VTUFXdXEHsn5jDbA0rRSdqgEJz+S2Z1eoLeh+jF txzTDgZYv5hwXNmltzmoXwffst350fy5ZAwmQp6k0suDw/FzRBsv4EhqRLTPGharoCo/ NHsO4/ShRIXi8dXbMD4gqzuBkOhQQ8zJIzHyDkfVgIkHN9cGcTEtf9gSahbcvinZkASq rnC/lx9slbb/d1oL7scHqo/ZrGhObo7PTAXtbohbu84ozqfxGceBUGWV3fs3JgJy+YXY pb6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702899624; x=1703504424; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vHNN6VmG6sf9HCs5L8+gO72OusoD2FKHsQu+tzTMeKM=; b=EXbtF5jCggEXeQRd8Vzcbn8hlOoR44juRrMocA/YJ/PusvOGKySfcAG9LhyhhrShh8 zK0RCd63nG2JyPRStC0Reuj0eW5vkm2xJ7EUJoRH+ifOZGH/ZIiBiGTgpNEYdfyGd5lj FwRrHYyZdeDOj1WuymEMYc99A3tHbq0R1bH4o9a2/U1Z6MpswlMPqUCepVrIdKpvwUWt so87NCk/LuWqmjVAa4PAAh6mtH/HfhLfGoMhY4mXBP19fW0WFZ48cSjEmATs+z4Edm3k VMww47tkFLwch1l/JF9c0v4U/JWaJaFdpO9i2v7RbFa5FrLnQqhE3iVWy6+vo0RL3vXG tr3w== X-Gm-Message-State: AOJu0YyADlTztQv4WkDpnzqtKzjpTFYDvI6rDs9T2b6eHxrDrvpTU7I4 UjY1T6hijg2Asu59Yi3nMDWznexHz7UujU1ZBZY= X-Google-Smtp-Source: AGHT+IE4f1QUnr1bk7YR0TWn4v4fpKMC/qIOZpKbF7ov8xGSQXjcw6QdTPjnMQtf9tYT51t50/gwCsfHLFiPnuIyvEM= X-Received: by 2002:a17:906:3f56:b0:a1d:b9d2:2af0 with SMTP id f22-20020a1709063f5600b00a1db9d22af0mr13398006ejj.1.1702899623397; Mon, 18 Dec 2023 03:40:23 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Mon, 18 Dec 2023 12:39:47 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000241867060cc737b6" X-Spamd-Result: default: False [-2.64 / 15.00]; URI_COUNT_ODD(1.00)[65]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_LONG(-0.97)[-0.969]; NEURAL_HAM_SHORT(-0.68)[-0.681]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4StyYj3FY0z3TMm X-Spamd-Bar: -- --000000000000241867060cc737b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So,ok,I should have said "the second u-boot" ; since the first u-boot binary is the "u-boot binary located in the RO memory" of the Chromebook". Sorry for the confusion. On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto wrote: > ---> There are no specific options in u-boot devoted to FreeBSD > > This is an important factor. So,what about if,instead of compiling a new > version of u-boot on the partition 2,I will recompile the u-boot customiz= ed > version created by the virtual open system in 2014,that should be install= ed > on the first partition ? It could work if there are no differences betwee= n > the u-boot that should boot Linux and the u-boot that should boot FreeBSD= . > > Can you give a look at the u-boot source code created by virtual open > systems ? You can find it on my google drive : > > > https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?us= p=3Dsharing > > I need to understand if I can recompile it without problem so that it can > satisfy my needs (the ability of the file u-boot.bin to boot FreeBSD as > domU under Xen,as explained by Stefano Stabellini,the xen developer that > suggested to me what I could do to have FreeBSD virtualized under Xen on = my > Arm Chromebook) ; otherwise the risk is to find later problems that will > make me troubles and that I will not able to fix. > > I gave a look at the virtual open system u-boot and I didn't see any arnd= ale_defconfig > inside. So,If I have understood correctly,I should put that file inside t= he > root of the u-boot source code,let's say here : > > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > > .checkpatch.conf README doc > net > .git api drivers > onenand_ipl > .gitignore arch dts > post > COPYING board examples > rules.mk > CREDITS boards.cfg fs > scripts > MAINTAINERS common include > snapshot.commit > MAKEALL config.mk lib > spl > Makefile cros mkconfig > test > PRESUBMIT.cfg disk nand_spl > tools > > and I should do : make and make install ? and the file I need,u-boot.bin > will be generated ? > > I didn't find any pre made configuration file inside : > > u-boot-vos # find . -type f -name "exynos*" > > ./include/exynos-fb.h > ./include/configs/exynos5-common.h > ./doc/device-tree-bindings/spi/exynos-spi.txt > ./doc/device-tree-bindings/usb/exynos-usb.txt > ./drivers/power/exynos-tmu.c > ./drivers/power/exynos-cpufreq.c > ./drivers/video/exynos-fb.c > ./drivers/spi/exynos_spi.c > ./board/samsung/dts/exynos5250-spring.dts > ./board/samsung/dts/exynos5250-smdk5250.dts > ./board/samsung/dts/exynos5250-snow.dts > ./board/samsung/dts/exynos5250-daisy.dts > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h > ./arch/arm/dts/exynos5250.dtsi > ./arch/arm/dts/exynos-periph-id.dtsi > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c > > u-boot-vos # find . -type f -name "arndale*" > > For sure I can't use a newer version of u-boot because otherwise the > patches needed to bypass the bootloader protections of the Arm Chromebook > (such as a lot of different patches needed to boot correctly Linux) will = be > broken ; anyway,since it works,I don't need to use an updated version of > u-boot. > > ----> As per my experience, you have to respect these two options, > compiling u-boot for FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > It says that I should use these parameters : > > CONFIG_ARMV7_NONSEC=3Dn > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > These are the parameters used to configure a Linux kernel. I don't > understand what's the relation between the compilation of a linux kernel > and u-boot. In the past I tried to recompile u-boot,but I didn't have the > need to set up those parameters,so I don't know how to do it (but I know > how to recompile a Linux kernel). > > > ---> I'm not sure that I'm getting you right, as I don't understand what > you mean under "the first u-boot". > > > I'm talking about first u-boot because the whole procedure to boot Linux > on the ARM Chromebook,that's explained here : > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ > > > at some point they say : > > > To be able to run KVM on ARM platforms, the kernel has to be booted in > hypervisor mode. Because of this relatively recent requirement (due to th= e > introduction of the virtualization extensions), up until now all booting > methods would boot the kernel in the standard Supervisor mode. > > For the ARM Chromebook the default boot procedure doesn't allow us to boo= t > in hypervisor mode. Although the laptop's boot mechanism is based on the > frequently used u-boot, the binary is located in RO memory. Fortunately, = a > chained u-boot mechanism can be used (i.e. starting another u-boot after > the original). We can then enter hypervisor mode from our custom iteratio= n > of u-boot and subsequently load our kernel and userspace. > > So,the first u-boot is the u-boot provided by virtual open systems,that's > able to chainload the "u-boot binary located in RO memory" , that does no= t > boot Chrome OS in hypervisor mode. We don't need it if we want to boot > Linux with kvm or xen enabled. > > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > >> I'm not an expert in the topic, I only know, that ARM has divided >> hardware into two worlds - Secure and Not-So, strictly limiting any >> software, running in non-secure world with access to functions and >> resources. >> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-har= dware-architecture?lang=3Den >> >> I'm not sure, that I'm getting you right, as I don't understand what you >> mean under "the first u-boot". >> >> As I understand, virtualization (HYP) is running in non-secure world ( >> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architect= ure/The-System-Level-Programmers--Model/The-Virtualization-Extensions), >> so my guess (only guess!!!), virtualization software has to prepare >> (configure) HW platform in the way, that FreeBSD kernel will not lack an= y >> resources, required to configure MPU, VA, etc. >> So, if you lucky to boot virtualizer, which is aware of target OS, that >> maybe you can boot the kernel. Although, I doubt, that you need to boot >> 'second' u-boot to boot the kernel - there is simply ubldr, which you ca= n >> hook somehow from virtualizer.... >> >> Stan >> >> >> >> Mario Marietto wrote: >> >> >> ---> As I understand, it makes sure that u-boot keeps in secure mode >> during boot and passes control to ubldr, which boots FreeBSD kernel, in >> that mode. >> >> Can you elaborate your sentence more ? I know that the bootloader secure >> mode is bypassed by the virtual open systems u-boot. Are you saying that >> when the control passes to the second u-boot,it will happen in secure >> mode,so that the bypass that happened loading the first u-boot,is annull= ed >> ? If this is true,maybe can I boot FreeBSD using the virtual-open-system >> custom u-boot ? Is this compatible with FreeBSD ? Where can I find the >> u-boot.bin that the xen developer talked about ? thanks bro'. >> >> >> >> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >> stanislav.silnicki@mailgate.us> wrote: >> >>> Hi Mario, >>> >>> U-Boot beast is hiding in this den: >>> https://source.denx.de/u-boot/u-boot.git >>> I took a brief look at your post and it seems to me, that option >>> CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit >>> platform: >>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/K= config?ref_type=3Dheads#L3 >>> >>> As for compiling the u-boot, it is a doable task, given that you >>> understand what you are doing. There are no specific options in u-boot >>> devoted to FreeBSD. It is a boot loader, whose mission to make basic >>> hardware initialization, read you kernel file from some media into RAM = and >>> then pass it control. >>> >>> Basically, you can grab some defconfig, prepared for any other >>> Exynos5250 based board (say, this one: >>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defc= onfig?ref_type=3Dheads) >>> and adopt it somehow. >>> >>> As per my experience, you have to respect these two options, compiling >>> u-boot for FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> >>> As I understand, it makes sure, that u-boot keeps in secure mode during >>> boot and passes control to ubldr, which boots FreBSD kernel, in that mo= de. >>> Otherwise, there a lot of surprises you may realize. >>> >>> Hope, this will help to progress you tasks >>> Stan >>> >>> Mario Marietto wrote: >>> >>> >>> Hello. >>> >>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. >>> Basically there are two ways to accomplish this task : >>> >>> 1) to write a patch that allows the FreeBSD kernel to boot as a zImage >>> file. This could be accomplished applying this patch to a specific file >>> that's on the source code of FreeBSD : >>> >>> >>> >>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139147271703= 5f986c979edef0c9 >>> >>> >>> >>> This patch was written by Julien Grall a lot of time ago and now it doe= s >>> not work anymore. This is the reason : >>> >>> >>> 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. >>> And I'm not able to fix it. >>> >>> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : >>> >>> >>> I was trying to explain why and how Julien's patch works so that you >>> could be the one to re-do something similar or fix the patch on the Fre= eBSD >>> kernel that you are working with. I am happy to help review and write >>> patches but I don't work with the FreeBSD kernel so I wouldn't be able = to >>> help you quickly. However, I might have a suggestion. Do you know if >>> FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as Xe= n on >>> ARM guest firmware/bootloader. You should be able to build U-Boot and u= se >>> the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD f= rom >>> disk or network and start it. For instance as domU config file: >>> >>> kernel=3D"/home/petalinux/u-boot.bin" >>> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>> >>> I know it is important to build u-boot with the following config to mak= e >>> it work on Xen. >>> >>> CONFIG_CMO_BY_VA_ONLY=3Dy >>> >>> >>> >>> This option seems more doable to me according to my knowledge. But I >>> need to understand how to do it. >>> >>> Well,let's say that on the ARM Chromebook I'm forced to use and install >>> a customized version of u-boot,created by virtual open systems,because = it >>> is the only one that allows bypassing its bootloader protection. You ca= n >>> find more information here : >>> >>> >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= /?vos=3Dtech >>> >>> This is the relevant section to read : >>> >>> >>> Bootloader : >>> >>> If you wish to skip this chapter you can download a pre-compiled binary >>> of the bootloader: >>> >>> >>> $ wget >>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv= _u-boot-snow.kpart >>> >>> >>> To be able to run KVM on ARM platforms, the kernel has to be booted in >>> hypervisor mode. Because of this relatively recent requirement (due to = the >>> introduction of the virtualization extensions), up until now all bootin= g >>> methods would boot the kernel in the standard Supervisor mode. For the = ARM >>> Chromebook the default boot procedure doesn't allow us to boot in >>> hypervisor mode. Although the laptop's boot mechanism is based on the >>> frequently used u-boot, the binary is located in RO memory. Fortunately= , a >>> chained u-boot mechanism can be used (i.e. starting another u-boot afte= r >>> the original). We can then enter hypervisor mode from our custom iterat= ion >>> of u-boot and subsequently load our kernel and userspace. >>> >>> Checkout the needed u-boot code : >>> >>> >>> $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ >>> ./scripts/build.sh >>> >>> >>> If successful, a message about how to copy the bootloader on the USB >>> flash disk or SD card will appear. We will use it later when preparing = the >>> boot medium to start our system. If you have followed the Setting up th= e >>> boot medium chapter and you have a prepared boot device, then you can >>> update u-boot by running : >>> >>> >>> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>> >>> >>> >>> so,the needed u-boot that we must use should be installed on the first >>> partition of the sd card. >>> >>> There is another relevant section to read : >>> >>> >>> Setting up the boot medium >>> >>> Now it is time to copy all the relevant files that we created in the >>> previous chapters,and use them to boot Chromebook with a different kern= el >>> and OS. In all these examples the device /dev/sdX is used. Take extra c= are >>> to change the examples to the device that you have attached. Insert the >>> boot medium on your workstation and carefully execute the following ste= p. >>> First we need to properly format the boot medium. >>> >>> In the uboot source directory : >>> >>> >>> $ sudo ./scripts/sdcard.sh /dev/sdX >>> >>> >>> This will erase all data and create 4 partitions in the medium, along >>> with copying the u-boot binary to the first partition: >>> >>> >>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> Partition 2 =3D not used >>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> Partition 4 =3D EXT4 partition for userspace files >>> >>> >>> With u-boot being copied, next is the kernel image and DTB file. From >>> the kernel source execute : >>> >>> >>> $ mkdir ../mnt/ >>> $ sudo mount /dev/sdX3 ../mnt/ >>> $ sudo cp arch/arm/boot/uImage ../mnt/ >>> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>> $ sudo umount /dev/sdX3 >>> >>> >>> Finally, we have to copy the Ubuntu userspace filesystem that we create= d >>> earlier: >>> >>> >>> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount >>> /dev/sdX4 >>> >>> >>> >>> Now,my idea is to chainload the already chain loaded u-boot created by >>> V.O.S to the new u-boot that we need for booting FreeBSD and that can b= e >>> installed in the partition n.2,as shown in this scheme,because it is no= t >>> used : >>> >>> >>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>> bit,compatible with FreeBSD on this partition) >>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> Partition 4 =3D EXT4 partition for userspace files >>> >>> >>> Take in consideration that default boot string is hardcoded here,in the >>> snow.h file of the custom u-boot created by VOS : >>> >>> >>> >>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs= /snow.h#L101 >>> >>> >>> >>> and it needs to be recompiled because it should point to the partition >>> n.2,where I will install the u-boot files as explained here : >>> >>> >>> https://wiki.freebsd.org/arm/Chromebook >>> >>> >>> I have some questions to ask before I start working on this. >>> >>> 1) The xen developer said : >>> >>> >>> You should be able to build U-Boot and use the U-Boot binary as Xen >>> guest kernel... >>> >>> >>> >>> where is the u-boot binary,according to this document ? >>> >>> https://wiki.freebsd.org/arm/Chromebook >>> >>> I don't see it. >>> >>> >>> 2) where is the source code of the file that I can get here : >>> >>> >>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/= nv_uboot-snow-simplefb.kpart.bz2 >>> >>> I need the source code if I want to recompile u-boot so that it can >>> point to the partition 4. >>> >>> Maybe it can be found on this link : >>> >>> http://linux-exynos.org/dist/chromebook/nv_uboot/ >>> >>> but it can't be opened.... >>> >>> >>> 3) in this specific scenario the source code of u-boot should run on ar= m >>> 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" model >>> XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A= 15) >>> Soc. >>> >>> >>> 4) I'm not sure if I can chainload the customized u-boot created by >>> V.O.S that should be installed on the first partition with the u-boot >>> tailored for booting FreeBSD that should be installed on the partition = 2.... >>> >>> >>> 5) the xen developer said that u-boot should be compiled enabling this >>> option : >>> >>> >>> Code: >>> >>> CONFIG_CMO_BY_VA_ONLY=3Dy >>> >>> >>> >>> Well,can you provide some good source that can help me to understand ho= w >>> I can recompile u-boot for FreeBSD ? thanks. >>> >>> -- >>> Mario. >>> >>> >> >> -- >> Mario. >> >> > > -- > Mario. > --=20 Mario. --000000000000241867060cc737b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So,ok,I should have said "the second u-boot" ; s= ince the first u-boot binary is the "u-boot binary located in the RO m= emory" of the Chromebook". Sorry for the confusion.

=
On Mon, De= c 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
---> There = are no specific options in u-boot devoted to=20 FreeBSD

This is an important factor. So,what = about if,instead of compiling a new version of u-boot on the partition 2,I = will recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first partition ? It could wor= k if there are no differences between the u-boot that should boot Linux and= the u-boot that should boot FreeBSD.

Can you give= a look at the u-boot source code created by virtual open systems ? You can= find it on my google drive :


I need to un= derstand if I can recompile it without problem so that it can satisfy my ne= eds (the ability of the file u-boot.bin to boot FreeBSD as domU under Xen,a= s explained by Stefano Stabellini,the xen developer that suggested to me wh= at I could do to have FreeBSD virtualized under Xen on my Arm Chromebook) ;= otherwise the risk is to find later problems that will make me troubles an= d that I will not able to fix.

I gave a look = at the virtual open system u-boot and I didn't see any arndale_de= fconfig inside. So,If I have understood correctly,I should put that file in= side the root of the u-boot source code,let's say here :

marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # l= s
= =C2=A0
.checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0README =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0net
.git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
.gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exa= mples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0rules.mk=
CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0spl
Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0too= ls

and I should do : make and make install ? and the file I need,u-boot.bi= n will be generated ?=C2=A0

I didn't find any pre made configuration f= ile inside :

u-boot-vos # find . -type f -name "exynos*"=C2=A0

./include/exynos-fb.h
./include/configs/exynos5-common.h
./doc/device-tree-bindings/spi/exynos-spi.txt
./doc/device-tree-bindings/usb/exynos-usb.txt
./drivers/power/exynos-tmu.c
./drivers/power/exynos-cpufreq.c
./drivers/video/exynos-fb.c
./drivers/spi/exynos_spi.c
./board/samsung/dts/exynos5250-spring.dts
./board/samsung/dts/exynos5250-smdk5250.dts
./board/samsung/dts/exynos5250-snow.dts
./board/samsung/dts/exynos5250-daisy.dts
./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
./arch/arm/dts/exynos5250.dtsi
./arch/arm/dts/exynos-periph-id.dtsi
./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0

u-boot-vos # find . -type f -name "a= rndale*"

For sure I can't use a newer version of u-boot because otherwise the= patches needed to bypass the bootloader protections of the Arm Chromebook = (such as a lot of different patches needed to boot correctly Linux) will be= broken ; anyway,since it works,I don't need to use an updated version = of u-boot.

----> As per my experience, you ha= ve to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

<= font size=3D"4">
<= div>It says that I should use these parameters :

C= ONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

These are the parameters used to configure a Linux kernel. I don'= ;t understand what's the relation between the compilation of a linux ke= rnel and u-boot. In the past I tried to recompile u-boot,but I didn't h= ave the need to set up those parameters,so I don't know how to do it (b= ut I know how to recompile a Linux kernel).


---> I'm not sure that I'm= getting you right, as I don't understand what you mean under "the= first u-boot".


I'm talking about first u-boot= because the whole procedure to boot Linux on the ARM Chromebook,that's= explained here :

http://www.virtualo= pensystems.com/en/solutions/guides/kvm-on-chromebook/


= at some point they say :


To be able to run KVM on ARM plat= forms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.

For the ARM Chromebook the default boot procedure doesn't allow us t= o boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

So,the first u-boot is the u-boot provided by virtual= open systems,that's able to chainload the "u-boot binary located = in RO memory" , that does not boot Chrome OS in hypervisor mode. We do= n't need it if we want to boot Linux with kvm or xen enabled.

=

On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
I'm not a= n expert in the topic, I only know, that ARM has divided hardware into two = worlds - Secure and Not-So, strictly limiting any software, running in non-= secure world with access to functions and resources.=C2=A0https://developer.arm.com/documentat= ion/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den
<= div dir=3D"auto" id=3D"m_-2747878036369583702m_-5077711917547611557m_-96266= 3937491960362tmjah_g_1299">
I'm no= t sure, that I'm getting you right, as I don't understand what you = mean under "the first u-boot".
<= br>
As I understand, virtualization (HYP) = is running in non-secure world (https://developer.arm= .com/documentation/ddi0406/c/System-Level-Architecture/The-System-Level-Pro= grammers--Model/The-Virtualization-Extensions), so my guess (only guess= !!!), virtualization software has to prepare (configure) HW platform in the= way, that FreeBSD kernel will not lack any resources, required to configur= e MPU, VA, etc.
So, if you lucky to boot v= irtualizer, which is aware of target OS, that maybe you can boot the kernel= . Although, I doubt, that you need to boot 'second' u-boot to boot = the kernel - there is simply ubldr, which you can hook somehow from virtual= izer....

Stan



Mario Marietto wrote:

= ---> As=20 I understand, it makes sure that u-boot keeps in secure mode during boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.

Can you elaborate your sentence more ? I know that the= bootloader secure mode is bypassed by the virtual open systems u-boot. Are= you saying that when the control passes to the second u-boot,it will happe= n in secure mode,so that the bypass that happened loading the first u-boot,= is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-op= en-system custom u-boot ? Is this compatible with FreeBSD ? Where can I fin= d the u-boot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM S= tanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot=C2=A0 beas= t is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that=20 option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to=20 your target armv7 32 bit=20 platform:=C2=A0https:/= /source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_= type=3Dheads#L3
<= br>
As=20 for compiling the u-boot, it is a doable task, given that you understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then pass= =20 it control.

Basically, you can grab = some defconfig,=20 prepared for any other Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads)=20 and adopt it somehow.

As per my exper= ience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during boot= =20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.

Hope, this=20 will help to progress you tasks
Stan

<= /div>
Mario=20 Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.= =20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And= =20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= =20 work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need= =20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of= =20 the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ c= d=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with= =20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the= =20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/dist= files/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point= =20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_= uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW&quo= t; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I= =20 can recompile u-boot for FreeBSD ?=20 thanks.



<= /td>
--
Mario= .
=20 =20 =20
=20 =20


--
Mario.
=20 =20 =20


--
Mario.


--
Mario.
--000000000000241867060cc737b6-- From nobody Mon Dec 18 12:14:22 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4StzKB2Lq6z54PwK for ; Mon, 18 Dec 2023 12:14:38 +0000 (UTC) (envelope-from pintochristophe69@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4StzK90JjRz3NZw for ; Mon, 18 Dec 2023 12:14:37 +0000 (UTC) (envelope-from pintochristophe69@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="SCEfu/DK"; spf=pass (mx1.freebsd.org: domain of pintochristophe69@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=pintochristophe69@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5532b348d30so1163325a12.1 for ; Mon, 18 Dec 2023 04:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702901673; x=1703506473; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=A6kUSjYxj8t7Byj6JZM3Pw4e/xiXpTjJRUGgak5a6bk=; b=SCEfu/DK7peSOYRq18jhHulZZyc1ts7xXkdwo5ZJf+r1ypm47SGaqiBoFRm4Gu2Qxs kaNV9leuYeY1nWdxoub7Qd/TxFUEdLJuPSMTTQaoc1+wl5QNDLXQ+DhORXx65BN5jBne NBsJxHqGmRqC7iw2+eys+9qJy8NuOrhKwJKBFj3QSxd/h0suz5LAZyd5E3m8usWpgFXL s5KJfyHxnqL91nxyaPyATg+1rc8gJ8MUxWPXmxnnJq7NpMbX+s5sO3n2gl5Ega3Mxg84 xBiAIXN3DkknHU3O1Arkf19H5yO6W3wLD9inZvF0nW/sNW62oTXb54D1peB+2wqEZ4vr kNaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702901673; x=1703506473; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A6kUSjYxj8t7Byj6JZM3Pw4e/xiXpTjJRUGgak5a6bk=; b=fetYTh17crHp0wDGZTU5JHNNrp+ARNHoXEgkMGxItW1ZurbOZ+cWgqKrrPWB7kMglA yAmYQg66Ioi4DXHyYSWnQDFDr4rxxOnxsVc4uH/+Co9BLsGRVlxwYbmvYBygbTaj/rYT eFyjIzP684UzXVTME0iSnFRXs6jlyFAzbIKZ7TaohY6kRPnbgkk6LBmyqpKU3ckoNPP3 zJquGZ65d+4jgCqr7EUAkFtJBVRUJWBjoZznGF41jqSf6as4JN+cAHSLawudtJrNKtch edCxOg0eG6fSu+XXCTXHuHnYg8uj9js0WrU2ALcGvhbiQv26hawYyrEJUdtzSFcbE8sA P55Q== X-Gm-Message-State: AOJu0Yx8iHiDouW5vriqKUneQQxEpIppDSXmgP7syVsncCwtwVZ4wACg puxBWi3m3bzWv4RY+32Qd7Jj9R8jcp78qng6UKtjJhafJGI= X-Google-Smtp-Source: AGHT+IGC54cggZz1fXH539xbDKrKfdFrXRGTmQy/0DY5Yl8af6XT+dMOvI5VoKpNHJsaf1ISGZ8vZTAkmgoZ4cryobw= X-Received: by 2002:a50:c04e:0:b0:553:2ce6:1455 with SMTP id u14-20020a50c04e000000b005532ce61455mr1238937edd.25.1702901672962; Mon, 18 Dec 2023 04:14:32 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Christophe Pinto Date: Mon, 18 Dec 2023 13:14:22 +0100 Message-ID: Subject: Rapsberry 4/5 & HiFiBerry products To: Freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004def54060cc7b14e" X-Spamd-Result: default: False [-3.84 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.84)[-0.837]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[Freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4StzK90JjRz3NZw X-Spamd-Bar: --- --0000000000004def54060cc7b14e Content-Type: text/plain; charset="UTF-8" Hello team, it will be possible to use HiFiBerry sound cards under FreeBSD like : HiFiBerry Amp4 | HiFiBerry or HiFiBerry Amp100 | HiFiBerry Regards, Christophe --0000000000004def54060cc7b14e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello t= eam,

it will be possible to use HiFiBerry sound cards un= der FreeBSD like :

=
or


Regards,

Christophe
--0000000000004def54060cc7b14e-- From nobody Mon Dec 18 12:59:04 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sv0Jg02LVz54T5m for ; Mon, 18 Dec 2023 12:59:15 +0000 (UTC) (envelope-from SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv0Jc6HLsz3DMn for ; Mon, 18 Dec 2023 12:59:12 +0000 (UTC) (envelope-from SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=SVvKUmYz; spf=pass (mx1.freebsd.org: domain of "SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl" designates 87.255.56.188 as permitted sender) smtp.mailfrom="SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Received: from rwvirtual46.colo.realworks.nl (rwvirtual46.colo.realworks.nl [10.0.10.46]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4Sv0JS605Pzft; Mon, 18 Dec 2023 13:59:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1702904344; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=d0/oB3qTn9CVzPmEFUB8XE301uuoKmoKZ4QvLdJ75K0=; b=SVvKUmYz3cCN2SMkJM3/yoeEyX9bZMZOVzTL/aXCj0eSS3TwpWwVM/Mp2grFNZMKViBZRJ whzxf9YUOJXkrZR3xpF49NvRjZc7R7v8KOmtkLhcIcEmC6z8iLxIovS1JRxL/n+hBIIALW O523BKG8/fyLUK2vSeSYZWe92He09KMajTbGInZL5qadne05GdSwUbMaY8qqcsDEtMnAuv a61iA/7KH2iP7XFzHMdrzG4YbWtebFAULDcsRkGSiUzBvfGR7PKNdCdh1FO1O36AYApyqv hZua7M58jusQsaI6RD99i/E0F7TIlZ+P32KfU1Rh61ugoa2R9sURb6HQ4U7uVQ== Received: from rwvirtual46.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual46.colo.realworks.nl (Postfix) with ESMTP id 9098B2404BD; Mon, 18 Dec 2023 13:59:04 +0100 (CET) Date: Mon, 18 Dec 2023 13:59:04 +0100 (CET) From: Ronald Klop To: Mats Mellstrand Cc: freebsd-arm@freebsd.org Message-ID: <2040550451.4915.1702904344395@localhost> In-Reply-To: <0856BB69-6BDB-4570-B010-F22BF262DE84@exmandato.se> References: <0856BB69-6BDB-4570-B010-F22BF262DE84@exmandato.se> Subject: Re: FreeBSD on raspberry PI 5 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4914_182496000.1702904344387" X-Mailer: Realworks (683.45) X-Originating-Host: from (89-20-164-210.static.ef-service.nl [89.20.164.210]) by rwvirtual46 [10.0.10.46] with HTTP; Mon, 18 Dec 2023 13:59:04 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0 X-Spamd-Result: default: False [-3.17 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=ddL8=H5=klop.ws=ronald-lists@realworks.nl] X-Rspamd-Queue-Id: 4Sv0Jc6HLsz3DMn X-Spamd-Bar: --- ------=_Part_4914_182496000.1702904344387 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, You never got an answer. I have never seen any report that anybody was using FreeBSD on a RPi5. Or that anybody is working on it. So for now it is experimental status. :-) I'm curious too. Regards, Ronald. Van: Mats Mellstrand Datum: dinsdag, 12 december 2023 17:22 Aan: freebsd-arm@freebsd.org Onderwerp: FreeBSD on raspberry PI 5 > > Hi, > > > Has anyone had success installing ad run FreeBSD on Raspberry Pi 5 > > If so, how did you do? > > > /mm > > > > > > ------=_Part_4914_182496000.1702904344387 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

You never got an answer.

I have never seen any report that anybody was using FreeBSD on a RPi5. Or that anybody is working on it.

So for now it is experimental status. :-) I'm curious too.

Regards,
Ronald.

 

Van: Mats Mellstrand <mats@exmandato.se>
Datum: dinsdag, 12 december 2023 17:22
Aan: freebsd-arm@freebsd.org
Onderwerp: FreeBSD on raspberry PI 5

Hi,


Has anyone had success installing ad run FreeBSD on Raspberry Pi 5

If so, how did you do?


/mm


 

  ------=_Part_4914_182496000.1702904344387-- From nobody Mon Dec 18 16:29:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sv4yz4d4rz54jf3 for ; Mon, 18 Dec 2023 16:29:15 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv4yz1PXWz3GgR for ; Mon, 18 Dec 2023 16:29:15 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 827FF5F315; Mon, 18 Dec 2023 16:29:06 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 814DA5EEAD; Mon, 18 Dec 2023 16:29:05 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210663; Mon, 18 Dec 2023 17:29:01 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 18 Dec 2023 17:29:01 +0100 From: Alex Samorukov To: Ronald Klop Cc: Mats Mellstrand , freebsd-arm@freebsd.org Subject: Re: FreeBSD on raspberry PI 5 In-Reply-To: <2040550451.4915.1702904344395@localhost> References: <0856BB69-6BDB-4570-B010-F22BF262DE84@exmandato.se> <2040550451.4915.1702904344395@localhost> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sv4yz1PXWz3GgR On 2023/12/18 13:59, Ronald Klop wrote: > Hi, > > You never got an answer. > > I have never seen any report that anybody was using FreeBSD on a RPi5. > Or that anybody is working on it. > > So for now it is experimental status. :-) I'm curious too. I do not think it is experimental. To make it work someone needs to write support for the BCM2712 and other peripherals found on that boar, adopt loader, etc. Not sure if work is started, but until its done status is "not supported yet" From nobody Mon Dec 18 18:22:11 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sv7TY1PJSz54qqj for ; Mon, 18 Dec 2023 18:22:25 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv7TX1T6jz4VDH for ; Mon, 18 Dec 2023 18:22:24 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de; dmarc=none Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BIIMB3h043505; Mon, 18 Dec 2023 19:22:11 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from [10.100.100.54] (unknown [217.110.88.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 9C8633A3; Mon, 18 Dec 2023 19:22:11 +0100 (CET) Content-Type: multipart/mixed; boundary="------------TvP1M6MvH4iAzV3lpnZgweRW" Message-ID: <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> Date: Mon, 18 Dec 2023 19:22:11 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] Content-Language: en-US To: Emmanuel Vadot Cc: freebsd-arm References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> From: Harry In-Reply-To: <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> X-Spamd-Result: default: False [-1.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.46)[0.460]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; MIME_UNKNOWN(0.10)[application/x-xz]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[omnilan.de]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4Sv7TX1T6jz4VDH X-Spamd-Bar: - This is a multi-part message in MIME format. --------------TvP1M6MvH4iAzV3lpnZgweRW Content-Type: multipart/alternative; boundary="------------JKZlkyNkW8aM4MFkAQpj4iBa" --------------JKZlkyNkW8aM4MFkAQpj4iBa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/15/23 16:56, Emmanuel Vadot wrote: > U-Boot also doesn't support the DRAM controller so we also need an > external blob from rkbin. > That's the main reason I haven't done ports for u-boot on rk356x so > one have to compile u-boot themselve. > It can be simply done like any other u-boot targets and only needs two > env variable : > export BL31=/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf > export > ROCKCHIP_TPL=/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I came up with so far :-) I'm trying to understand what happens with the help of this: http://opensource.rock-chips.com/wiki_Boot_option The attached diff (updates sysutils/linux-rkbin (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and adds sysutils/u-boot-nanopi-r5c) allows me to build u-boot, supposedly supporting R5C(rk3568). After putting these onto SD-card with dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/idbloader.img of=/dev/da1 seek=8 bs=4k conv=sync dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-boot.itb of=/dev/da1 seek=2048 bs=4k conv=sync my nanopi-R5C boots from eMMC instead of SD. I downloaded a NANOPI-R5C_EFI.itb elsewhere. I can get the TianoCore port booting... But I'm missing the part, where ubldr, the FreeBSD post-u-boot-loader, is supposed to take over - and how... I simply created a freebsd-ufs partition and put /boot along with a loader.conf onto it, which works using the foreign TianoCore port, but not my newly created u-boot. What am I missung after dd'ing? Any hints appreciated! -harry P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff attached, the I used the commented nanopi-r5c-rk3568_defconfig! evb-rk3568_defconfig is a leftover... --------------JKZlkyNkW8aM4MFkAQpj4iBa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12/15/23 16:56, Emmanuel Vadot wrote:
 U-Boot also doesn't support the DRAM controller so we also need an
external blob from rkbin.
 That's the main reason I haven't done ports for u-boot on rk356x so
one have to compile u-boot themselve.
 It can be simply done like any other u-boot targets and only needs two
env variable :
export BL31=/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf
export
ROCKCHIP_TPL=/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin

Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I came up with so far :-)

I'm trying to understand what happens with the help of this:
http://opensource.rock-chips.com/wiki_Boot_option

The attached diff (updates sysutils/linux-rkbin (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and adds sysutils/u-boot-nanopi-r5c)
allows me to build u-boot, supposedly supporting R5C(rk3568).

After putting these onto SD-card with
dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/idbloader.img of=/dev/da1 seek=8 bs=4k conv=sync
dd if=/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-boot.itb of=/dev/da1 seek=2048 bs=4k conv=sync

my nanopi-R5C boots from eMMC instead of SD.

I downloaded a NANOPI-R5C_EFI.itb elsewhere.
I can get the TianoCore port booting...

But I'm missing the part, where ubldr, the FreeBSD post-u-boot-loader, is supposed to take over - and how...

I simply created a freebsd-ufs partition and put /boot along with a loader.conf onto it, which works using the foreign TianoCore port, but not my newly created u-boot.


What am I missung after dd'ing?
Any hints appreciated!


-harry


P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff attached, the I used the commented nanopi-r5c-rk3568_defconfig! evb-rk3568_defconfig is a leftover...

--------------JKZlkyNkW8aM4MFkAQpj4iBa-- --------------TvP1M6MvH4iAzV3lpnZgweRW Content-Type: application/x-xz; name="FE-r5c_ports.diff.xz" Content-Disposition: attachment; filename="FE-r5c_ports.diff.xz" Content-Transfer-Encoding: base64 /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4EeyDFpdADIaSQnC/BF9UN4KT0fZJahqQqcSkAAK ykWH2iKWWJhQGmZCf/gGicyL9PuIdgJgGwJXMmI7KWja99OuG9jFyw/36yrocRMIIuamu8PN 0fycSaNEoRsqbw59xDHL0FWdGcmADX8qmGnxFwen6QxCgGeyVoBotgkhIT2PVJ4lPuaj3A3g dXSERbyJ8TITGNJ+CkSOO5m/A5qWj5tdPEUUOF0+Chcqlwcy7T+O0cIgNQSfzXgJaiAeav8H KfZqJz7wRg5qCrWBdeeHdTOd8HBSC/HP4i2h7M7qlGGfutiPzbiwatv4SksmG09KKEBuCVTQ xM57AZ2pghfm+yXu6+i1uYFdW6YxCS9rzyHuHqz4cUkKIi+4CtHe0Z2l+qZbAM3dchrW3oqo axoFvzXywLB5nL9J7ujY07FGm+NxSFu/mRoJfEQg9weMpnrWqQnEVmNlfwexmpKaUVDdoP01 atFHrr2S7pph1JtP3/k6YqGqaRqnmNsTrOQH994vrdhdefZ0JJ3nrS+KWS+g5opiiUOHNTwT JP+TSthSK5L2X3EmS/FeEuWfnxvYktiSLhcWtrSjfN4ln2AYsJ3Qn71/h5vtFba1k6+7jcjr ae4aBmgqsQ2ct/X9SIbe6tLBDSIwh1ZxWVj1n42/xZVzO/+ugP4RSqqJBbF7SGqjy8Po65g0 PAPYHaLjvRjqec0VgpG2H5YNHjHhCu6daSmLLARaHVyhrgT7tm89oiXU2dOxVGyDJAJCFpkR 7Q0BfyiStQfEwT/JYOYXTFe5ygYLSfVrJT8NJIpuldMwdwm94hSMlkE4DyYwd8r0sxewbXVG WLLZhpd1cEtM39nKr6MLybNkn4h/PLz1kPEwyabrVvS0vZ12kPA9i/SlRf0viSp+k+QV/Ibf JWGmb6Lo3c+i4cBRk/xTKy+arxijIqPMacPNz/wDnzyMmDt7BpQUiE5nlvx2KwLwSj8SsZ5y F0tOzPiAppBNaYxlVCt6yFXhLW687t5c5AYG4c496bxVAc+El83IW2ftgEuIcIWw0Jb/qDvY HQy4epeG29OtMBvm4YJMKzurKaYO8jaE2ps4gwBUL01nJzVA7rmyHJ4LllS5XrYfpUU8a35d V0J6XGfX9HqqpQHW8bHi/2nxo6gwNcWbCSLXisD0YhA4fZhNi9ksqg7/028/dGh/GsYU5Rhc AN5EDp+lTmTxLS90LGRx1APF6n/cJ+Aua09d1nIamyoa/QedNpq1jVcVeGkqYioCY4//zxhW 8kIKLet8SxvCVTyFrpSIuqU1m3QRDxMXMlZEvi78gAXPGzCaatRNoYu01qee0GpfHa1sf3y6 jrezyXOa13VUth8ZNAvnKHZj9eaAR6NxLbRV6OYofwp7wtvVDZXv30ZYNOqf7FQEouw52+Sp VhFow6zYjSeajUqpjXJ02ZFgMQsCOoVSZ0mjgCMerVVViE+7+vUIsXPKZQFOw3j1dgTFSXHO RvQaUHYlYVP/hoM4dGEjdW5Pr6lw6PQsuYbRD9ry8J60bHAqPNbpminArDpxwQXGs9Nt/R7V Xea01T7XXAER7EKXF3t/zCkCMv0fAMHE51yQBVG6X/mcwc0Agb05jOFyJ2HjAwMJeeITJ37G erTt7BctCVkJrzvQ6XRcH/FmDxwgIxFIXMuqJqRtSPOmf9WVRqhMgEnpgYEYypbJXlmg6N8u 9P5UtiBZ7tomR4cDeBZzModLBAeiYMyr4007Axzj49LzsaL3Y2E/uB1IVbsuPf3GfjSMHNAj 3+mmm4GipCWU+OqC51iiPkxWzC303f34Sjz18I8zxNJnbT8WwOSuKyVywl6tVbPJcLOeN1s8 CW2X3bI82qZf2+TbhVZ/qry0+CdJHDSTFii4xW92W7dYYgmrdCW3ULyn0WK0ppGHQT6unoVU AzKGmIgUnqw6gSHMxAnm2jjzixzwYk2zHYWFNbynyqfPypVqgZI5yHA0n0Ayr6qWlFZUqNYS I8XesTSmY9XsL8oPlRHhOhCoV+emsXBh/Oufchriy2mz7qtsmffl0n9muHOuB5cDN9cbR8/j EnnGT3e1CkH596efRdND3an/vIkCAz1HgLtj414jDsDRiBwBsrzwvSM812XmNT1JazsXojnV DCKYvPY8M/YNM5yDzSY7L+HDODWH4XKCGC+2BGzPx5m2wnDli80g6uz21HOkesWbWYLeVf34 h3gDPLEUMZCNBnDifnuskPj688kx0eYRAyFjLaqzK0Tm1FYoSraj24J/Kp5f2SNHRJq3jx9j pIcf21a3LCD5xhJZavplsdq+Th0uaAqmsdQyVCVx6GNIySzq44mIrlUDluUf7yvXDgw6h3IU 50KThMlT09XqDAaeZlcaCY+CTPdr0nPhrqGpoEReG9Jdh7glsx37sLw4P7G466yXQ6YWhaWV S8x4IQUXzKt8SXoAteN/qe8+VRwXfah56mXsFxztWxXUSQPTILLuZtGflDS6TIqmHzIAz3Oc NvZPeujvjtKaaalGJxFeSylKjGduZ6VDM/AORAH1KqOR5YR8oaWBPTo0rQ5JQdJWx0Cujqbk TMprwCFAchsj6ehTWQPGIT5/7WaHAdyai3HgIVEACpnM5RI6qfmCopCkR7nSaNAQwG2Zs/R5 FbGNDATPpefn97po+J6vv9GDBWXW6tODqDlV6El3jTxmo9Ipwu6ykoTSYJWk9E0zSE8z7xr2 zZdEzm54tv5zwhstbHKXRFc0BMvoF4lRP20GecDe3pF60mdGhMFWftpQ5alvcuPlfa5lICDa Y3DKJBIvtypSomh0xW/g7DVE0D7lWvX+hB6zruD9P4bBs0SSrZUWF0BbZdwH3bG1ErrQ0k/L QMyBe6oCTijf74/in39P3UOpQjBzFxDxQHKBuIxb2CTRG7+6gMb9iM9rFj4fGgwxe/EY1S0q iiBWP7SLZfZZKRlLPlHeb5Lg759crfni/k/Pwamd6k/2Sn1f+o9+UXXzpUtTKuEf3+OKxJgL hscSrXrmZkq68uw4PsmpzlJ3QLh8grhSiB0bQXH2gJqRBxESzBC82SO1gwzSu5RVWp8WW6X8 qufFhMWgj3jrVswkFg2/z7+ciswBgpZ3mh4WVPkd4jVqlAqHFCoaNqQEFlFpbxWUnelskt24 exC6/F4k76kyR/vY2RIbV8hw17fIcIJ/4mvhDSy9M+CeABCNw+yVyZLHz7UJbYn0uhqwXkSC dNOh3HVPqw4u3cXZo2L9v93QG4BTR0eZuBbXBVDxFagXXWZGLczb086kWxggE4L1HfAVrsuU bFhI6jn5GtkEuws6eluQ3dawIZH6UIdtjQwDwccjkBLAVwdydfz4FQRHaRuf/1UHY3ptzMPJ icEMg9IlSLtv0vH/ISxgV3YTZ0889iwDNvKlhkvMmVk21bkAuJ+jEUCBy/1WR/Z8ZZLgidQi ovFlStQpqsdisa9vSfrLF7pIp7RuOJDs/tgUUz8Er67ncBkuI4XK9uITGqIO20gOLtLhXTmX D3mF+cjmxc04YuxJ2lLKqTXL3Ky/K4k2i3ful/2daI7j8NjuTHYyQgMCk+3Juu9Td/8abrRv FQF4Be8nybDqp8fnGTYYmSuLa6tsR2wyg0DwXSdef99LHPnJQ/KhAyGAav+jYhfNi/cAQpII tubLWkBHjp5+IdWgzbfbQAFp8M/Ika5dsJjVUl2P3Qmx6AjOVZ1V6/8qqgBZr5UutbzM9oyj 98uk/Xx3oFV1RWCsS3YtTr1f7q+G9w+ZhblsdzkSf5HhsEtzduTlv0/tA+637tzuQyGhR3BH S/ZQpzc7XEdkLO8g4OUlQ230Leagbu2VvIumJYL7rxD3nwhBni3hjgczGaegmzhWgjijD4lp glr0e89ixW+YWg4KVe9rzBUB38kgjX4qQzj6Ub8V5PUkasC9+h++x5EWcwPCOpOLwiYMeH3g kHcXVMwrU8+R6RUdjO3NMspUbQN0z6acPhjJM75qudVo+x/kAR7oifpXfV3AGkLo33SYqKiL ybDn6pufgh4jc5dNvHH0SPSGqmCAR8wB74zL+IHxuoOzfQusqZK48gyTZKgaDc0kJY9sR3vc BzJh3a3pP2cV6BJ5bviBcWXE3Ilp6W3G66zCJGkNbgBrra7i5NSrBQIT1UZL6QOpWKVZOufx gk1NubqqlyMclAPuuYqfy4aMPeZ4KCwKN75pZrglgKwVEDSvFw1hGdY+G69cNzyUxyFSvt2A GbsBEdQAAAAAAIhMrAJxK6A/AAH2GLOPAQASfrusscRn+wIAAAAABFla --------------TvP1M6MvH4iAzV3lpnZgweRW-- From nobody Mon Dec 18 18:44:20 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sv7z93ylbz53d3L for ; Mon, 18 Dec 2023 18:44:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv7z84Crbz3DNG for ; Mon, 18 Dec 2023 18:44:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702925073; bh=QDJYxByl4hOQD1vssDHl3sNc/3aWashhb52Men1Z+w0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KlEO5luGLb4gAiLTawWl6kPxu5NhwUKOqkSUcvVqI9Cu5lWn5tw214wB7WsQerNN6CDTdYBsg/bkFHx0jhiUhdDCMxG5vnb2cdD95XzR5CrWTBS5NuorOMQd0p4wG8HG054lbKL0b7CWjdtiIy3h6xHrfaxQeXKljFJ/9UUWlXNty6ci23j05ztGIbW2hvywzWmbL5g3nE4LZ2Aac4zmwjU86/FY2p735lBXVUmaQEy8/ZkvYL8PcWkmGCIZ+VUlwepCjTYVkKmgFNOCuCSxKX5hmGtTZ1Q0ng4RQKM6z4eE1KPReatyOijoO97o/Wy6PIBKBL62bXRyyj+WQYhKrg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702925073; bh=Sg2Qd2v5Y/u05xtvQtuQCrZiq7WMmJ1c0VxncTCCYJ1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hR4+NpDW0Wqav4cX/qYwgOSgsczGZrW/1cCesND76CFYiGQoZknGIjK1MqyZkpLjRJHbUbVpRyA9gnzkxxAkM4SBgbve+C3gGQiKSHar4MFpZuVf5fUvNYlGTKNpw45BhwmuelGyYCMOwQSXB7ieFJZveZ1ojQ/xexxTlhdXEHfZR/Vq7zTjEwlGFwo+awDb7Y6ii8qeZ1ag5d5ORj0D2n9jeRGcJEnQZ6FqJfkbOh23UspORVCZWvQs6TRLqLwEYhEtYB3uzQxd3Nt03Jxzyi0tnyDjpJQ9O2P8Uf6PZ309RjDTyWqUhJLaldQ+TIJpXEXi/9UVVWn9oR+xB3Ytlw== X-YMail-OSG: 6.e53ZsVM1n1zaahbx5_bjvUUHn7QpbIxOxZJd_aBas3W3t.nis9ztt2eTzdhe0 8KMbDmkF10k9PKnPcrjtcudrGhxOT9DsL6CeYY.7qOwzS0jWVQo6lP3.vzbNQYK30IVTJzOthPP5 C76CKoIV.0QGKFfxpb.kPIpGUipCWI_tjs0F3lcPICAlYskIzEfeMl0kVhCVZWMKvgc2UodyiNkN 8gw47hcCbE3o0yc8WiicZG4nzEoHE52wHoB5bnXVJAkEVZqgwH9FoSB50CbFYw9VfbeE_AyiQtzd A_y2MzuvpcvmAZIPr3r200tHk1tiNkCNzkYCN_oABfuEoPR3fKS6T8SR0ETIO1hhKsofMqmC6uTW 8SEPAqjE5xNeYG_EA.DWAlhROB9HjUqIztWVr6IfUSP0S8G_Eezs2qloTVpsqOtQBryTXn6s3zMQ XVi6Q.S_VAfMf9HNwrHPWDQlt4vYaIbcODtnPwXmDk8Syl4o10arUD3CcvQgFLsVuGMLW3TZOwpj gVZlXwiG7QEwuDm_jIHgiHnpXaI2vyucVgyE540GURP8Q3DpNn8Dwo13wuVjW_8pHVv5UDUPe3a6 W9iLLjfmruFSv5am9b8IyzGNfh_3I_ULGyeHU6DMCSwP80gFHsjld6z1W6koIsghhYVRiHcqmcou _0pgjzDSEARjImQsXimqyv88xQiFRngyZZ3yfUeqEt.YzzZZqemrUqSGLNRVu35sDoqVMgurrixb 1aFo4Jx7JfMup9AQthtikcAMlodMYiHaAtP.I4U2O6xkTMB0PlOw5Zhom7vGXLm_EbZ1Pi3epBnn XN.L92_rAYHOizgSH0IE5u5fQmsymVjQyYVu_W4TKtnZo0NrqqSAnf3c5Fm.k8_msmTij.rPwfmw SUGdJltbf85zXDPwWr13JqH01Mcj3Xn73.yP6Kz969250B.CBBfKg8TPi0OcxqUjX7.gj6luMpfQ Ou9miJuepXdQK.V0hZSZZ21IA3qiWrvU3gxwIQ0briXNktuR4f.wGc4_SroEo8uovvIPcURqljUy sISBd5nUTnuMhKibgYkX5noA.Tcj49OXsW13Hy_1ZD7xLIkumkefswgmOKrz_leG09J5MH2_Qhtd QNS.Il29IhREiA.eYEdE_gLr4Rz9hV9nWEEI98CfG1trLV9cDGdiiGdmlxLc8wFmV3dVYdNZ5PPJ cb_oohcT6.SoU624NgSgeiKoaxp2abl0eB3VPc9absJrEGlsZ9hqHWhrLzayvHV.uMAddiFIkIZC 997jPqtoIxBlMfm0jy5mz9_X7LgF3RebBZG_pJYX2_PXXr9FOk0XiTvtz1nVNT79gprSeqTQlmcj 312tRp7xHdMaSgASvqZE8EsO37TBVuF3Qm5VBL8p3WyUmtPVuxBHP6BIg61DxFxVfwgtBsTGwd4a YzOqM.Owc0JnTEH4jxYp56vbAqqtb3hgiFnJBSAYQShWA3p2OYiaynWItaNZuf476ZOVk_vPX8lM pzeZ12u5kXbbCEq2Ci_RWfKnQRy5qFLvgazqrQB3eF5sW3SNePK0w7DcOj1Ri8fS.tzIlIRDLJIv PDHzJhCLa0MZ5m77oubBTJzSW36AKPEcCDKNSRfjjmRzlblP.MHFg_X.Cw24o3Uogjw2waVzLk9x qMcNpW8tEwOnUihAQiv1bhOqKOhkWjZpOfN4rcvdQshWABw70WjO0mmwMawZ_O45Cy2uYeevxXT0 ASj2o2RL.SEf6eqi72XoYVdVLznuYHlpct4Zjfn_ARUNh31NofXpYJyedInovV46vhAWF1cTH9Jm isHK6eFC9mYSe.hrhDXFuPeRVxc_CXesRNUU519tuvrv3GFEHCZL2zDVvf.yTgk8C.b86fVwLkJ5 H9ultdWCat5spPz2ihg1Qviu9Z3QcQPTskOL7W5dhFB2uZT4ObP9LonFT2pfy.Rgvvseaau0ZJYK x0XYhZUEiDn2sD7owJTfGdg.fxWHqByDktsGrZsP9I_k_a0c65YjRfIj8MzCEZFmb0anPpLulIxa CyHdXKiw2oN461n0ChPY_e00S3s2FyXIHfkQfcm0Nqxxy3HcCxjv_EQTuGp1HIuwMSJAdo8.A9_q D1HBJVSTenNSfoxbJA_OlKTvvfcB.z75M3UwD_aX64wqXAoqUCy04LgHEGy49a1xGt8Xj9ZRCw5I Hu5KFVsP.W9i5HKyvSgJ4_dGsdB0tb.1Jq1SC8AzPJEizfe3hcQncGKSmyWbXljA6pAs6MMjUg6g _7Bt4GNJoWvv.6QaQ4u111qgVCpb14R2SOBVSM9hFd43iw9TjmjiXqliy3wk_RIE_vMl4dKno4g- - X-Sonic-MF: X-Sonic-ID: be45a664-6a4b-47df-9432-40d90adce063 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Dec 2023 18:44:33 +0000 Received: by hermes--production-gq1-6949d6d8f9-ghhkt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9984605b2120fad599367e16a8728077; Mon, 18 Dec 2023 18:44:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] From: Mark Millard In-Reply-To: <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> Date: Mon, 18 Dec 2023 10:44:20 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> To: Harry X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sv7z84Crbz3DNG On Dec 18, 2023, at 10:22, Harry wrote: >=20 > On 12/15/23 16:56, Emmanuel Vadot wrote: >> U-Boot also doesn't support the DRAM controller so we also need an >> external blob from rkbin. >> That's the main reason I haven't done ports for u-boot on rk356x so >> one have to compile u-boot themselve. >> It can be simply done like any other u-boot targets and only needs = two >> env variable : >> export BL31=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf >> export >> ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin >=20 > Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I = came up with so far :-) > I'm trying to understand what happens with the help of this: > http://opensource.rock-chips.com/wiki_Boot_option > The attached diff (updates sysutils/linux-rkbin = (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and = adds sysutils/u-boot-nanopi-r5c) > allows me to build u-boot, supposedly supporting R5C(rk3568). > After putting these onto SD-card with > dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync > dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync > my nanopi-R5C boots from eMMC instead of SD. > I downloaded a NANOPI-R5C_EFI.itb elsewhere. > I can get the TianoCore port booting... > But I'm missing the part, where ubldr, the FreeBSD post-u-boot-loader, = is supposed to take over - and how... > I simply created a freebsd-ufs partition and put /boot along with a = loader.conf onto it, which works using the foreign TianoCore port, but = not my newly created u-boot. >=20 > What am I missung after dd'ing? > Any hints appreciated! FYI: ubldr is no longer part of the standard/typical way of booting = these days, at least for armv7 (and aarch64): = https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=3D0d6e5081= eb00 reports (back in mid-2021): QUOTE author Emmanuel Vadot 2021-05-11 18:27:14 +0000 committer Emmanuel Vadot 2021-05-11 20:22:54 +0000 commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch) . . . sysutils/u-boot-*: Remove ubldr support We have been using loader.efi on armv7 for a long time now. Remove = support for booting with ubldr and the needed patches that were never = upstreamed. While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy in the = Fragment as it's needed to have the cache flushed for us when loader.efi = is started. END QUOTE Any documentation indicating sny ubldr involvement likely predates that change. > -harry >=20 > P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff = attached, the I used the commented nanopi-r5c-rk3568_defconfig! = evb-rk3568_defconfig is a leftover... >=20 > =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 18 22:15:34 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SvDfp4vB0z54B5F for ; Mon, 18 Dec 2023 22:15:46 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SvDfn5WX1z4Kg5 for ; Mon, 18 Dec 2023 22:15:45 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 3BIMFZVi042998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 00:15:35 +0200 (EET) (envelope-from titus@edc.ro) Received: from [192.168.1.5] (79-114-40-228.rdsnet.ro [79.114.40.228] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 3BIMFW7D059333 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 00:15:33 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1702937733; bh=7vc/Xhe/ZGMv2I0OAsWzZ3PnCp4TgnF/h8VQv5mtOS8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=4L/CTPjwCkFDVwJTK88ABudAoBDThHNgN8IjMauZQy3mPmD6e/GTndboHV5xFUiXp b41TPzDGbov0fy7CILKYB01fUXdiKkez/V30Ed/E5nWx9+F8pNNwquSy/kioLxOLnU u5Q0GHy5J/Z8kHdfuaYSLbBhVyY4po9AysaYS7YA= From: titus Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] Date: Tue, 19 Dec 2023 00:15:34 +0200 In-Reply-To: <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> Cc: Harry , freebsd-arm To: Mark Millard References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SvDfn5WX1z4Kg5 --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii if u-boot is configured with EFI support then u-boot loads loader.efi directly (bootaa64.efi) which is already on = aarch64 images > On 18 Dec 2023, at 20:44, Mark Millard wrote: >=20 > On Dec 18, 2023, at 10:22, Harry > wrote: >>=20 >> On 12/15/23 16:56, Emmanuel Vadot wrote: >>> U-Boot also doesn't support the DRAM controller so we also need an >>> external blob from rkbin. >>> That's the main reason I haven't done ports for u-boot on rk356x so >>> one have to compile u-boot themselve. >>> It can be simply done like any other u-boot targets and only needs = two >>> env variable : >>> export BL31=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf >>> export >>> ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin >>=20 >> Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I = came up with so far :-) >> I'm trying to understand what happens with the help of this: >> http://opensource.rock-chips.com/wiki_Boot_option >> The attached diff (updates sysutils/linux-rkbin = (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and = adds sysutils/u-boot-nanopi-r5c) >> allows me to build u-boot, supposedly supporting R5C(rk3568). >> After putting these onto SD-card with >> dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync >> dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync >> my nanopi-R5C boots from eMMC instead of SD. >> I downloaded a NANOPI-R5C_EFI.itb elsewhere. >> I can get the TianoCore port booting... >> But I'm missing the part, where ubldr, the FreeBSD = post-u-boot-loader, is supposed to take over - and how... >> I simply created a freebsd-ufs partition and put /boot along with a = loader.conf onto it, which works using the foreign TianoCore port, but = not my newly created u-boot. >>=20 >> What am I missung after dd'ing? >> Any hints appreciated! >=20 > FYI: ubldr is no longer part of the standard/typical way of booting = these days, > at least for armv7 (and aarch64): >=20 > = https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=3D0d6e5081= eb00 = >=20 > reports (back in mid-2021): >=20 > QUOTE > author Emmanuel Vadot > = 2021-05-11 18:27:14 +0000 > committer Emmanuel Vadot > = 2021-05-11 20:22:54 +0000 > commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch) > . . . > sysutils/u-boot-*: Remove ubldr support > We have been using loader.efi on armv7 for a long time now. Remove = support for booting with ubldr and the needed patches that were never = upstreamed. While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy in the = Fragment as it's needed to have the cache flushed for us when loader.efi = is started. > END QUOTE >=20 > Any documentation indicating sny ubldr involvement likely predates = that > change. >=20 >> -harry >>=20 >> P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff = attached, the I used the commented nanopi-r5c-rk3568_defconfig! = evb-rk3568_defconfig is a leftover... >>=20 >> >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii if = u-boot is configured with EFI support then
u-boot loads = loader.efi directly (bootaa64.efi) which is already on aarch64 = images


On 18 Dec 2023, at 20:44, Mark = Millard <marklmi@yahoo.com> wrote:

On Dec 18, 2023, at 10:22, Harry = <freebsd@omnilan.de> wrote:

On 12/15/23 16:56, Emmanuel Vadot wrote:
U-Boot also doesn't = support the DRAM controller so we also need an
external = blob from rkbin.
That's the main reason I haven't done = ports for u-boot on rk356x so
one have to compile u-boot = themselve.
It can be simply done like any other u-boot = targets and only needs two
env variable :
export BL31=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf
export
ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18= .bin

Thanks! I'm happy that - = besides the ddr_CLOCK - it matches what I came up with so far :-)
I'm trying to understand what happens with the help of = this:
http://opensource.rock-chips.com/wiki_Boot_option
The attached diff (updates sysutils/linux-rkbin = (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) = and adds sysutils/u-boot-nanopi-r5c)
allows me to build = u-boot, supposedly supporting R5C(rk3568).
After putting = these onto SD-card with
dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync
dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync
my = nanopi-R5C boots from eMMC instead of SD.
I downloaded a = NANOPI-R5C_EFI.itb elsewhere.
I can get the TianoCore port = booting...
But I'm missing the part, where ubldr, the = FreeBSD post-u-boot-loader, is supposed to take over - and how...
I simply created a freebsd-ufs partition and put /boot along = with a loader.conf onto it, which works using the foreign TianoCore = port, but not my newly created u-boot.

What = am I missung after dd'ing?
Any hints appreciated!

FYI: ubldr is no longer part of the standard/typical way of = booting these days,
at least for armv7 (and aarch64):

https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id= =3D0d6e5081eb00

reports (back = in mid-2021):

QUOTEauthor Emmanuel Vadot = <manu@FreeBSD.org> 2021-05-11 18:27:14 = +0000
committer = Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 20:22:54 +0000
commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 = (patch)
. . = .
sysutils/u-boot-*: Remove ubldr support
We have been using loader.efi on = armv7 for a long time now. Remove support for booting with ubldr and the = needed patches that were never upstreamed. While here add = CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy in the Fragment as it's needed to = have the cache flushed for us when loader.efi is started.
END QUOTE

Any documentation indicating sny = ubldr involvement likely predates that
change.

-harry

P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the = diff attached, the I used the commented nanopi-r5c-rk3568_defconfig! = evb-rk3568_defconfig is a leftover...

<FE-r5c_ports.diff.xz>



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

= --Apple-Mail=_E8C69677-2A32-4B2D-B5C6-C26193A27F4C-- From nobody Mon Dec 18 23:32:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SvGM56k7Pz54H8S for ; Mon, 18 Dec 2023 23:32:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SvGM51fW1z3fYm for ; Mon, 18 Dec 2023 23:32:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702942334; bh=oGhUACRadBfdiyR6A9dJVAnerX0paeu7yuEFaeDFhPc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YqfowSjn/FmvyMCMXO1pTsDCqxq/Qs6prtJHT9Rf4IQSIMt/pDc3eCu9n1SxiKWZP0qKu1g0vDurr1DwnUhv2Cq+bgEYkNzLNXnS32lsn2pZVYaFVpE1ubWwcz57VN6pto49DGsq676TlejfmCwaQBbWbJPh7OR2CyU1QRmExFSfOioALmxgn9+IBxEyKx/kT7ATEJOVDWWvj1EnB0cmrrpJalonfCSUsgwoqfo0HTVfHXGsqgCSHH8rOIUO4yC+r1PkVf1W1nBsoxhAYfepOa6+r0Kt+bAWMsrbSzSoj8bXLNNb0lCQRbAyfH0v16Z2OCpgSiBjc8u7F5Cc1Az7vQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1702942334; bh=bB9v90DboDJ9tA9UOHe1ZxYsQZnf9KcFBBcAyk6kvTo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SubyJSob2GzbMxcJAL0/bRBZHHW3jnePOKK7ewLylcfwacIznupKV8d2fTk2Fcu6kqAB67MuOsUSB13s4ytp3Ng/X0YcJgaIoqluPbCEUE5rG+ZfZ4AeV0CVkhshYdNQQT5UfKP5tT5l5bhMfEZzs3YvHft9+299BjcYHykEf9qlsyihzwX4ujeodwcngwdKl+zawCSeLgroQIiGr3zGsTqB5QBsQyLPdoKtgQdHTbqUHXmsiZFQ80VcLq8LIjCRE4kJf4LsQAfnAFHa+1Z/+Ujn5NfMBoYh10ZqrM8D4yEe57PGeRYj81cbHqvUXsCrZUwrV/UYr7zPKZ/BCJWJYQ== X-YMail-OSG: qhPB9A4VM1k5fxSrUo50ISuG540c6NBArDBRA3_qAlMjlRn84xd2nogcidOoLP. U0nRqH2ZNdjb0zq8jR2VoLvCR0pNPK5yoz9dSvMmTyzi7qtGU_1YE3_X1td0_IfeRMMkoyFY8X93 itrwZYYE7W94rOxNh0Zv70CcNjN6qJY91vQTvfjEcHJJ_m1xFV1eUDMzyQqDlpy7dU45LTf6CWeS ct7.GherQ.MxOur7mYbqkGFpfYbFZEZt.HS4Y.W5qrIS57O5c.nHCUfA51cpxXzE14PPFVYfjCEX KZwEXXV0XOCh3_HBAv9mqxeGEQ_SYuLICuJvZcmlNrEUQxHQzGh9uN4HkolKSal6QxGFJqnCUBOR MTp0R.GlzJWP1Nf1Rv5HldLz5OWHB13S_BNp_YYYHkNd2Bso0Gl92WoFdvrxRVNqCSi8wR61NzoH EGMZnNiriPCoGcj57eRCfEyohAirfwrBXJOwkLum2VXBZvc44fxvSvwkNjoH.dXkFQlF3nspHeLC 1MASYgdSYw7Q4sLs9DA.NT.U4LihSTsGFpHduFPNwVXyylhjpDdv_uJAYMfg.AfD1FYLl4Um.Zef 3g.d43.zFC36dKdAfwcQJooDQL6PNZHIJ7UCSSzRwfz.g3eiFUZn_d_Jj0A_2jqxfSJfkp6zxp3c w4iqUGagcNQxEnKUN06zzdwvavy04Rkegyn31FN9frt9C5.Be5urH9X8YEb6SE_I.qVk_qWX8Liz _Q5SqpZ90NQEB_plf70rbxJJx6gb6Yl3X6tonQzQjsWrJjkKqrcGMIC4nHZ08OYPKcDv0LhR0dDn EH4cE2XUvmL.7UONCPee2emYj8vYQfQtkjwwaaZ0LEkpei_vLAm4_WjU86G0xbWVixHBCUABptX9 _uKUOXYJaehGc.80eSPmfVguiWwfbUleXYyzLCal6lC10A21T3DPes3NYAh_G0P6Y9_hg.6sp3VP _r3WcjQlBs2lniCDnSrCzXuFy0Qwo0nOZQt1smHK0zaoB_a91dTpCmiwfD3Tn9jjiS7VtjxtilNj b0TnE_2tCFdCxwfnn5n2dK831Q2RNvfQnQmB9wyxfVfZwR1UlXFhASisaLhCaZm7TBLgMUqyRgdX 6Dok0evDQc_x0eQ0xMNlrjJ_kRjotnyBvCn2rW5jwNmYDm51AYQI7Eq0ApA3PsHjrRKUwjybuFGM fTnEvWWtrdNv4Bui7thyxCjxbYpSgZr_7fiaSCu9egz.QEsbEsA9vnRS96akp88TZKQbueaZne_v 0GxMHPYL0W7Cn0nYiguURo0prfZQ.sVlVRdfK_U_trby0k1UIsjYzlZOMkmeRLT9XEiLrco0112D hjzUhxygGLmS.DoFhbjJPTE_qE81y5kLcA9McWVDNE2gWfkIUJEDqnCVjwyHFzi3ebVpfbhZaS7v d8cA108yCfWk52e5W_25_nzzLzI3A8KzF3QbcmPybQ_UMgIExc4Q.w9MhKHSWec1VdNNpHJoil9g VTheOe5E2FJdq2JsUi5jm5Y3AZVicImHlVUxtZBcxypLTz6y31K_m98HxGvERbtSPSoLkgW8iF_0 MsQJLcwI0Ifm9qtuf.wM_pkkJOEG68fRFIJtciestctj1LOjPF._squ3lPM7WwHSv7bQoqv1gl4W pA0ZGGZV4c18yCJkWlAjAcF6jXM1tlnx7yydZ_qsjGBNczcxXPzSSNbiqOs_dQ1ubMSIOdwb4dx1 CZ.NjnvS8XPAzBdL628JlQ4MtVpLHRYeDokCGUC9Xahm9ahl2IQ1IW5RCE.wjYc27iVCHLY.n2xZ Q.oh5zRPdrxtpQ.df349YBYj5zPvdsnSl_Pui3ptAmDhKrnMf7E0wlEBWuDuTAIUPWLtB_evYlWx Vo0qUYmuXw1EkZarvRLbeSOItYBY4vZ1MSSRTSHGQGhCPKFphJkfW9xY.BZw_GtYFOlv8rMqsgeX PTKf6m2iepN9uLfNuF5nv6wdRzmomAJlqMYqduKSM.PDdzTiXWUm9Up7k.zGNK5V.wo4Dwun1pq6 oiUZ25kSO3dcbkAzFE8FrPhGeTBzX6z9q7CIcqguw1XQ5KvLU.j356yTVjJak29wSnt_pkJx.FHN OB1yJ_4fuU4QUv3svuAS9rFJXntBrLtlSgmd2_aUuRCNp8Kh0JhkEW46lJOn1lEqeckM2eghCdaI Gt4LM0GZmWm3elfM4GjU3ZkDO549fpJjZx9tX0xdqXZdlpfIFDlxKdHGZXb2GfUPqkuLJNRJLsCv hShEsl1L.dPj8lylyqk.IaQyqV2OZZAaDIC25GPfSCKKla6QCV5FOQEL8R03JYFx8F5yJxzgen.0 q X-Sonic-MF: X-Sonic-ID: 926b5008-ba38-4486-a025-92e3bdbdce60 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Dec 2023 23:32:14 +0000 Received: by hermes--production-gq1-6949d6d8f9-x28h5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 423d401d47dce29c4e415d9f463280b7; Mon, 18 Dec 2023 23:32:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] From: Mark Millard In-Reply-To: Date: Mon, 18 Dec 2023 15:32:00 -0800 Cc: Harry , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <578FCC1A-71B9-4712-948C-CC35D6AC89CD@yahoo.com> References: <2CE509A2-AECF-4562-A080-589AC7888F21@edc.ro> <20231012184430.952dd9d5a26c97ee225c9e77@bidouilliste.com> <5211ad65-5289-4776-b839-7c681de77bf4@omnilan.de> <20231215165640.78bab647c883368b8fc9c34e@bidouilliste.com> <04c04e63-cfe2-4fa6-b6c3-615b6ae8a3d6@omnilan.de> <6DCACFA0-0377-4D6F-804A-CF5CEC8918DB@yahoo.com> To: titus X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SvGM51fW1z3fYm On Dec 18, 2023, at 14:15, titus wrote: > if u-boot is configured with EFI support then > u-boot loads loader.efi directly (bootaa64.efi) which is already on = aarch64 images Up to detailed naming conventions, armv7 also works via a renamed loader.efi for FreeBSD's way of setting things up (such as via sysutils/u-boot-* ports) and has for years. The name is bootarm.efi for armv7. For example, each of: = FreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20231216-ca39f23347e1-266973.img.= xz = FreeBSD-14.0-STABLE-arm-armv7-GENERICSD-20231216-2ef9079ece5a-266002.img.x= z = FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20231216-9986fd59d855-256898.img.x= z from the = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/?C=3DM&O=3DD area are that way. >> On 18 Dec 2023, at 20:44, Mark Millard wrote: >>=20 >> On Dec 18, 2023, at 10:22, Harry wrote: >>>=20 >>> On 12/15/23 16:56, Emmanuel Vadot wrote: >>>> U-Boot also doesn't support the DRAM controller so we also need an >>>> external blob from rkbin. >>>> That's the main reason I haven't done ports for u-boot on rk356x so >>>> one have to compile u-boot themselve. >>>> It can be simply done like any other u-boot targets and only needs = two >>>> env variable : >>>> export BL31=3D/path/to/rkbin/bin/rk35/rk3568_bl31_v1.43.elf >>>> export >>>> ROCKCHIP_TPL=3D/path/to/rkbin/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin >>>=20 >>> Thanks! I'm happy that - besides the ddr_CLOCK - it matches what I = came up with so far :-) >>> I'm trying to understand what happens with the help of this: >>> http://opensource.rock-chips.com/wiki_Boot_option >>> The attached diff (updates sysutils/linux-rkbin = (g20190719->g20230726), sysutils/u-boot-master (2020.07->2023.10) and = adds sysutils/u-boot-nanopi-r5c) >>> allows me to build u-boot, supposedly supporting R5C(rk3568). >>> After putting these onto SD-card with >>> dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/id= bloader.img of=3D/dev/da1 seek=3D8 bs=3D4k conv=3Dsync >>> dd = if=3D/.chroot/build.FreeBSD-14/usr/local/share/u-boot/u-boot-nanopi-r5c/u-= boot.itb of=3D/dev/da1 seek=3D2048 bs=3D4k conv=3Dsync >>> my nanopi-R5C boots from eMMC instead of SD. >>> I downloaded a NANOPI-R5C_EFI.itb elsewhere. >>> I can get the TianoCore port booting... >>> But I'm missing the part, where ubldr, the FreeBSD = post-u-boot-loader, is supposed to take over - and how... >>> I simply created a freebsd-ufs partition and put /boot along with a = loader.conf onto it, which works using the foreign TianoCore port, but = not my newly created u-boot. >>>=20 >>> What am I missung after dd'ing? >>> Any hints appreciated! >>=20 >> FYI: ubldr is no longer part of the standard/typical way of booting = these days, >> at least for armv7 (and aarch64): >>=20 >> = https://cgit.freebsd.org/ports/commit/sysutils/u-boot-master?id=3D0d6e5081= eb00 >>=20 >> reports (back in mid-2021): >>=20 >> QUOTE >> author Emmanuel Vadot 2021-05-11 18:27:14 +0000 >> committer Emmanuel Vadot 2021-05-11 20:22:54 +0000 >> commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch) >> . . . >> sysutils/u-boot-*: Remove ubldr support >> We have been using loader.efi on armv7 for a long time now. Remove = support for booting with ubldr and the needed patches that were never = upstreamed. While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy in the = Fragment as it's needed to have the cache flushed for us when loader.efi = is started. >> END QUOTE >>=20 >> Any documentation indicating sny ubldr involvement likely predates = that >> change. >>=20 >>> -harry >>>=20 >>> P.S.: sysutils/u-boot-nanopi-r5c/Makefile is wrong in the diff = attached, the I used the commented nanopi-r5c-rk3568_defconfig! = evb-rk3568_defconfig is a leftover... >>>=20 >>> >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 19 15:28:47 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SvgbY0FhWz54QLV for ; Tue, 19 Dec 2023 15:29:29 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SvgbW4l6Vz4ZdQ for ; Tue, 19 Dec 2023 15:29:27 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TXZi4UCo; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a2370535060so263615566b.1 for ; Tue, 19 Dec 2023 07:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702999765; x=1703604565; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uZTibxYoVXyZHPrL/nU7tAAF4GnSbtnveYq8sdS6ZzI=; b=TXZi4UCo+ECR251BsWbyxb2lF8hyT7y589uz3akQ986mOW4QR+7rTjod4DarEQ/GmX wfU6P+2U/b1qdKfGF1tCYFzLcNbYyXUOhUJiwP2LKIc07OU3vrtXPkqrpZzlM+74aPCW 9fblFGl/hlBVS8XVBWWp6HoLpZawAALTPDj4L1tkbRbOIikdEnbFf0lpWzoq7Lb3cANX 2UFAjqes1GIAKZER73gy9nirtuFgI0wF+U8x/ZXi+A2aMbqLpxaCMK9ZXX4RwrTfCVVZ Ip32Wej5wWucjBJ/dtp2AluRAY1XHBo6XQstSoSddQi3rYtiecvA3YZ0VrPRjTzT5PRX P07g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702999765; x=1703604565; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uZTibxYoVXyZHPrL/nU7tAAF4GnSbtnveYq8sdS6ZzI=; b=h3C9TzzAnEJzStznWSTcxI+tbcHtbMmjW9fu5Unr6Mp/sQ8m3EiLftco+7QrTnXgtD MC9T+l8fB55V7xg9Stdh0Nl61dz8EDET0K+kfnCUkMOGUiUzKa8OYHivR/CmRhVX+Z8P GZoVJFfIUA3SYpXJTSqS8RDlniQoSuBXI9IXgKC++36hAdOE9laf4Z9oFAhGWElgGKf5 BXnfvDF8rq1bEHC9Bg9rVhGFdtXuW0G4SYvugBxrkJUdtWr5LjxOgMiijzy+xP3f7jXZ xRSgYrYj7CmrvX0X6KaAaPPXh6z0CCX0zndTglovSxofFOMhANBup9omdSKLAMnLMz/P JCZw== X-Gm-Message-State: AOJu0Yzsm5J6eY8tUbTxw2Pvu0fBIWRaLWO3rL3oey5Pk14C+Y4G8feH aGW1vY7hOzLqie0f7QsNc5wnwHKMRSI7oXlDHrPeapl1TOA= X-Google-Smtp-Source: AGHT+IFsayR6t7I2kBDKEW3prJWkRaTwdXpt7p3hrYKQDThl3p7klUCGTQg2aScpzGktRLrCk8yNKVi4Q4QnSDuSC44= X-Received: by 2002:a17:906:f9c4:b0:a23:49ec:9bad with SMTP id lj4-20020a170906f9c400b00a2349ec9badmr1132099ejb.77.1702999764638; Tue, 19 Dec 2023 07:29:24 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Tue, 19 Dec 2023 16:28:47 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000062155060cde8899" X-Spamd-Result: default: False [-3.00 / 15.00]; URI_COUNT_ODD(1.00)[69]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4SvgbW4l6Vz4ZdQ X-Spamd-Bar: -- --000000000000062155060cde8899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello to everyone. I have compiled the needed u-boot.bin from scratch using this procedure : # git clone https://github.com/u-boot/u-boot.git # cd u-boot # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig : thi= s line generates the file .config # nano .config and I've added these parameters : CONFIG_ARMV7_NONSEC=3Dn CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy the uboot-bin file is generated with this command : # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make At this point,I took a look inside the .config file and I saw that the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some reason,it is not accepted and this could be a problem.... These are the xen config files that I've used : nano freebsd.cfg name=3D"test" kernel=3D"u-boot.bin" extra =3D "console=3Dhvc0" memory=3D256 vcpus=3D1 disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] nano start-freebsd xl create freebsd.cfg xl console freebsd This is what happens when I launch the vm : # ./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 1:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-existent domain libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable to destroy guest libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction of domain failed freebsd is an invalid domain identifier (rc=3D-6) On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto wrote: > So,ok,I should have said "the second u-boot" ; since the first u-boot > binary is the "u-boot binary located in the RO memory" of the Chromebook"= . > Sorry for the confusion. > > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto > wrote: > >> ---> There are no specific options in u-boot devoted to FreeBSD >> >> This is an important factor. So,what about if,instead of compiling a new >> version of u-boot on the partition 2,I will recompile the u-boot customi= zed >> version created by the virtual open system in 2014,that should be instal= led >> on the first partition ? It could work if there are no differences betwe= en >> the u-boot that should boot Linux and the u-boot that should boot FreeBS= D. >> >> Can you give a look at the u-boot source code created by virtual open >> systems ? You can find it on my google drive : >> >> >> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?u= sp=3Dsharing >> >> I need to understand if I can recompile it without problem so that it ca= n >> satisfy my needs (the ability of the file u-boot.bin to boot FreeBSD as >> domU under Xen,as explained by Stefano Stabellini,the xen developer that >> suggested to me what I could do to have FreeBSD virtualized under Xen on= my >> Arm Chromebook) ; otherwise the risk is to find later problems that will >> make me troubles and that I will not able to fix. >> >> I gave a look at the virtual open system u-boot and I didn't see any arn= dale_defconfig >> inside. So,If I have understood correctly,I should put that file inside = the >> root of the u-boot source code,let's say here : >> >> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >> >> .checkpatch.conf README doc >> net >> .git api drivers >> onenand_ipl >> .gitignore arch dts >> post >> COPYING board examples >> rules.mk >> CREDITS boards.cfg fs >> scripts >> MAINTAINERS common include >> snapshot.commit >> MAKEALL config.mk lib >> spl >> Makefile cros mkconfig >> test >> PRESUBMIT.cfg disk nand_spl >> tools >> >> and I should do : make and make install ? and the file I need,u-boot.bin >> will be generated ? >> >> I didn't find any pre made configuration file inside : >> >> u-boot-vos # find . -type f -name "exynos*" >> >> ./include/exynos-fb.h >> ./include/configs/exynos5-common.h >> ./doc/device-tree-bindings/spi/exynos-spi.txt >> ./doc/device-tree-bindings/usb/exynos-usb.txt >> ./drivers/power/exynos-tmu.c >> ./drivers/power/exynos-cpufreq.c >> ./drivers/video/exynos-fb.c >> ./drivers/spi/exynos_spi.c >> ./board/samsung/dts/exynos5250-spring.dts >> ./board/samsung/dts/exynos5250-smdk5250.dts >> ./board/samsung/dts/exynos5250-snow.dts >> ./board/samsung/dts/exynos5250-daisy.dts >> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >> ./arch/arm/dts/exynos5250.dtsi >> ./arch/arm/dts/exynos-periph-id.dtsi >> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >> >> u-boot-vos # find . -type f -name "arndale*" >> >> For sure I can't use a newer version of u-boot because otherwise the >> patches needed to bypass the bootloader protections of the Arm Chromeboo= k >> (such as a lot of different patches needed to boot correctly Linux) will= be >> broken ; anyway,since it works,I don't need to use an updated version of >> u-boot. >> >> ----> As per my experience, you have to respect these two options, >> compiling u-boot for FreeBSD: >> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-maste= r/files/FreeBSD_Fragment >> >> It says that I should use these parameters : >> >> CONFIG_ARMV7_NONSEC=3Dn >> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >> >> These are the parameters used to configure a Linux kernel. I don't >> understand what's the relation between the compilation of a linux kernel >> and u-boot. In the past I tried to recompile u-boot,but I didn't have th= e >> need to set up those parameters,so I don't know how to do it (but I know >> how to recompile a Linux kernel). >> >> >> ---> I'm not sure that I'm getting you right, as I don't understand what >> you mean under "the first u-boot". >> >> >> I'm talking about first u-boot because the whole procedure to boot Linux >> on the ARM Chromebook,that's explained here : >> >> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ >> >> >> at some point they say : >> >> >> To be able to run KVM on ARM platforms, the kernel has to be booted in >> hypervisor mode. Because of this relatively recent requirement (due to t= he >> introduction of the virtualization extensions), up until now all booting >> methods would boot the kernel in the standard Supervisor mode. >> >> For the ARM Chromebook the default boot procedure doesn't allow us to >> boot in hypervisor mode. Although the laptop's boot mechanism is based o= n >> the frequently used u-boot, the binary is located in RO memory. >> Fortunately, a chained u-boot mechanism can be used (i.e. starting anoth= er >> u-boot after the original). We can then enter hypervisor mode from our >> custom iteration of u-boot and subsequently load our kernel and userspac= e. >> >> So,the first u-boot is the u-boot provided by virtual open systems,that'= s >> able to chainload the "u-boot binary located in RO memory" , that does n= ot >> boot Chrome OS in hypervisor mode. We don't need it if we want to boot >> Linux with kvm or xen enabled. >> >> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >> stanislav.silnicki@mailgate.us> wrote: >> >>> I'm not an expert in the topic, I only know, that ARM has divided >>> hardware into two worlds - Secure and Not-So, strictly limiting any >>> software, running in non-secure world with access to functions and >>> resources. >>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-ha= rdware-architecture?lang=3Den >>> >>> I'm not sure, that I'm getting you right, as I don't understand what yo= u >>> mean under "the first u-boot". >>> >>> As I understand, virtualization (HYP) is running in non-secure world ( >>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architec= ture/The-System-Level-Programmers--Model/The-Virtualization-Extensions), >>> so my guess (only guess!!!), virtualization software has to prepare >>> (configure) HW platform in the way, that FreeBSD kernel will not lack a= ny >>> resources, required to configure MPU, VA, etc. >>> So, if you lucky to boot virtualizer, which is aware of target OS, that >>> maybe you can boot the kernel. Although, I doubt, that you need to boot >>> 'second' u-boot to boot the kernel - there is simply ubldr, which you c= an >>> hook somehow from virtualizer.... >>> >>> Stan >>> >>> >>> >>> Mario Marietto wrote: >>> >>> >>> ---> As I understand, it makes sure that u-boot keeps in secure mode >>> during boot and passes control to ubldr, which boots FreeBSD kernel, in >>> that mode. >>> >>> Can you elaborate your sentence more ? I know that the bootloader secur= e >>> mode is bypassed by the virtual open systems u-boot. Are you saying tha= t >>> when the control passes to the second u-boot,it will happen in secure >>> mode,so that the bypass that happened loading the first u-boot,is annul= led >>> ? If this is true,maybe can I boot FreeBSD using the virtual-open-syste= m >>> custom u-boot ? Is this compatible with FreeBSD ? Where can I find the >>> u-boot.bin that the xen developer talked about ? thanks bro'. >>> >>> >>> >>> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> >>>> Hi Mario, >>>> >>>> U-Boot beast is hiding in this den: >>>> https://source.denx.de/u-boot/u-boot.git >>>> I took a brief look at your post and it seems to me, that option >>>> CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit >>>> platform: >>>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/= Kconfig?ref_type=3Dheads#L3 >>>> >>>> As for compiling the u-boot, it is a doable task, given that you >>>> understand what you are doing. There are no specific options in u-boot >>>> devoted to FreeBSD. It is a boot loader, whose mission to make basic >>>> hardware initialization, read you kernel file from some media into RAM= and >>>> then pass it control. >>>> >>>> Basically, you can grab some defconfig, prepared for any other >>>> Exynos5250 based board (say, this one: >>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_def= config?ref_type=3Dheads) >>>> and adopt it somehow. >>>> >>>> As per my experience, you have to respect these two options, compiling >>>> u-boot for FreeBSD: >>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mas= ter/files/FreeBSD_Fragment >>>> >>>> As I understand, it makes sure, that u-boot keeps in secure mode durin= g >>>> boot and passes control to ubldr, which boots FreBSD kernel, in that m= ode. >>>> Otherwise, there a lot of surprises you may realize. >>>> >>>> Hope, this will help to progress you tasks >>>> Stan >>>> >>>> Mario Marietto wrote: >>>> >>>> >>>> Hello. >>>> >>>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook. >>>> Basically there are two ways to accomplish this task : >>>> >>>> 1) to write a patch that allows the FreeBSD kernel to boot as a zImage >>>> file. This could be accomplished applying this patch to a specific fil= e >>>> that's on the source code of FreeBSD : >>>> >>>> >>>> >>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc13914727170= 35f986c979edef0c9 >>>> >>>> >>>> >>>> This patch was written by Julien Grall a lot of time ago and now it >>>> does not work anymore. This is the reason : >>>> >>>> >>>> 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. >>>> And I'm not able to fix it. >>>> >>>> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = : >>>> >>>> >>>> I was trying to explain why and how Julien's patch works so that you >>>> could be the one to re-do something similar or fix the patch on the Fr= eeBSD >>>> kernel that you are working with. I am happy to help review and write >>>> patches but I don't work with the FreeBSD kernel so I wouldn't be able= to >>>> help you quickly. However, I might have a suggestion. Do you know if >>>> FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as X= en on >>>> ARM guest firmware/bootloader. You should be able to build U-Boot and = use >>>> the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD = from >>>> disk or network and start it. For instance as domU config file: >>>> >>>> kernel=3D"/home/petalinux/u-boot.bin" >>>> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>> >>>> I know it is important to build u-boot with the following config to >>>> make it work on Xen. >>>> >>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>> >>>> >>>> >>>> This option seems more doable to me according to my knowledge. But I >>>> need to understand how to do it. >>>> >>>> Well,let's say that on the ARM Chromebook I'm forced to use and instal= l >>>> a customized version of u-boot,created by virtual open systems,because= it >>>> is the only one that allows bypassing its bootloader protection. You c= an >>>> find more information here : >>>> >>>> >>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeboo= k/?vos=3Dtech >>>> >>>> This is the relevant section to read : >>>> >>>> >>>> Bootloader : >>>> >>>> If you wish to skip this chapter you can download a pre-compiled binar= y >>>> of the bootloader: >>>> >>>> >>>> $ wget >>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/n= v_u-boot-snow.kpart >>>> >>>> >>>> To be able to run KVM on ARM platforms, the kernel has to be booted in >>>> hypervisor mode. Because of this relatively recent requirement (due to= the >>>> introduction of the virtualization extensions), up until now all booti= ng >>>> methods would boot the kernel in the standard Supervisor mode. For the= ARM >>>> Chromebook the default boot procedure doesn't allow us to boot in >>>> hypervisor mode. Although the laptop's boot mechanism is based on the >>>> frequently used u-boot, the binary is located in RO memory. Fortunatel= y, a >>>> chained u-boot mechanism can be used (i.e. starting another u-boot aft= er >>>> the original). We can then enter hypervisor mode from our custom itera= tion >>>> of u-boot and subsequently load our kernel and userspace. >>>> >>>> Checkout the needed u-boot code : >>>> >>>> >>>> $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ >>>> ./scripts/build.sh >>>> >>>> >>>> If successful, a message about how to copy the bootloader on the USB >>>> flash disk or SD card will appear. We will use it later when preparing= the >>>> boot medium to start our system. If you have followed the Setting up t= he >>>> boot medium chapter and you have a prepared boot device, then you can >>>> update u-boot by running : >>>> >>>> >>>> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>> >>>> >>>> >>>> so,the needed u-boot that we must use should be installed on the first >>>> partition of the sd card. >>>> >>>> There is another relevant section to read : >>>> >>>> >>>> Setting up the boot medium >>>> >>>> Now it is time to copy all the relevant files that we created in the >>>> previous chapters,and use them to boot Chromebook with a different ker= nel >>>> and OS. In all these examples the device /dev/sdX is used. Take extra = care >>>> to change the examples to the device that you have attached. Insert th= e >>>> boot medium on your workstation and carefully execute the following st= ep. >>>> First we need to properly format the boot medium. >>>> >>>> In the uboot source directory : >>>> >>>> >>>> $ sudo ./scripts/sdcard.sh /dev/sdX >>>> >>>> >>>> This will erase all data and create 4 partitions in the medium, along >>>> with copying the u-boot binary to the first partition: >>>> >>>> >>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> Partition 2 =3D not used >>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>> exynos5250-snow.dtb) >>>> Partition 4 =3D EXT4 partition for userspace files >>>> >>>> >>>> With u-boot being copied, next is the kernel image and DTB file. From >>>> the kernel source execute : >>>> >>>> >>>> $ mkdir ../mnt/ >>>> $ sudo mount /dev/sdX3 ../mnt/ >>>> $ sudo cp arch/arm/boot/uImage ../mnt/ >>>> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>> $ sudo umount /dev/sdX3 >>>> >>>> >>>> Finally, we have to copy the Ubuntu userspace filesystem that we >>>> created earlier: >>>> >>>> >>>> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount >>>> /dev/sdX4 >>>> >>>> >>>> >>>> Now,my idea is to chainload the already chain loaded u-boot created by >>>> V.O.S to the new u-boot that we need for booting FreeBSD and that can = be >>>> installed in the partition n.2,as shown in this scheme,because it is n= ot >>>> used : >>>> >>>> >>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>>> bit,compatible with FreeBSD on this partition) >>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>> exynos5250-snow.dtb) >>>> Partition 4 =3D EXT4 partition for userspace files >>>> >>>> >>>> Take in consideration that default boot string is hardcoded here,in th= e >>>> snow.h file of the custom u-boot created by VOS : >>>> >>>> >>>> >>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/config= s/snow.h#L101 >>>> >>>> >>>> >>>> and it needs to be recompiled because it should point to the partition >>>> n.2,where I will install the u-boot files as explained here : >>>> >>>> >>>> https://wiki.freebsd.org/arm/Chromebook >>>> >>>> >>>> I have some questions to ask before I start working on this. >>>> >>>> 1) The xen developer said : >>>> >>>> >>>> You should be able to build U-Boot and use the U-Boot binary as Xen >>>> guest kernel... >>>> >>>> >>>> >>>> where is the u-boot binary,according to this document ? >>>> >>>> https://wiki.freebsd.org/arm/Chromebook >>>> >>>> I don't see it. >>>> >>>> >>>> 2) where is the source code of the file that I can get here : >>>> >>>> >>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles= /nv_uboot-snow-simplefb.kpart.bz2 >>>> >>>> I need the source code if I want to recompile u-boot so that it can >>>> point to the partition 4. >>>> >>>> Maybe it can be found on this link : >>>> >>>> http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>> >>>> but it can't be opened.... >>>> >>>> >>>> 3) in this specific scenario the source code of u-boot should run on >>>> arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW" = model >>>> XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex = A15) >>>> Soc. >>>> >>>> >>>> 4) I'm not sure if I can chainload the customized u-boot created by >>>> V.O.S that should be installed on the first partition with the u-boot >>>> tailored for booting FreeBSD that should be installed on the partition= 2.... >>>> >>>> >>>> 5) the xen developer said that u-boot should be compiled enabling this >>>> option : >>>> >>>> >>>> Code: >>>> >>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>> >>>> >>>> >>>> Well,can you provide some good source that can help me to understand >>>> how I can recompile u-boot for FreeBSD ? thanks. >>>> >>>> -- >>>> Mario. >>>> >>>> >>> >>> -- >>> Mario. >>> >>> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --000000000000062155060cde8899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to everyone.

I have compiled the needed u-boot.bin from scratch using this proce= dure :

# git clone <= a href=3D"https://github.com/u-boot/u-boot.git" target=3D"_blank">https://g= ithub.com/u-boot/u-boot.git
# cd u-boot
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_de= fconfig : this line generates the file .config
# nano .config and I've= added these parameters :

CONFIG= _ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

the uboot-bin file is generated with this command :

<= div># ARCH=3Darm CROSS_COMPILE=3Darm-linux-gn= ueabihf- make

At this point,I took a look inside the .config file and I saw that the=20 parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some= =20 reason,it is not accepted and this could be a problem....
These are the xen config files that I've used :

nano freebsd.cfg

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

nano start-freebsd

<= /span>
xl create freebsd.cfg
xl console freebsd

This is what happens when I launch the vm :

# ./start-freebsd
=C2=A0
Parsing config from freebsd.c= fg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader foun= d: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain= 1:cannot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D= -6)


On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto = <marietto2008@gmail.com>= ; wrote:
So,ok,I should have said "the second u-boot" ; since th= e first u-boot binary is the "u-boot binary located in the RO memory&q= uot; of the Chromebook". Sorry for the confusion.

On Mon, Dec 18, 2= 023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
=
---= > There are no specific options in u-boot devoted to=20 FreeBSD

This is an important factor. So,what = about if,instead of compiling a new version of u-boot on the partition 2,I = will recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first partition ? It could wor= k if there are no differences between the u-boot that should boot Linux and= the u-boot that should boot FreeBSD.

Can you give= a look at the u-boot source code created by virtual open systems ? You can= find it on my google drive :


I need to un= derstand if I can recompile it without problem so that it can satisfy my ne= eds (the ability of the file u-boot.bin to boot FreeBSD as domU under Xen,a= s explained by Stefano Stabellini,the xen developer that suggested to me wh= at I could do to have FreeBSD virtualized under Xen on my Arm Chromebook) ;= otherwise the risk is to find later problems that will make me troubles an= d that I will not able to fix.

I gave a look = at the virtual open system u-boot and I didn't see any arndale_de= fconfig inside. So,If I have understood correctly,I should put that file in= side the root of the u-boot source code,let's say here :

marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # l= s
= =C2=A0
.checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0README =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0net
.git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
.gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exa= mples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0rules.mk=
CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0spl
Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0too= ls

and I should do : make and make install ? and the file I need,u-boot.bi= n will be generated ?=C2=A0

I didn't find any pre made configuration f= ile inside :

u-boot-vos # find . -type f -name "exynos*"=C2=A0

./include/exynos-fb.h
./include/configs/exynos5-common.h
./doc/device-tree-bindings/spi/exynos-spi.txt
./doc/device-tree-bindings/usb/exynos-usb.txt
./drivers/power/exynos-tmu.c
./drivers/power/exynos-cpufreq.c
./drivers/video/exynos-fb.c
./drivers/spi/exynos_spi.c
./board/samsung/dts/exynos5250-spring.dts
./board/samsung/dts/exynos5250-smdk5250.dts
./board/samsung/dts/exynos5250-snow.dts
./board/samsung/dts/exynos5250-daisy.dts
./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
./arch/arm/dts/exynos5250.dtsi
./arch/arm/dts/exynos-periph-id.dtsi
./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0

u-boot-vos # find . -type f -name "a= rndale*"

For sure I can't use a newer version of u-boot because otherwise the= patches needed to bypass the bootloader protections of the Arm Chromebook = (such as a lot of different patches needed to boot correctly Linux) will be= broken ; anyway,since it works,I don't need to use an updated version = of u-boot.

----> As per= my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

<= font size=3D"4">
<= div>It says that I should use these parameters :

C= ONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

These are the parameters used to configure a Linux kernel. I don'= ;t understand what's the relation between the compilation of a linux ke= rnel and u-boot. In the past I tried to recompile u-boot,but I didn't h= ave the need to set up those parameters,so I don't know how to do it (b= ut I know how to recompile a Linux kernel).


---> I'm = not sure that I'm getting you right, as I don't understand what you= mean under "the first u-boot".


I'm talki= ng about first u-boot because the whole procedure to boot Linux on the ARM = Chromebook,that's explained here :

http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/<= /a>


at some point they say :


To be able t= o run KVM on ARM platforms, the kernel has to be booted in hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.

For the ARM Chromebook the default boot procedure doesn't allow us t= o boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

So,the first u-boot is the u-boot provided by virtual= open systems,that's able to chainload the "u-boot binary located = in RO memory" , that does not boot Chrome OS in hypervisor mode. We do= n't need it if we want to boot Linux with kvm or xen enabled.

=

On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
I'm not an expert in the topic, I only know, that ARM has div= ided hardware into two worlds - Secure and Not-So, strictly limiting any so= ftware, running in non-secure world with access to functions and resources.= =C2=A0https://devel= oper.arm.com/documentation/den0013/d/Security/TrustZone-hardware-architectu= re?lang=3Den
I'm not sure, = that I'm getting you right, as I don't understand what you mean und= er "the first u-boot".

As= I understand, virtualization (HYP) is running in non-secure world (https://developer.arm.com/documentation/ddi0406/c/System-Lev= el-Architecture/The-System-Level-Programmers--Model/The-Virtualization-Exte= nsions), so my guess (only guess!!!), virtualization software has to pr= epare (configure) HW platform in the way, that FreeBSD kernel will not lack= any resources, required to configure MPU, VA, etc.
So, if you lucky to boot virtualizer, which= is aware of target OS, that maybe you can boot the kernel. Although, I dou= bt, that you need to boot 'second' u-boot to boot the kernel - ther= e is simply ubldr, which you can hook somehow from virtualizer....

Stan

Mario Marietto wrote:


=
--->= ; As=20 I understand, it makes sure that u-boot keeps in secure mode during boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.

Can you elaborate your sentence more ? I know that the= bootloader secure mode is bypassed by the virtual open systems u-boot. Are= you saying that when the control passes to the second u-boot,it will happe= n in secure mode,so that the bypass that happened loading the first u-boot,= is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-op= en-system custom u-boot ? Is this compatible with FreeBSD ? Where can I fin= d the u-boot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM S= tanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot=C2=A0 beas= t is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that=20 option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to=20 your target armv7 32 bit=20 platform:=C2=A0https:/= /source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_= type=3Dheads#L3

As=20 for compiling the u-boot, it is a doable task, given that you understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then pass= =20 it control.

Basically, you can grab some defconfig,=20 prepared for any other Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads)=20 and adopt it somehow.

As per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during boot= =20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.

Hope, this=20 will help to progress you tasks
Stan

Ma= rio=20 Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.= =20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And= =20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= =20 work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need= =20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of= =20 the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ c= d=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with= =20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the= =20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/dist= files/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point= =20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_= uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW&quo= t; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I= =20 can recompile u-boot for FreeBSD ?=20 thanks.
=

--
Mario.
=20 =20 =20
=20 =20


--
Mario.
=20 =20 =20

--
Mario.


--
Mario.


--
Mario.
--000000000000062155060cde8899-- From nobody Tue Dec 19 17:07:40 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Svjnf2XZRz54Z6r for ; Tue, 19 Dec 2023 17:08:22 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Svjnc0HCpz3CjQ for ; Tue, 19 Dec 2023 17:08:20 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XgaNmglk; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a2685675b6eso73992766b.1 for ; Tue, 19 Dec 2023 09:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703005698; x=1703610498; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XAYgT2jNeVpzPjD39EIIMgS97rrRHtBAJD704cGdbq0=; b=XgaNmglkGD+hs+4LbiJ4pfS6TkKl+Z2h7MIz0ptug6lHz5/pHEFWZ8JTqSfSXUQJKQ HHs6PbqGwC+bQPzHWuRstNpJMiwaGvmY754qhz1vZmIyG9VGD8DGHcI6CQa3hQAYF35J 99V6K9lOnNN0t4VBS8V1UbG/Me224IBavP/FiGCsWkJKMKAVQTJVkYX3sNTkcsDg7qY4 WuPoRpeGlWvjxnlp5AzgpZmCa1S8sjqqDL26U86yK13NTRxCZoNlKQgeSVUpkb2JD+MX OA8YOoauZkoiQIaJXWQU9zYqmlwUIzpP/v2O5hCwq9I74iu/2Lua4YnbiPgLddsRZ8qB BfHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703005698; x=1703610498; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XAYgT2jNeVpzPjD39EIIMgS97rrRHtBAJD704cGdbq0=; b=cX2G2xmFekZtquZo47Ja2BPbh9yoJOF25okFiH1fq7xH+BOwtVgzRFTeg4kb/DJldf 4WfeBDefHqDauUFPYozQrDTexjMyxfoxjz9+tLHguJmjm6XcCxguFhDICTCA36L5Ktgp Rv25uit91Gp0j2pHqbQ/QTn3c0l/ZWjTQTLSsBSmM+8ous7BjewmddWCZYSZJYMjfNwp pAKieV5AD3+pFN1YG+xxEEB79sSlRvWmGB2Mo5NGcyUwbPnpB8OaK8unD51Lm5hncKSr JDC2DezUNUDmjkFHXvjmOItsHZ0LWkfTy2yr6kATChVF7elA5WU4fkusSwQxRZK1QxNS ExpQ== X-Gm-Message-State: AOJu0YwnJslt+YVPRidDpg3KWHaE/D90jYPdsnavc/DrjwbbRr53OaXd 7q3QCxVzFmmgef+Pgpmi1/x8Wsecxpj9f+EpKDQ= X-Google-Smtp-Source: AGHT+IF+zm7XepDWGiGAiueHx9EHODiFv9vuxWPM2PmTRkHWk7kWNVh6/lO4T4uE1TMMVJWpPKW7IkEeUleYZD6Enj0= X-Received: by 2002:a17:906:7247:b0:a23:5fa8:6ec1 with SMTP id n7-20020a170906724700b00a235fa86ec1mr1250003ejk.19.1703005697401; Tue, 19 Dec 2023 09:08:17 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Tue, 19 Dec 2023 18:07:40 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki , Stefano Stabellini Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a4e847060cdfe9f8" X-Spamd-Result: default: False [-2.96 / 15.00]; URI_COUNT_ODD(1.00)[69]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.964]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Svjnc0HCpz3CjQ X-Spamd-Bar: -- --000000000000a4e847060cdfe9f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ....I see that some other interesting files have been produced by u-boot when I have compiled it : u-boot u-boot.lds u-boot.bin u-boot.map u-boot-nodtb.bin u-boot.dtb u-boot.srec u-boot-dtb.bin u-boot.sym So,maybe I should use a different u-boot* file for booting FreeBSD ? On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto wrote: > Hello to everyone. > > I have compiled the needed u-boot.bin from scratch using this procedure : > > # git clone https://github.com/u-boot/u-boot.git > # cd u-boot > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig : t= his > line generates the file .config > # nano .config and I've added these parameters : > > CONFIG_ARMV7_NONSEC=3Dn > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > the uboot-bin file is generated with this command : > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make > > At this point,I took a look inside the .config file and I saw that the > parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some reason,= it > is not accepted and this could be a problem.... > > These are the xen config files that I've used : > > nano freebsd.cfg > > name=3D"test" > kernel=3D"u-boot.bin" > extra =3D "console=3Dhvc0" > memory=3D256 > vcpus=3D1 > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > nano start-freebsd > > xl create freebsd.cfg > xl console freebsd > > This is what happens when I launch the vm : > > # ./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 1:cannot > (re-)build domain: -3 > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > 1:Non-existent domain > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unabl= e > to destroy guest > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction > of domain failed > freebsd is an invalid domain identifier (rc=3D-6) > > > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto > wrote: > >> So,ok,I should have said "the second u-boot" ; since the first u-boot >> binary is the "u-boot binary located in the RO memory" of the Chromebook= ". >> Sorry for the confusion. >> >> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto >> wrote: >> >>> ---> There are no specific options in u-boot devoted to FreeBSD >>> >>> This is an important factor. So,what about if,instead of compiling a ne= w >>> version of u-boot on the partition 2,I will recompile the u-boot custom= ized >>> version created by the virtual open system in 2014,that should be insta= lled >>> on the first partition ? It could work if there are no differences betw= een >>> the u-boot that should boot Linux and the u-boot that should boot FreeB= SD. >>> >>> Can you give a look at the u-boot source code created by virtual open >>> systems ? You can find it on my google drive : >>> >>> >>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?= usp=3Dsharing >>> >>> I need to understand if I can recompile it without problem so that it >>> can satisfy my needs (the ability of the file u-boot.bin to boot FreeBS= D as >>> domU under Xen,as explained by Stefano Stabellini,the xen developer tha= t >>> suggested to me what I could do to have FreeBSD virtualized under Xen o= n my >>> Arm Chromebook) ; otherwise the risk is to find later problems that wil= l >>> make me troubles and that I will not able to fix. >>> >>> I gave a look at the virtual open system u-boot and I didn't see any ar= ndale_defconfig >>> inside. So,If I have understood correctly,I should put that file inside= the >>> root of the u-boot source code,let's say here : >>> >>> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>> >>> .checkpatch.conf README doc >>> net >>> .git api drivers >>> onenand_ipl >>> .gitignore arch dts >>> post >>> COPYING board examples >>> rules.mk >>> CREDITS boards.cfg fs >>> scripts >>> MAINTAINERS common include >>> snapshot.commit >>> MAKEALL config.mk lib >>> spl >>> Makefile cros mkconfig >>> test >>> PRESUBMIT.cfg disk nand_spl >>> tools >>> >>> and I should do : make and make install ? and the file I need,u-boot.bi= n >>> will be generated ? >>> >>> I didn't find any pre made configuration file inside : >>> >>> u-boot-vos # find . -type f -name "exynos*" >>> >>> ./include/exynos-fb.h >>> ./include/configs/exynos5-common.h >>> ./doc/device-tree-bindings/spi/exynos-spi.txt >>> ./doc/device-tree-bindings/usb/exynos-usb.txt >>> ./drivers/power/exynos-tmu.c >>> ./drivers/power/exynos-cpufreq.c >>> ./drivers/video/exynos-fb.c >>> ./drivers/spi/exynos_spi.c >>> ./board/samsung/dts/exynos5250-spring.dts >>> ./board/samsung/dts/exynos5250-smdk5250.dts >>> ./board/samsung/dts/exynos5250-snow.dts >>> ./board/samsung/dts/exynos5250-daisy.dts >>> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>> ./arch/arm/dts/exynos5250.dtsi >>> ./arch/arm/dts/exynos-periph-id.dtsi >>> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>> >>> u-boot-vos # find . -type f -name "arndale*" >>> >>> For sure I can't use a newer version of u-boot because otherwise the >>> patches needed to bypass the bootloader protections of the Arm Chromebo= ok >>> (such as a lot of different patches needed to boot correctly Linux) wil= l be >>> broken ; anyway,since it works,I don't need to use an updated version o= f >>> u-boot. >>> >>> ----> As per my experience, you have to respect these two options, >>> compiling u-boot for FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> >>> It says that I should use these parameters : >>> >>> CONFIG_ARMV7_NONSEC=3Dn >>> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> >>> These are the parameters used to configure a Linux kernel. I don't >>> understand what's the relation between the compilation of a linux kerne= l >>> and u-boot. In the past I tried to recompile u-boot,but I didn't have t= he >>> need to set up those parameters,so I don't know how to do it (but I kno= w >>> how to recompile a Linux kernel). >>> >>> >>> ---> I'm not sure that I'm getting you right, as I don't understand wha= t >>> you mean under "the first u-boot". >>> >>> >>> I'm talking about first u-boot because the whole procedure to boot Linu= x >>> on the ARM Chromebook,that's explained here : >>> >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / >>> >>> >>> at some point they say : >>> >>> >>> To be able to run KVM on ARM platforms, the kernel has to be booted in >>> hypervisor mode. Because of this relatively recent requirement (due to = the >>> introduction of the virtualization extensions), up until now all bootin= g >>> methods would boot the kernel in the standard Supervisor mode. >>> >>> For the ARM Chromebook the default boot procedure doesn't allow us to >>> boot in hypervisor mode. Although the laptop's boot mechanism is based = on >>> the frequently used u-boot, the binary is located in RO memory. >>> Fortunately, a chained u-boot mechanism can be used (i.e. starting anot= her >>> u-boot after the original). We can then enter hypervisor mode from our >>> custom iteration of u-boot and subsequently load our kernel and userspa= ce. >>> >>> So,the first u-boot is the u-boot provided by virtual open >>> systems,that's able to chainload the "u-boot binary located in RO memor= y" , >>> that does not boot Chrome OS in hypervisor mode. We don't need it if we >>> want to boot Linux with kvm or xen enabled. >>> >>> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> >>>> I'm not an expert in the topic, I only know, that ARM has divided >>>> hardware into two worlds - Secure and Not-So, strictly limiting any >>>> software, running in non-secure world with access to functions and >>>> resources. >>>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-h= ardware-architecture?lang=3Den >>>> >>>> I'm not sure, that I'm getting you right, as I don't understand what >>>> you mean under "the first u-boot". >>>> >>>> As I understand, virtualization (HYP) is running in non-secure world ( >>>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Archite= cture/The-System-Level-Programmers--Model/The-Virtualization-Extensions), >>>> so my guess (only guess!!!), virtualization software has to prepare >>>> (configure) HW platform in the way, that FreeBSD kernel will not lack = any >>>> resources, required to configure MPU, VA, etc. >>>> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t >>>> maybe you can boot the kernel. Although, I doubt, that you need to boo= t >>>> 'second' u-boot to boot the kernel - there is simply ubldr, which you = can >>>> hook somehow from virtualizer.... >>>> >>>> Stan >>>> >>>> >>>> >>>> Mario Marietto wrote: >>>> >>>> >>>> ---> As I understand, it makes sure that u-boot keeps in secure mode >>>> during boot and passes control to ubldr, which boots FreeBSD kernel, i= n >>>> that mode. >>>> >>>> Can you elaborate your sentence more ? I know that the bootloader >>>> secure mode is bypassed by the virtual open systems u-boot. Are you sa= ying >>>> that when the control passes to the second u-boot,it will happen in se= cure >>>> mode,so that the bypass that happened loading the first u-boot,is annu= lled >>>> ? If this is true,maybe can I boot FreeBSD using the virtual-open-syst= em >>>> custom u-boot ? Is this compatible with FreeBSD ? Where can I find the >>>> u-boot.bin that the xen developer talked about ? thanks bro'. >>>> >>>> >>>> >>>> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>>> stanislav.silnicki@mailgate.us> wrote: >>>> >>>>> Hi Mario, >>>>> >>>>> U-Boot beast is hiding in this den: >>>>> https://source.denx.de/u-boot/u-boot.git >>>>> I took a brief look at your post and it seems to me, that option >>>>> CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit >>>>> platform: >>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8= /Kconfig?ref_type=3Dheads#L3 >>>>> >>>>> As for compiling the u-boot, it is a doable task, given that you >>>>> understand what you are doing. There are no specific options in u-boo= t >>>>> devoted to FreeBSD. It is a boot loader, whose mission to make basic >>>>> hardware initialization, read you kernel file from some media into RA= M and >>>>> then pass it control. >>>>> >>>>> Basically, you can grab some defconfig, prepared for any other >>>>> Exynos5250 based board (say, this one: >>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_de= fconfig?ref_type=3Dheads) >>>>> and adopt it somehow. >>>>> >>>>> As per my experience, you have to respect these two options, compilin= g >>>>> u-boot for FreeBSD: >>>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-ma= ster/files/FreeBSD_Fragment >>>>> >>>>> As I understand, it makes sure, that u-boot keeps in secure mode >>>>> during boot and passes control to ubldr, which boots FreBSD kernel, i= n that >>>>> mode. Otherwise, there a lot of surprises you may realize. >>>>> >>>>> Hope, this will help to progress you tasks >>>>> Stan >>>>> >>>>> Mario Marietto wrote: >>>>> >>>>> >>>>> Hello. >>>>> >>>>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook= . >>>>> Basically there are two ways to accomplish this task : >>>>> >>>>> 1) to write a patch that allows the FreeBSD kernel to boot as a zImag= e >>>>> file. This could be accomplished applying this patch to a specific fi= le >>>>> that's on the source code of FreeBSD : >>>>> >>>>> >>>>> >>>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717= 035f986c979edef0c9 >>>>> >>>>> >>>>> >>>>> This patch was written by Julien Grall a lot of time ago and now it >>>>> does not work anymore. This is the reason : >>>>> >>>>> >>>>> It appears FreeBSD-CURRENT removed the last step converting the kerne= l >>>>> 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. >>>>> And I'm not able to fix it. >>>>> >>>>> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer= : >>>>> >>>>> >>>>> I was trying to explain why and how Julien's patch works so that you >>>>> could be the one to re-do something similar or fix the patch on the F= reeBSD >>>>> kernel that you are working with. I am happy to help review and write >>>>> patches but I don't work with the FreeBSD kernel so I wouldn't be abl= e to >>>>> help you quickly. However, I might have a suggestion. Do you know if >>>>> FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as = Xen on >>>>> ARM guest firmware/bootloader. You should be able to build U-Boot and= use >>>>> the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBSD= from >>>>> disk or network and start it. For instance as domU config file: >>>>> >>>>> kernel=3D"/home/petalinux/u-boot.bin" >>>>> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>>> >>>>> I know it is important to build u-boot with the following config to >>>>> make it work on Xen. >>>>> >>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> >>>>> >>>>> >>>>> This option seems more doable to me according to my knowledge. But I >>>>> need to understand how to do it. >>>>> >>>>> Well,let's say that on the ARM Chromebook I'm forced to use and >>>>> install a customized version of u-boot,created by virtual open >>>>> systems,because it is the only one that allows bypassing its bootload= er >>>>> protection. You can find more information here : >>>>> >>>>> >>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebo= ok/?vos=3Dtech >>>>> >>>>> This is the relevant section to read : >>>>> >>>>> >>>>> Bootloader : >>>>> >>>>> If you wish to skip this chapter you can download a pre-compiled >>>>> binary of the bootloader: >>>>> >>>>> >>>>> $ wget >>>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/= nv_u-boot-snow.kpart >>>>> >>>>> >>>>> To be able to run KVM on ARM platforms, the kernel has to be booted i= n >>>>> hypervisor mode. Because of this relatively recent requirement (due t= o the >>>>> introduction of the virtualization extensions), up until now all boot= ing >>>>> methods would boot the kernel in the standard Supervisor mode. For th= e ARM >>>>> Chromebook the default boot procedure doesn't allow us to boot in >>>>> hypervisor mode. Although the laptop's boot mechanism is based on the >>>>> frequently used u-boot, the binary is located in RO memory. Fortunate= ly, a >>>>> chained u-boot mechanism can be used (i.e. starting another u-boot af= ter >>>>> the original). We can then enter hypervisor mode from our custom iter= ation >>>>> of u-boot and subsequently load our kernel and userspace. >>>>> >>>>> Checkout the needed u-boot code : >>>>> >>>>> >>>>> $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>>>> u-boot$ ./scripts/build.sh >>>>> >>>>> >>>>> If successful, a message about how to copy the bootloader on the USB >>>>> flash disk or SD card will appear. We will use it later when preparin= g the >>>>> boot medium to start our system. If you have followed the Setting up = the >>>>> boot medium chapter and you have a prepared boot device, then you can >>>>> update u-boot by running : >>>>> >>>>> >>>>> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>>> >>>>> >>>>> >>>>> so,the needed u-boot that we must use should be installed on the firs= t >>>>> partition of the sd card. >>>>> >>>>> There is another relevant section to read : >>>>> >>>>> >>>>> Setting up the boot medium >>>>> >>>>> Now it is time to copy all the relevant files that we created in the >>>>> previous chapters,and use them to boot Chromebook with a different ke= rnel >>>>> and OS. In all these examples the device /dev/sdX is used. Take extra= care >>>>> to change the examples to the device that you have attached. Insert t= he >>>>> boot medium on your workstation and carefully execute the following s= tep. >>>>> First we need to properly format the boot medium. >>>>> >>>>> In the uboot source directory : >>>>> >>>>> >>>>> $ sudo ./scripts/sdcard.sh /dev/sdX >>>>> >>>>> >>>>> This will erase all data and create 4 partitions in the medium, along >>>>> with copying the u-boot binary to the first partition: >>>>> >>>>> >>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>> Partition 2 =3D not used >>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>> exynos5250-snow.dtb) >>>>> Partition 4 =3D EXT4 partition for userspace files >>>>> >>>>> >>>>> With u-boot being copied, next is the kernel image and DTB file. From >>>>> the kernel source execute : >>>>> >>>>> >>>>> $ mkdir ../mnt/ >>>>> $ sudo mount /dev/sdX3 ../mnt/ >>>>> $ sudo cp arch/arm/boot/uImage ../mnt/ >>>>> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>>> $ sudo umount /dev/sdX3 >>>>> >>>>> >>>>> Finally, we have to copy the Ubuntu userspace filesystem that we >>>>> created earlier: >>>>> >>>>> >>>>> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount >>>>> /dev/sdX4 >>>>> >>>>> >>>>> >>>>> Now,my idea is to chainload the already chain loaded u-boot created b= y >>>>> V.O.S to the new u-boot that we need for booting FreeBSD and that can= be >>>>> installed in the partition n.2,as shown in this scheme,because it is = not >>>>> used : >>>>> >>>>> >>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>>>> bit,compatible with FreeBSD on this partition) >>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>> exynos5250-snow.dtb) >>>>> Partition 4 =3D EXT4 partition for userspace files >>>>> >>>>> >>>>> Take in consideration that default boot string is hardcoded here,in >>>>> the snow.h file of the custom u-boot created by VOS : >>>>> >>>>> >>>>> >>>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/confi= gs/snow.h#L101 >>>>> >>>>> >>>>> >>>>> and it needs to be recompiled because it should point to the partitio= n >>>>> n.2,where I will install the u-boot files as explained here : >>>>> >>>>> >>>>> https://wiki.freebsd.org/arm/Chromebook >>>>> >>>>> >>>>> I have some questions to ask before I start working on this. >>>>> >>>>> 1) The xen developer said : >>>>> >>>>> >>>>> You should be able to build U-Boot and use the U-Boot binary as Xen >>>>> guest kernel... >>>>> >>>>> >>>>> >>>>> where is the u-boot binary,according to this document ? >>>>> >>>>> https://wiki.freebsd.org/arm/Chromebook >>>>> >>>>> I don't see it. >>>>> >>>>> >>>>> 2) where is the source code of the file that I can get here : >>>>> >>>>> >>>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfile= s/nv_uboot-snow-simplefb.kpart.bz2 >>>>> >>>>> I need the source code if I want to recompile u-boot so that it can >>>>> point to the partition 4. >>>>> >>>>> Maybe it can be found on this link : >>>>> >>>>> http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>>> >>>>> but it can't be opened.... >>>>> >>>>> >>>>> 3) in this specific scenario the source code of u-boot should run on >>>>> arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW"= model >>>>> XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= A15) >>>>> Soc. >>>>> >>>>> >>>>> 4) I'm not sure if I can chainload the customized u-boot created by >>>>> V.O.S that should be installed on the first partition with the u-boot >>>>> tailored for booting FreeBSD that should be installed on the partitio= n 2.... >>>>> >>>>> >>>>> 5) the xen developer said that u-boot should be compiled enabling thi= s >>>>> option : >>>>> >>>>> >>>>> Code: >>>>> >>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> >>>>> >>>>> >>>>> Well,can you provide some good source that can help me to understand >>>>> how I can recompile u-boot for FreeBSD ? thanks. >>>>> >>>>> -- >>>>> Mario. >>>>> >>>>> >>>> >>>> -- >>>> Mario. >>>> >>>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --000000000000a4e847060cdfe9f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
..= ..I see that some other interesting files have been produced by u-boot when= I have compiled it :

u-boot
u-boot.lds
u-boot.bin
= u-boot.map
u-bo= ot-nodtb.bin
u-boot.dtb
u-boot.srec=
u-boot-dtb.bin
= u-boot.sym

So,maybe I sho= uld use a different u-boot* file for booting FreeBSD ?


=
On Tue, Dec 19, 2023 at 4:28=E2=80=AF= PM Mario Marietto <marietto200= 8@gmail.com> wrote:
Hello to everyone.
<= div>
I have compiled the needed u-boot.bin from scratch using= this procedure :

# cd u-boot
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make <= /span>snow_defconfig : this line generates the file .config
# nano .config and I've= added these parameters :

CONFIG= _ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

the uboot-bin file is generated with this command :

<= div># ARCH=3Darm CROSS_COMPILE=3Darm-linux-gn= ueabihf- make

At this point,I took a look inside the .config file and I saw that the=20 parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some= =20 reason,it is not accepted and this could be a problem....
These are the xen config files that I've used :

nano freebsd.cfg

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

nano start-freebsd

xl create freebsd.cfg
xl console freebsd

This is what happens when I launch the vm :

# ./start-freebsd
=C2=A0
Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader foun= d: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain= 1:cannot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc=3D-6)
<= br>

On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario M= arietto <mar= ietto2008@gmail.com> wrote:
So,ok,I should have said "the seco= nd u-boot" ; since the first u-boot binary is the "u-boot binary = located in the RO memory" of the Chromebook". Sorry for the confu= sion.

On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.co= m> wrote:
---> There are no specific options in u-boot devo= ted to=20 FreeBSD

This is an important factor. So,what = about if,instead of compiling a new version of u-boot on the partition 2,I = will recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first partition ? It could wor= k if there are no differences between the u-boot that should boot Linux and= the u-boot that should boot FreeBSD.

Can you give= a look at the u-boot source code created by virtual open systems ? You can= find it on my google drive :


I need to un= derstand if I can recompile it without problem so that it can satisfy my ne= eds (the ability of the file u-boot.bin to boot FreeBSD as domU under Xen,a= s explained by Stefano Stabellini,the xen developer that suggested to me wh= at I could do to have FreeBSD virtualized under Xen on my Arm Chromebook) ;= otherwise the risk is to find later problems that will make me troubles an= d that I will not able to fix.

I gave a look = at the virtual open system u-boot and I didn't see any arndale_de= fconfig inside. So,If I have understood correctly,I should put that file in= side the root of the u-boot source code,let's say here :

marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # l= s
= =C2=A0
.checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0README =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0net
.git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
.gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exa= mples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0rules.mk=
CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0spl
Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0too= ls

and I should do : make and make install ? and the file I need,u-boot.bi= n will be generated ?=C2=A0

I didn't find any pre made configuration f= ile inside :

u-boot-vos # find . -type f -name "exynos*"=C2=A0

./include/exynos-fb.h
./include/configs/exynos5-common.h
./doc/device-tree-bindings/spi/exynos-spi.txt
./doc/device-tree-bindings/usb/exynos-usb.txt
./drivers/power/exynos-tmu.c
./drivers/power/exynos-cpufreq.c
./drivers/video/exynos-fb.c
./drivers/spi/exynos_spi.c
./board/samsung/dts/exynos5250-spring.dts
./board/samsung/dts/exynos5250-smdk5250.dts
./board/samsung/dts/exynos5250-snow.dts
./board/samsung/dts/exynos5250-daisy.dts
./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
./arch/arm/dts/exynos5250.dtsi
./arch/arm/dts/exynos-periph-id.dtsi
./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0

u-boot-vos # find . -type f -name "a= rndale*"

For sure I can't use a newer version of u-boot because otherwise the= patches needed to bypass the bootloader protections of the Arm Chromebook = (such as a lot of different patches needed to boot correctly Linux) will be= broken ; anyway,since it works,I don't need to use an updated version = of u-boot.

----> As per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

<= font size=3D"4">
<= div>It says that I should use these parameters :

C= ONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

These are the parameters used to configure a Linux kernel. I don'= ;t understand what's the relation between the compilation of a linux ke= rnel and u-boot. In the past I tried to recompile u-boot,but I didn't h= ave the need to set up those parameters,so I don't know how to do it (b= ut I know how to recompile a Linux kernel).


---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".

I'm talking about first u-boot because the whole procedure to b= oot Linux on the ARM Chromebook,that's explained here :

http://www.virtualopensystems.com/en/solutions/guide= s/kvm-on-chromebook/


at some point they say :

To be able to run KVM on ARM platforms, the kernel has to be boote= d in hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.

For the ARM Chromebook the default boot procedure doesn't allow us t= o boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

So,the first u-boot is the u-boot provided by virtual= open systems,that's able to chainload the "u-boot binary located = in RO memory" , that does not boot Chrome OS in hypervisor mode. We do= n't need it if we want to boot Linux with kvm or xen enabled.

=

On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
I'm not an expert in the topic, I only kn= ow, that ARM has divided hardware into two worlds - Secure and Not-So, stri= ctly limiting any software, running in non-secure world with access to func= tions and resources.=C2=A0https://developer.arm.com/documentation/den0013/d/Security/TrustZone= -hardware-architecture?lang=3Den

I'm not sure, that I'm = getting you right, as I don't understand what you mean under "the = first u-boot".

As I understand, virtualization (HYP) is running= in non-secure world (https://developer.arm.com/docum= entation/ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--= Model/The-Virtualization-Extensions), so my guess (only guess!!!), virt= ualization software has to prepare (configure) HW platform in the way, that= FreeBSD kernel will not lack any resources, required to configure MPU, VA,= etc.
So, if you lucky to boot virtualizer, which is aware of target OS, t= hat maybe you can boot the kernel. Although, I doubt, that you need to boot= 'second' u-boot to boot the kernel - there is simply ubldr, which = you can hook somehow from virtualizer....

Stan


Mario Marietto wrote:


---> As=20 I understand, it makes sure that u-boot keeps in secure mode during boot=20 and passes control to ubldr, which boots FreeBSD kernel, in that mode.

Can you elaborate your sentence more ? I know that the= bootloader secure mode is bypassed by the virtual open systems u-boot. Are= you saying that when the control passes to the second u-boot,it will happe= n in secure mode,so that the bypass that happened loading the first u-boot,= is annulled ? If this is true,maybe can I boot FreeBSD using the virtual-op= en-system custom u-boot ? Is this compatible with FreeBSD ? Where can I fin= d the u-boot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM S= tanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
=20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
Hi=20 Mario,

U-Boot=C2=A0 beas= t is=20 hiding in this den: https://source.denx.de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that=20 option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to=20 your target armv7 32 bit=20 platform:=C2=A0https:/= /source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_= type=3Dheads#L3

As=20 for compiling the u-boot, it is a doable task, given that you understand=20 what you are doing. There are no specific options in u-boot devoted to=20 FreeBSD. It is a boot loader, whose mission to make basic hardware=20 initialization, read you kernel file from some media into RAM and then pass= =20 it control.

Basically, yo= u can grab some defconfig,=20 prepared for any other Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads)=20 and adopt it somehow.

As = per my experience, you have to respect=20 these two options, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blo= b/main/sysutils/u-boot-master/files/FreeBSD_Fragment

As=20 I understand, it makes sure, that u-boot keeps in secure mode during boot= =20 and passes control to ubldr, which boots FreBSD kernel, in that mode.=20 Otherwise, there a lot of surprises you may realize.
=
Hope, this=20 will help to progress you tasks
Stan

Mario=20 Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook.= =20 Basically there are two ways to accomplish this task :

1) to write a patch that allows the FreeBSD kernel to boot as a zImage=20 file. This could be accomplished applying this patch to a specific file=20 that's on the source code of FreeBSD :


https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of time ago and now it does=20 not work anymore. This is the reason :


=09
=09
It appears FreeBSD-CURRENT removed the last step converting the=20 kernel file to kernel.bin. The patch can be readily rebased, but without kernel.bin that doesn't do too much.
=09


So,without a rebase of that patch the first option is not applicable. And= =20 I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me by a xen developer :


=09
=09
I was trying to explain why and how Julien's patch works so that you= =20 could be the one to re-do something similar or fix the patch on the=20 FreeBSD kernel that you are working with. I am happy to help review and=20 write patches but I don't work with the FreeBSD kernel so I wouldn'= t be=20 able to help you quickly. However, I might have a suggestion. Do you=20 know if FreeBSD can be booted by U-Boot ? Because U-Boot definitely=20 boots as Xen on ARM guest firmware/bootloader. You should be able to=20 build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot=20 could load FreeBSD from disk or network and start it. For instance as=20 domU config file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xvda' ]

I know it is important to build u-boot with the following config to make it= =20 work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy
=09


This option seems more doable to me according to my knowledge. But I need= =20 to understand how to do it.

Well,let's say that on the ARM Chromebook I'm forced to use and ins= tall a customized version of u-boot,created by virtual open systems,because it is the only one that allows bypassing its bootloader protection. You=20 can find more information here :

http:/= /www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dte= ch

This is the relevant section to read :


=09
=09
Bootloader :

If you wish to skip this chapter you can download a pre-compiled binary of= =20 the bootloader:


$ wget http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the kernel has to be booted in=20 hypervisor mode. Because of this relatively recent requirement (due to=20 the introduction of the virtualization extensions), up until now all=20 booting methods would boot the kernel in the standard Supervisor mode.=20 For the ARM Chromebook the default boot procedure doesn't allow us to= =20 boot in hypervisor mode. Although the laptop's boot mechanism is based= =20 on the frequently used u-boot, the binary is located in RO memory.=20 Fortunately, a chained u-boot mechanism can be used (i.e. starting=20 another u-boot after the original). We can then enter hypervisor mode=20 from our custom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ c= d=20 u-boot$ ./scripts/build.sh


If successful, a message about how to copy the bootloader on the USB=20 flash disk or SD card will appear. We will use it later when preparing=20 the boot medium to start our system. If you have followed the Setting up the boot medium chapter and you have a prepared boot device, then you=20 can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1
=09


so,the needed u-boot that we must use should be installed on the first=20 partition of the sd card.

There is another relevant section to read :


=09
=09
Setting up the boot medium

Now it is time to copy all the relevant files that we created in the=20 previous chapters,and use them to boot Chromebook with a different=20 kernel and OS. In all these examples the device /dev/sdX is used. Take=20 extra care to change the examples to the device that you have attached.=20 Insert the boot medium on your workstation and carefully execute the=20 following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partitions in the medium, along with= =20 copying the u-boot binary to the first partition:


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


With u-boot being copied, next is the kernel image and DTB file. From the= =20 kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace filesystem that we created=20 earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umount=20 /dev/sdX4
=09


Now,my idea is to chainload the already chain loaded u-boot created by=20 V.O.S to the new u-boot that we need for booting FreeBSD and that can be installed in the partition n.2,as shown in this scheme,because it is=20 not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
Partition 2 =3D not used (maybe we can install the u-boot for arm 32=20 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (uImage and=20 exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is hardcoded here,in the=20 snow.h file of the custom u-boot created by VOS :


https://github.com/virtualopensyste...18a39b6c= 177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should point to the partition=20 n.2,where I will install the u-boot files as explained here :


https://wiki.freebsd.org/arm/Chromebook


I have some questions to ask before I start working on this.

1) The xen developer said :


=09
=09
You should be able to build U-Boot and use the U-Boot binary as Xen=20 guest kernel...
=09


where is the u-boot binary,according to this document ?

https://wiki.freebsd.org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can get here :

http://commondatastorage.googleapis.com/chromeos-localmirror/dist= files/nv_uboot-snow-simplefb.kpart.bz2

I need the source code if I want to recompile u-boot so that it can point= =20 to the partition 4.

Maybe it can be found on this link :

http://linux-exynos.org/dist/chromebook/nv_= uboot/

but it can't be opened....


3) in this specific scenario the source code of u-boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW&quo= t; model XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex= =20 A15) Soc.


4) I'm not sure if I can chainload the customized u-boot created by=20 V.O.S that should be installed on the first partition with the u-boot=20 tailored for booting FreeBSD that should be installed on the partition=20 2....


5) the xen developer said that u-boot should be compiled enabling this=20 option :


=09 =09
Code: 

CONFIG_CMO_BY_VA_ONLY=3Dy


Well,can you provide some good source that can help me to understand how I= =20 can recompile u-boot for FreeBSD ?=20 thanks.

<= /div>
--
Mario.
=20 =20 =20
=20 =20


--
Mario.
=20 =20 =20

--
Mario.


--
Mario.


--
Mario.


--
Mario.
--000000000000a4e847060cdfe9f8-- From nobody Tue Dec 19 17:22:03 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Svk5X2Vw9z54bGJ for ; Tue, 19 Dec 2023 17:22:08 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Svk5W1LJVz3TgZ for ; Tue, 19 Dec 2023 17:22:06 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de; dmarc=none Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BJHM1JY051491; Tue, 19 Dec 2023 18:22:01 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from [10.100.100.54] (unknown [217.110.88.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id C5FEE64A; Tue, 19 Dec 2023 18:22:01 +0100 (CET) Message-ID: Date: Tue, 19 Dec 2023 18:22:03 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images Content-Language: en-US To: "Fred G. Finster" , freebsd-arm@freebsd.org Cc: "fredfinster58@gmail.com" References: <43691d67-3d00-e8d5-f917-fbb2963454cc@thegalacticzoo.com> From: Harry In-Reply-To: <43691d67-3d00-e8d5-f917-fbb2963454cc@thegalacticzoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.27 / 15.00]; URL_IN_SUBJECT(1.00)[personalbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_NA(0.00)[omnilan.de]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Svk5W1LJVz3TgZ X-Spamd-Bar: -- On 12/16/23 04:30, Fred G. Finster wrote: >> ... > Hary,  I can see you are testing and setting up a build environment > for the Nano Pi R5C SBC.   Look at Sleep Walkers work over at > https://personalBSD.org   and Telegram Group t.me/personalbsd > > https://personalbsd.org/images/FreeBSD-aarch64-14.0-CURRENT-NanoPi-R5C-20230522.img.xz > > Hello Fred, thanks, I stumbled across this resource before purchasing R5C, which I considered as my insurance for having an easy onboarding, I thought - the download is 404 these days and I couldn't find a copy out there. > Give this image a test run on your hardware NanoPi r5c.   Then read > register settings and save.  See what settings and values (ie binary > blobs NOT LOADED ) exist in your kernel boot image.  Then modify your > own sources and build another new image again. > Chat with SleepWalker and maybe get a working build environment? > ExtroWerk user, was porting FreeBSD to a GeniaTech RK3566 SBC board. > https://t.me/PersonalBSD/11146  I see ExtroWerk was asking me to build > an image for him. > https://extrowerk.com/2023-10-30/Geniatech-XPI-3566-ZERO-SBC.html > https://github.com/extrowerk > > > > Yes, Harry, I want to see you successfully build a FreeBSD kernel from > source to run and execute on the NanoPi r5c single board computer.  Ie > Get all the "little ducks in a row." Stacking downloaded images in the correct order with correct offset worked - I can boot cross-compiled FreeBSD-14-aarch64 kernel+world from such a SD-card.  But the TianoCore port I found produces incorrect ACPI tables - e.g the eMMC controller is only accessible if I disable ACPI and load a DTB via loader.conf. My goal was to understand the arm-SoC boot process, at least to some degree, and having the ability to compile all the necessary blobs myself - otherwise I would need to choose a vendor who officially supports FreeBSD - which is none afaik, meaning I'd need to deploy a different operating system for my project. Either vendor supported or code available.  Tinkering with dubiously acquired 'images' isn't feasible for me. Is the complete u-boot port obsolete these days?  As far as I understand, there's no UEFI support and since ubldr was canceled. Is there really no way to boot FreeBSD aarch64 with self-compiled ingredients? (at least with only including the bl31_dram blob) I will have a look in src/release for the aarch64 platform, but I thought deploying the boot firmware was more straight forward - especially since there's plenty of doc's claiming that u-boot is all you need... It's hard to identify outdated docs - which is the majority, if not all I found so far... Thanks, -harry From nobody Tue Dec 19 17:45:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Svkd15pNNz54cxN for ; Tue, 19 Dec 2023 17:45:57 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Svkd117CLz4VV3 for ; Tue, 19 Dec 2023 17:45:56 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 3BJHjpel088639 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 19:45:51 +0200 (EET) (envelope-from titus@edc.ro) Received: from tituss-imac.eatlas.local (eatlas.ro [86.126.82.18]) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 3BJHjngE073175 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 19:45:50 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1703007950; bh=3lqiyxyTvJGA6bqmuNaQGmmMj2SAlxn24sKtRHWZiy8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=qrbmNvVDONCAYEuJnQw37s87P1W6BsbdBfd5Z7bJ3uIEsrLKozi7aWmQLoprDH4CY k2I8akDoifu4YmFZKCIOGRtg/e4PGhVnCqiIWOseBM8yCZxfo9BTfEPpqHmwXfJZi5 8L6PWMa4psnlwZVqO0dUyEVidK+0GVcADHjdCX9o= From: titus Message-Id: <1573661F-100C-46C6-9A75-524B1AACF1FA@edc.ro> Content-Type: multipart/alternative; boundary="Apple-Mail=_3658101A-78B0-4427-B7B5-98EC65515BC6" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images Date: Tue, 19 Dec 2023 19:45:51 +0200 In-Reply-To: Cc: freebsd-arm To: Harry References: <43691d67-3d00-e8d5-f917-fbb2963454cc@thegalacticzoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Svkd117CLz4VV3 --Apple-Mail=_3658101A-78B0-4427-B7B5-98EC65515BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii u-boot can/does provide EFI api to freebsd so you can boot an aarch64 = image if have an rk3566 board (orange pi 3b) and i run 14.x on it i just built https://github.com/Kwiboo/u-boot-rockchip = (mostly because they = provided an opi3b dtb and mainline did not) add CONFIG_EFI_LOADER=3Dy to the opi3b_defconfig, build, dd, boot (bl31 = built from source, tpl from rkbin) depending on your board / dtb / luck what works and what not may vary i have uart / sd / emmc / gmac / sata / pcie / usb / thermal / cpu freq = control / spi flash working on mine=20 but i need to patch some of the drivers and have a frankensteined dtb = between official opi3b and pine quarzt64 i have no video output, only serial you may want to take a look at = https://forums.freebsd.org/threads/running-freebsd-on-radxa-rock-3c-rk3566= -board.89389/ = =20 rk3399 is better supported than rk35xx > On Dec 19, 2023, at 7:22 PM, Harry wrote: >=20 > On 12/16/23 04:30, Fred G. Finster wrote: >>> ... >> Hary, I can see you are testing and setting up a build environment = for the Nano Pi R5C SBC. Look at Sleep Walkers work over at = https://personalBSD.org and Telegram Group t.me/personalbsd >>=20 >> = https://personalbsd.org/images/FreeBSD-aarch64-14.0-CURRENT-NanoPi-R5C-202= 30522.img.xz=20 >>=20 >=20 > Hello Fred, >=20 >=20 > thanks, I stumbled across this resource before purchasing R5C, which I = considered as my insurance for having an easy onboarding, I thought - = the download is 404 these days and I couldn't find a copy out there. >=20 >=20 >> Give this image a test run on your hardware NanoPi r5c. Then read = register settings and save. See what settings and values (ie binary = blobs NOT LOADED ) exist in your kernel boot image. Then modify your = own sources and build another new image again. >> Chat with SleepWalker and maybe get a working build environment? >> ExtroWerk user, was porting FreeBSD to a GeniaTech RK3566 SBC board. >> https://t.me/PersonalBSD/11146 I see ExtroWerk was asking me to = build an image for him. >> https://extrowerk.com/2023-10-30/Geniatech-XPI-3566-ZERO-SBC.html >> https://github.com/extrowerk >>=20 >>=20 >>=20 >> Yes, Harry, I want to see you successfully build a FreeBSD kernel = from source to run and execute on the NanoPi r5c single board computer. = Ie Get all the "little ducks in a row." >=20 >=20 > Stacking downloaded images in the correct order with correct offset = worked - I can boot cross-compiled FreeBSD-14-aarch64 kernel+world from = such a SD-card. But the TianoCore port I found produces incorrect ACPI = tables - e.g the eMMC controller is only accessible if I disable ACPI = and load a DTB via loader.conf. >=20 > My goal was to understand the arm-SoC boot process, at least to some = degree, and having the ability to compile all the necessary blobs myself = - otherwise I would need to choose a vendor who officially supports = FreeBSD - which is none afaik, meaning I'd need to deploy a different = operating system for my project. Either vendor supported or code = available. Tinkering with dubiously acquired 'images' isn't feasible = for me. >=20 > Is the complete u-boot port obsolete these days? As far as I = understand, there's no UEFI support and since ubldr was canceled. Is = there really no way to boot FreeBSD aarch64 with self-compiled = ingredients? (at least with only including the bl31_dram blob) >=20 > I will have a look in src/release for the aarch64 platform, but I = thought deploying the boot firmware was more straight forward - = especially since there's plenty of doc's claiming that u-boot is all you = need... > It's hard to identify outdated docs - which is the majority, if not = all I found so far... >=20 > Thanks, >=20 > -harry >=20 >=20 >=20 --Apple-Mail=_3658101A-78B0-4427-B7B5-98EC65515BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii u-boot can/does provide EFI api to freebsd so you can boot an = aarch64 image
if have an rk3566 board (orange pi 3b) and = i run 14.x on it
i just built https://github.com/Kwiboo/u-boot-rockchip (mostly = because they provided an opi3b dtb and mainline did not)
add CONFIG_EFI_LOADER=3Dy to the opi3b_defconfig, build, dd, = boot (bl31 built from source, tpl from rkbin)
depending on your board / dtb / luck what works and what not = may vary
i have uart / sd / emmc / gmac / sata / = pcie / usb / thermal / cpu freq control / spi flash working on = mine 
but i need to patch some of the = drivers and have a frankensteined dtb between official opi3b and pine = quarzt64
i have no video output, only serial

rk3399 is better supported than = rk35xx

On Dec 19, 2023, at 7:22 PM, Harry <freebsd@omnilan.de> = wrote:

On 12/16/23 04:30, Fred G. Finster wrote:
...
Hary,  I can see you are = testing and setting up a build environment for the Nano Pi R5C = SBC.   Look at Sleep Walkers work over at https://personalBSD.org   and Telegram Group t.me/personalbsd

https://personalbsd.org/images/FreeBSD-aarch64-14.0-CURRENT-Nan= oPi-R5C-20230522.img.xz

Hello Fred,


thanks, I stumbled across this resource before purchasing = R5C, which I considered as my insurance for having an easy onboarding, I = thought - the download is 404 these days and I couldn't find a copy out = there.


Give this image a test run on your hardware = NanoPi r5c.   Then read register settings and save.  See = what settings and values (ie binary blobs NOT LOADED ) exist in your = kernel boot image.  Then modify your own sources and build another = new image again.
Chat with SleepWalker and maybe get a = working build environment?
ExtroWerk user, was porting = FreeBSD to a GeniaTech RK3566 SBC board.
https://t.me/PersonalBSD/11146  I see ExtroWerk was = asking me to build an image for him.
https://extrowerk.com/2023-10-30/Geniatech-XPI-3566-ZERO-SBC.ht= ml
https://github.com/extrowerk



Yes, Harry, I want to see you = successfully build a FreeBSD kernel from source to run and execute on = the NanoPi r5c single board computer.  Ie Get all the "little ducks = in a row."


Stacking downloaded images in the correct order with correct = offset worked - I can boot cross-compiled FreeBSD-14-aarch64 = kernel+world from such a SD-card.  But the TianoCore port I found = produces incorrect ACPI tables - e.g the eMMC controller is only = accessible if I disable ACPI and load a DTB via loader.conf.

My goal was to understand the arm-SoC boot = process, at least to some degree, and having the ability to compile all = the necessary blobs myself - otherwise I would need to choose a vendor = who officially supports FreeBSD - which is none afaik, meaning I'd need = to deploy a different operating system for my project. Either vendor = supported or code available.  Tinkering with dubiously acquired = 'images' isn't feasible for me.

Is the = complete u-boot port obsolete these days?  As far as I understand, = there's no UEFI support and since ubldr was canceled. Is there really no = way to boot FreeBSD aarch64 with self-compiled ingredients? (at least = with only including the bl31_dram blob)

I = will have a look in src/release for the aarch64 platform, but I thought = deploying the boot firmware was more straight forward - especially since = there's plenty of doc's claiming that u-boot is all you need...
It's hard to identify outdated docs - which is the majority, = if not all I found so far...

Thanks,

-harry




= --Apple-Mail=_3658101A-78B0-4427-B7B5-98EC65515BC6-- From nobody Tue Dec 19 18:06:28 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Svl4l6x6Xz54fhh for ; Tue, 19 Dec 2023 18:06:31 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Svl4l375Yz3Wdh for ; Tue, 19 Dec 2023 18:06:31 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; none Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BJI6Rv7051724; Tue, 19 Dec 2023 19:06:27 +0100 (CET) (envelope-from freebsd@omnilan.de) X-Authentication-Warning: mx0.gentlemail.de: Host ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135] claimed to be mh0.gentlemail.de Received: from [10.100.100.54] (unknown [217.110.88.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id F40E6661; Tue, 19 Dec 2023 19:06:26 +0100 (CET) Message-ID: Date: Tue, 19 Dec 2023 19:06:28 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: u-boot-nanopi-r5c [Was: Re: 14-BETA5 panic on rk3566] https://personalbsd.org/images Content-Language: en-US To: titus Cc: freebsd-arm References: <43691d67-3d00-e8d5-f917-fbb2963454cc@thegalacticzoo.com> <1573661F-100C-46C6-9A75-524B1AACF1FA@edc.ro> From: Harry In-Reply-To: <1573661F-100C-46C6-9A75-524B1AACF1FA@edc.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Svl4l375Yz3Wdh On 12/19/23 18:45, titus wrote: > u-boot can/does provide EFI api to freebsd so you can boot an aarch64 > image > if have an rk3566 board (orange pi 3b) and i run 14.x on it > i just built https://github.com/Kwiboo/u-boot-rockchip (mostly because > they provided an opi3b dtb and mainline did not) Thanks a lot!  I'll try to reproduce... I updated the u-boot-master to 2023.10 because it includes rk3568 dts. Mysteriously other 'end-user' images downloaded for R5C also don't boot (nanopi-r5c_bookworm-1203.img.xz e.g.) while DietPi_NanoPiR5S-ARMv8-Bookworm.img.xz e.g. boots fine. I'm definitely missing some important SD layout parts... > add CONFIG_EFI_LOADER=y to the opi3b_defconfig, build, dd, boot (bl31 > built from source, tpl from rkbin)  Start of your line is an interesing hint: ./work/u-boot-2023.10/configs/nanopi-r5c-rk3568_defconfig lacks CONFIG_EFI_LOADER=y... Maybe that's all I'm missing, will try to find some time later this week to check. Thanks a lot, -harry From nobody Tue Dec 19 22:24:16 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Svrpw3QLFz558RW for ; Tue, 19 Dec 2023 22:24:56 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Svrpv33Vfz4L6r for ; Tue, 19 Dec 2023 22:24:55 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=P4tgtb+h; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a233a60f8feso397286666b.0 for ; Tue, 19 Dec 2023 14:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703024693; x=1703629493; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0eOzDCsyfuMSa6M6LrXPX8dBBvwfNWLujpYs2rzQWH4=; b=P4tgtb+hPXhJgOvvYaOdXDFWuEiTvi4mkGhoYzADFs+6WFmVtXRITuPCgbX2Ifx/9D CgNrQ+D0o8ZAYsiqcRVhRJhrgLoV0x306jqNwNqVwKP50giqDj3GocdcBH2FOPMmisYH 447eufLuE/5xi2nBZsndDS2LD1KeBcD5EAP7xAPYtUhGmCmkGakr0cF4zWFJAOM95hoX FVO6xe1EEVl2Wa2+AiF9JQ9dFJGxGwW1d8sHSZESfAYZLmpb73wRfMJ2wmZ01Vd5+CUs c5VAkJZ4HDDRx6gEGABchLm/M/VG+kGd45P1L5+cqvtOASZP1s1tgp50zNHa1OwnNoIj HQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703024693; x=1703629493; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0eOzDCsyfuMSa6M6LrXPX8dBBvwfNWLujpYs2rzQWH4=; b=pps5eDkL0FgUtWS21sY4QEju2MoqIIjmqgEKjhE4t0nRUsa1YbOtqGyOBMsYyyHeND rZSUaG8uI/U6GU1rMXpZKxGOetF81pkC1BEhLOAcPZD4J4rtxJjZZo1KPXyMLBO76pWC 0S/xMWhDhcjzR35p0HSSF973qcWdojTe01CFFg0rHphFoWkUbjOO5J/ri5WAIP/8fuGf 6nMGJ5QN628vetUcrmdbsJSuKCZl8Z9jFx8b4q3BEJp3EvSiskId3cb2mmLGdDIwQqbN d5yGgQ8gvtiL5ZgrHTwTsPrOZ4ifBBTX2EJSBFG5eyNHoMJfpmq7/KeFQl8rwCbyvZum Qo5Q== X-Gm-Message-State: AOJu0Yx6pvYGdGpznDXr29P8uaQgjTp7obro9XKQODhbMvC/wm9OphHH wL4gqZy6lawGLNd6sTl4qJx9J8toOpElkwHc2yE= X-Google-Smtp-Source: AGHT+IEUvErGAJWXxWFGKHszFTZRzmVDbF5bYa8nT2DFia8es+NuQhgNVljrkFC4ZcGfIwP4QKnAq8BzTq5krof+N70= X-Received: by 2002:a17:906:30ca:b0:a1e:997a:574f with SMTP id b10-20020a17090630ca00b00a1e997a574fmr7830411ejb.122.1703024692828; Tue, 19 Dec 2023 14:24:52 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Tue, 19 Dec 2023 23:24:16 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stefano Stabellini Cc: Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: multipart/alternative; boundary="000000000000dc1fa1060ce45558" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Svrpv33Vfz4L6r X-Spamd-Bar: --- --000000000000dc1fa1060ce45558 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've asked some help on the channel #arm on Reddit and someone replied : https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_arm32= _bit_as_domu_with/ Maybe his answer can be useful to understand why it does not work. On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini wrote: > +Michal > > Hi Mario, > > I am not sure about booting FreeBSD, but I am certain that u-boot works > fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config > file: > > name=3D"test" > kernel=3D"u-boot.bin" > extra =3D "console=3Dhvc0" > memory=3D256 > vcpus=3D1 > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > I don't know for sure if you can boot FreeBSD but you should definitely > be able to see the u-boot command line prompt. The fact that you are > getting this message: > > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: > Invalid kernel > > Means that something is not right in the u-boot configuration or u-boot > build. Michal and Artem (CCed) might know more. From what I recall, > there was nothing special required to get u-boot.bin to boot as domU > kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. > > Cheers, > > Stefano > > > On Tue, 19 Dec 2023, Mario Marietto wrote: > > ....I see that some other interesting files have been produced by u-boo= t > when I have compiled it : > > > > u-boot > > u-boot.lds > > u-boot.bin > > u-boot.map > > u-boot-nodtb.bin > > u-boot.dtb > > u-boot.srec > > u-boot-dtb.bin > > u-boot.sym > > > > So,maybe I should use a different u-boot* file for booting FreeBSD ? > > > > > > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto > wrote: > > Hello to everyone. > > > > I have compiled the needed u-boot.bin from scratch using this procedure= : > > > > # git clone https://github.com/u-boot/u-boot.git > > # cd u-boot > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig := this > line generates the file .config > > # nano .config and I've added these parameters : > > > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > > > the uboot-bin file is generated with this command : > > > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make > > > > At this point,I took a look inside the .config file and I saw that the > parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for > > some reason,it is not accepted and this could be a problem.... > > > > These are the xen config files that I've used : > > > > nano freebsd.cfg > > > > name=3D"test" > > kernel=3D"u-boot.bin" > > extra =3D "console=3Dhvc0" > > memory=3D256 > > vcpus=3D1 > > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > > > nano start-freebsd > > > > xl create freebsd.cfg > > xl console freebsd > > > > This is what happens when I launch the vm : > > > > # ./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 fail= ed > > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain > 1:cannot (re-)build domain: -3 > > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > 1:Non-existent domain > > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain > 1:Unable to destroy guest > > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain > 1:Destruction of domain failed > > freebsd is an invalid domain identifier (rc=3D-6) > > > > > > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto > wrote: > > So,ok,I should have said "the second u-boot" ; since the first > u-boot binary is the "u-boot binary located in the RO > > memory" of the Chromebook". Sorry for the confusion. > > > > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto > wrote: > > ---> There are no specific options in u-boot devoted to FreeBSD > > > > This is an important factor. So,what about if,instead of compiling a ne= w > version of u-boot on the partition 2,I will > > recompile the u-boot customized version created by the virtual open > system in 2014,that should be installed on the first > > partition ? It could work if there are no differences between the u-boo= t > that should boot Linux and the u-boot that > > should boot FreeBSD. > > > > Can you give a look at the u-boot source code created by virtual open > systems ? You can find it on my google drive : > > > > > https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?us= p=3Dsharing > > > > I need to understand if I can recompile it without problem so that it > can satisfy my needs (the ability of the file > > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano > Stabellini,the xen developer that suggested to me > > what I could do to have FreeBSD virtualized under Xen on my Arm > Chromebook) ; otherwise the risk is to find later > > problems that will make me troubles and that I will not able to fix. > > > > I gave a look at the virtual open system u-boot and I didn't see any > arndale_defconfig inside. So,If I have understood > > correctly,I should put that file inside the root of the u-boot source > code,let's say here : > > > > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > > > > .checkpatch.conf README doc > net > > .git api drivers > onenand_ipl > > .gitignore arch dts > post > > COPYING board examples > rules.mk > > CREDITS boards.cfg fs > scripts > > MAINTAINERS common include > snapshot.commit > > MAKEALL config.mk lib > spl > > Makefile cros mkconfig > test > > PRESUBMIT.cfg disk nand_spl > tools > > > > and I should do : make and make install ? and the file I need,u-boot.bi= n > will be generated ? > > > > I didn't find any pre made configuration file inside : > > > > u-boot-vos # find . -type f -name "exynos*" > > > > ./include/exynos-fb.h > > ./include/configs/exynos5-common.h > > ./doc/device-tree-bindings/spi/exynos-spi.txt > > ./doc/device-tree-bindings/usb/exynos-usb.txt > > ./drivers/power/exynos-tmu.c > > ./drivers/power/exynos-cpufreq.c > > ./drivers/video/exynos-fb.c > > ./drivers/spi/exynos_spi.c > > ./board/samsung/dts/exynos5250-spring.dts > > ./board/samsung/dts/exynos5250-smdk5250.dts > > ./board/samsung/dts/exynos5250-snow.dts > > ./board/samsung/dts/exynos5250-daisy.dts > > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h > > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h > > ./arch/arm/dts/exynos5250.dtsi > > ./arch/arm/dts/exynos-periph-id.dtsi > > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c > > > > u-boot-vos # find . -type f -name "arndale*" > > > > For sure I can't use a newer version of u-boot because otherwise the > patches needed to bypass the bootloader protections > > of the Arm Chromebook (such as a lot of different patches needed to boo= t > correctly Linux) will be broken ; anyway,since > > it works,I don't need to use an updated version of u-boot. > > > > ----> As per my experience, you have to respect these two options, > compiling u-boot for > > FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > > > It says that I should use these parameters : > > > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > > > These are the parameters used to configure a Linux kernel. I don't > understand what's the relation between the compilation > > of a linux kernel and u-boot. In the past I tried to recompile > u-boot,but I didn't have the need to set up those > > parameters,so I don't know how to do it (but I know how to recompile a > Linux kernel). > > > > ---> I'm not sure that I'm getting you right, as I don't understand wha= t > you mean under "the first u-boot". > > > > > > I'm talking about first u-boot because the whole procedure to boot Linu= x > on the ARM Chromebook,that's explained here : > > > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / > > > > > > at some point they say : > > > > > > To be able to run KVM on ARM platforms, the kernel has to be booted in > hypervisor mode. Because of this relatively recent > > requirement (due to the introduction of the virtualization extensions), > up until now all booting methods would boot the > > kernel in the standard Supervisor mode. > > > > For the ARM Chromebook the default boot procedure doesn't allow us to > boot in hypervisor mode. Although the laptop's boot > > mechanism is based on the frequently used u-boot, the binary is located > in RO memory. Fortunately, a chained u-boot > > mechanism can be used (i.e. starting another u-boot after the original)= . > We can then enter hypervisor mode from our > > custom iteration of u-boot and subsequently load our kernel and > userspace. > > > > So,the first u-boot is the u-boot provided by virtual open > systems,that's able to chainload the "u-boot binary located in > > RO memory" , that does not boot Chrome OS in hypervisor mode. We don't > need it if we want to boot Linux with kvm or xen > > enabled. > > > > > > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > > I'm not an expert in the topic, I only know, that ARM has divided > hardware into two worlds - Secure and > > Not-So, strictly limiting any software, running in non-secure > world with access to functions and > > resources. > https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hard= ware-architecture?lang=3Den > > > > I'm not sure, that I'm getting you right, as I don't understand what yo= u > mean under "the first u-boot". > > > > As I understand, virtualization (HYP) is running in non-secure world( > https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectu= re/The-System-Level-Programmers--Model/The-Virtualization-Extens > > ions), so my guess (only guess!!!), virtualization software has to > prepare (configure) HW platform in the way, > > that FreeBSD kernel will not lack any resources, required to configure > MPU, VA, etc. > > So, if you lucky to boot virtualizer, which is aware of target OS, that > maybe you can boot the kernel. Although, I > > doubt, that you need to boot 'second' u-boot to boot the kernel - there > is simply ubldr, which you can hook somehow > > from virtualizer.... > > > > Stan > > > > > > > > Mario Marietto wrote: > > > > > > ---> As I understand, it makes sure that u-boot keeps in secure > mode during boot and passes control to > > ubldr, which boots FreeBSD kernel, in that mode. > > > > Can you elaborate your sentence more ? I know that the bootloader secur= e > mode is bypassed by the virtual open > > systems u-boot. Are you saying that when the control passes to the > second u-boot,it will happen in secure > > mode,so that the bypass that happened loading the first u-boot,is > annulled ? If this is true,maybe can I boot > > FreeBSD using the virtual-open-system custom u-boot ? Is this compatibl= e > with FreeBSD ? Where can I find the > > u-boot.bin that the xen developer talked about ? thanks bro'. > > > > > > > > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > > Hi Mario, > > > > U-Boot beast is hiding in this den: > https://source.denx.de/u-boot/u-boot.git > > I took a brief look at your post and it seems to me, that > option CONFIG_CMO_BY_VA_ONLY is irrelevant to > > your target armv7 32 bit > > platform: > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kco= nfig?ref_type=3Dheads#L3 > > > > As for compiling the u-boot, it is a doable task, given that you > understand what you are doing. There > > are no specific options in u-boot devoted to FreeBSD. It is a boot > loader, whose mission to make basic > > hardware initialization, read you kernel file from some media into RAM > and then pass it control. > > > > Basically, you can grab some defconfig, prepared for any other > Exynos5250 based board (say, this one: > > > https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defcon= fig?ref_type=3Dheads) > and adopt > > it somehow. > > > > As per my experience, you have to respect these two options, compiling > u-boot for > > FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > > > As I understand, it makes sure, that u-boot keeps in secure mode during > boot and passes control to > > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot > of surprises you may realize. > > > > Hope, this will help to progress you tasks > > Stan > > > > Mario Marietto wrote: > > > > > > Hello. > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM > Chromebook. Basically there are > > two ways to accomplish this task : > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a > zImage file. This could be > > accomplished applying this patch to a specific file that's on the > source code of FreeBSD : > > > > > > > https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f= 986c979edef0c9 > > > > > > This patch was written by Julien Grall a lot of time ago and now > it does not work anymore. > > This is the reason : > > > > > > 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. > And I'm not able to fix it. > > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > > > > I was trying to explain why and how Julien's patch works so that > you could be the one > > to re-do something similar or fix the patch on the FreeBSD kernel > that you are > > working with. I am happy to help review and write patches but I > don't work with the > > FreeBSD kernel so I wouldn't be able to help you quickly. However= , > I might have a > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > Because U-Boot > > definitely boots as Xen on ARM guest firmware/bootloader. You > should be able to build > > U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot > could load FreeBSD > > from disk or network and start it. For instance as domU config > file: > > > > kernel=3D"/home/petalinux/u-boot.bin" > > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] > > > > I know it is important to build u-boot with the following config > to make it work on > > Xen. > > > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > > > > > This option seems more doable to me according to my knowledge. But I > need to understand how to do > > it. > > > > Well,let's say that on the ARM Chromebook I'm forced to use and install > a customized version of > > u-boot,created by virtual open systems,because it is the only one that > allows bypassing its > > bootloader protection. You can find more information here : > > > > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?= vos=3Dtech > > > > This is the relevant section to read : > > > > > > Bootloader : > > > > If you wish to skip this chapter you can download a pre-compiled > binary of the > > bootloader: > > > > > > $ wget > > > http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u= -boot-snow.kpart > > > > > > To be able to run KVM on ARM platforms, the kernel has to be > booted in hypervisor > > mode. Because of this relatively recent requirement (due to the > introduction of the > > virtualization extensions), up until now all booting methods woul= d > boot the kernel in > > the standard Supervisor mode. For the ARM Chromebook the default > boot procedure > > doesn't allow us to boot in hypervisor mode. Although the laptop'= s > boot mechanism is > > based on the frequently used u-boot, the binary is located in RO > memory. Fortunately, > > a chained u-boot mechanism can be used (i.e. starting another > u-boot after the > > original). We can then enter hypervisor mode from our custom > iteration of u-boot and > > subsequently load our kernel and userspace. > > > > Checkout the needed u-boot code : > > > > > > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd > u-boot$ > > ./scripts/build.sh > > > > > > If successful, a message about how to copy the bootloader on the > USB flash disk or SD > > card will appear. We will use it later when preparing the boot > medium to start our > > system. If you have followed the Setting up the boot medium > chapter and you have a > > prepared boot device, then you can update u-boot by running : > > > > > > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 > > > > > > > > so,the needed u-boot that we must use should be installed on the first > partition of the sd card. > > > > There is another relevant section to read : > > > > > > Setting up the boot medium > > > > Now it is time to copy all the relevant files that we created in > the previous > > chapters,and use them to boot Chromebook with a different kernel > and OS. In all these > > examples the device /dev/sdX is used. Take extra care to change > the examples to the > > device that you have attached. Insert the boot medium on your > workstation and > > carefully execute the following step. First we need to properly > format the boot > > medium. > > > > In the uboot source directory : > > > > > > $ sudo ./scripts/sdcard.sh /dev/sdX > > > > > > This will erase all data and create 4 partitions in the medium, > along with copying > > the u-boot binary to the first partition: > > > > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used > > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > > > > > > With u-boot being copied, next is the kernel image and DTB file. > From the kernel > > source execute : > > > > > > $ mkdir ../mnt/ > > $ sudo mount /dev/sdX3 ../mnt/ > > $ sudo cp arch/arm/boot/uImage ../mnt/ > > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ > > $ sudo umount /dev/sdX3 > > > > > > Finally, we have to copy the Ubuntu userspace filesystem that we > created earlier: > > > > > > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo > umount /dev/sdX4 > > > > > > > > Now,my idea is to chainload the already chain loaded u-boot created by > V.O.S to the new u-boot > > that we need for booting FreeBSD and that can be installed in the > partition n.2,as shown in this > > scheme,because it is not used : > > > > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 > bit,compatible with FreeBSD on > > this partition) > > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > > > > > > Take in consideration that default boot string is hardcoded here,in the > snow.h file of the custom > > u-boot created by VOS : > > > > > > > https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/s= now.h#L101 > > > > > > and it needs to be recompiled because it should point to the partition > n.2,where I will install > > the u-boot files as explained here : > > > > > > https://wiki.freebsd.org/arm/Chromebook > > > > > > I have some questions to ask before I start working on this. > > > > 1) The xen developer said : > > > > > > You should be able to build U-Boot and use the U-Boot binary as > Xen guest kernel... > > > > > > > > where is the u-boot binary,according to this document ? > > > > https://wiki.freebsd.org/arm/Chromebook > > > > I don't see it. > > > > > > 2) where is the source code of the file that I can get here : > > > > > http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv= _uboot-snow-simplefb.kpart.bz2 > > > > I need the source code if I want to recompile u-boot so that it can > point to the partition 4. > > > > Maybe it can be found on this link : > > > > http://linux-exynos.org/dist/chromebook/nv_uboot/ > > > > but it can't be opened.... > > > > > > 3) in this specific scenario the source code of u-boot should run on ar= m > 32 bit,not on arm > > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's > powered by a Samsung Exynos > > 5250 (ARMv7 32 bit Cortex A15) Soc. > > > > > > 4) I'm not sure if I can chainload the customized u-boot created by > V.O.S that should be > > installed on the first partition with the u-boot tailored for booting > FreeBSD that should be > > installed on the partition 2.... > > > > > > 5) the xen developer said that u-boot should be compiled enabling this > option : > > > > > > Code: > > > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > > > Well,can you provide some good source that can help me to understand ho= w > I can recompile u-boot > > for FreeBSD ? thanks. > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > --=20 Mario. --000000000000dc1fa1060ce45558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've asked some help on the channel #arm on Reddi= t and someone replied :


Maybe his answer can b= e useful to understand why it does not work.

On Tue, Dec 19, 2023= at 8:33=E2=80=AFPM Stefano Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/do= cumentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much= .
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.
--000000000000dc1fa1060ce45558-- From nobody Wed Dec 20 04:52:30 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sw1QM1NzFz54rLg for ; Wed, 20 Dec 2023 04:52:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sw1QL3ndxz3CL6 for ; Wed, 20 Dec 2023 04:52:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40c2db2ee28so66017925e9.2 for ; Tue, 19 Dec 2023 20:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703047958; x=1703652758; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1LOxcSw/tF1sThy3cUFmTPJVJmSuupEt4AGIlZzVRh0=; b=jJpzADGdgre8ydKlVOPEz5xns9V2z+MyMhVzSlr3PH71R/YtJIXhlZZr/MWuazsON8 5MvVkaEmaPJlvU3yA6tON4lY8AHwbieQYlM0LM+6dZqVn7yXamwm8tF+A4XPTa25eRco 4XS8B9GsB4aUR+y36K+TiENTWUpqMqo5qzzVJth6Bp0Kxpol9FTXfFoP56epC9yFt8PW 5eeM1x74NkJL89dTWk+jZRevJwhWROPU3hzdHLZ/kl4dG/FnSysU6uDLfTBrFXZ4tF7Y L6ht8JuNgOWzgEv/zsNe9xRNT+eozP+kV4eUPlVQiddExq0gRYMM4tiNXP4p7NXIMW2t iYZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703047958; x=1703652758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1LOxcSw/tF1sThy3cUFmTPJVJmSuupEt4AGIlZzVRh0=; b=Y854n4oTtM4ZY5tfXK6YtOKv3hUUkR64fIQNexYndkS8zddmlh88yZsY3OaPOa4w2k qDgNmO2cn5zVFdBozE8MIfpn2IXDXc0ueoOZwxrwHvINBZtpcvZEP1rdGaDhB86Rw3MC v3kph6fLBwQJh4S2mk8XMl0in+JiiP6erZYHVEEp9Pk6a3l5W1Fc2EptmhDyPDdqMRPu pJEyVELzQAEU4KMi1QYXIMPv0CACkEFMFK/koZ4fotrcYQJwp3t7vTX9Dt2wKJAEENtu 0YaPt13ISgarpIOUPuhNaFb+jnSoCb8Ad3ykiSC2NCidftorQXStSWNSbO8pppfljYe5 Z3jw== X-Gm-Message-State: AOJu0YzOp68M8DQPXM3xokv6+DC7HaYbabOThTY0aJ1ASlafHsCSC7fe 7BDRr+RzMAybpxNmJ84Sdw++dHv8oCXO/DiXuvWSWw== X-Google-Smtp-Source: AGHT+IEbbi40CPslNsrPaZHmFoH0hxmo048S+DdFkhUNhkMzdD6/L9qjT78ibdS8TyMOvFe3UxMKw1yCFVvBUeT5Olk= X-Received: by 2002:a7b:c3c6:0:b0:40b:5e1d:83a3 with SMTP id t6-20020a7bc3c6000000b0040b5e1d83a3mr10805496wmj.55.1703047958061; Tue, 19 Dec 2023 20:52:38 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Warner Losh Date: Tue, 19 Dec 2023 21:52:30 -0700 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Mario Marietto Cc: Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: multipart/alternative; boundary="000000000000937df7060ce9c0b0" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sw1QL3ndxz3CL6 --000000000000937df7060ce9c0b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd think you'd need the right virtualization loader. I'm not entirely sure the u-boot.bin you've been creating is for a dom-u.. If I misunderstood, then the below isn't good advice. Chain booting the u-boot, the first u-boot initializes things so you want to start with stage after the SPL. But the different error messages suggest that it's trying to reboot with kexec, which isn't supported on armv7 at the moment. If you could boot in kvm, I think that the following would work.... Though I'm not entirely sure how to specify the two .fd files in your setup. The use of qemu is to have an easy env to debug things... I don't have a chromebook to try... My first instinct would be to try qemu on x86 (this is the first step of many to get to your destination). If you could boot the GENERIC_SD image that we produce using qemu + edk2-arm-code.fd that would be a huge first step. This will give you the boot loader, I believe, to boot in the VM that you need better than going via the u-boot route. Since you are booting in a virtualized environment, I think it wouldn't matter which one :). So, I did the following to boot the virtualized armv7 FreeBSD environment, following a post on the forums I found and knew to have the right recipe: https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qemu= .80765/ 1. pkg install qemu 2. mkdir qemu-armv7-env 3. cd qemu-armv7-env 4. fetch https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-14.= 0-RELEASE-arm-armv7-GENERICSD.img.xz 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv=3Dn= otrunc 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv=3Dn= otrunc 10. cat > start-freebsd-arm.sh #!/bin/sh qemu-system-arm \ -M virt \ -m 1024 \ -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ -nographic \ -serial mon:stdio ^D 11. chmod +x start-freebsd-arm.sh 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.0: Starting devd. Starting dhclient. DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc4b36a60 FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 panic: Fatal abort cpuid =3D 0 time =3D 1680843057 KDB: stack backtrace: #0 0xc035786c at kdb_backtrace+0x48 #1 0xc02fdd20 at vpanic+0x140 #2 0xc02fdbe0 at vpanic+0 #3 0xc06304ac at abort_align+0 #4 0xc063052c at abort_align+0x80 #5 0xc063017c at abort_handler+0x480 #6 0xc060f480 at exception_exit+0 #7 0xc04a9750 at udp_input+0x288 #8 0xc0473f54 at ip_input+0x1e0 #9 0xc04447c0 at netisr_dispatch_src+0xf8 #10 0xc043bf2c at ether_demux+0x1a4 #11 0xc043d5e4 at ether_nh_input+0x480 #12 0xc04447c0 at netisr_dispatch_src+0xf8 #13 0xc043c404 at ether_input+0x50 #14 0xc01c0838 at vtnet_rx_vq_process+0x880 #15 0xc01b70d0 at vtpci_intx_intr+0xac #16 0xc02b87f0 at ithread_loop+0x2ec #17 0xc02b465c at fork_exit+0xc0 Uptime: 19s I don't know if this is a problem with qemu or FreeBSD's kernel... Warner On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto wrote: > I've asked some help on the channel #arm on Reddit and someone replied : > > > https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_arm= 32_bit_as_domu_with/ > > Maybe his answer can be useful to understand why it does not work. > > On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini > wrote: > >> +Michal >> >> Hi Mario, >> >> I am not sure about booting FreeBSD, but I am certain that u-boot works >> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >> file: >> >> name=3D"test" >> kernel=3D"u-boot.bin" >> extra =3D "console=3Dhvc0" >> memory=3D256 >> vcpus=3D1 >> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >> >> I don't know for sure if you can boot FreeBSD but you should definitely >> be able to see the u-boot command line prompt. The fact that you are >> getting this message: >> >> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found= : >> Invalid kernel >> >> Means that something is not right in the u-boot configuration or u-boot >> build. Michal and Artem (CCed) might know more. From what I recall, >> there was nothing special required to get u-boot.bin to boot as domU >> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >> >> Cheers, >> >> Stefano >> >> >> On Tue, 19 Dec 2023, Mario Marietto wrote: >> > ....I see that some other interesting files have been produced by >> u-boot when I have compiled it : >> > >> > u-boot >> > u-boot.lds >> > u-boot.bin >> > u-boot.map >> > u-boot-nodtb.bin >> > u-boot.dtb >> > u-boot.srec >> > u-boot-dtb.bin >> > u-boot.sym >> > >> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >> > >> > >> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto >> wrote: >> > Hello to everyone. >> > >> > I have compiled the needed u-boot.bin from scratch using this procedur= e >> : >> > >> > # git clone https://github.com/u-boot/u-boot.git >> > # cd u-boot >> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : >> this line generates the file .config >> > # nano .config and I've added these parameters : >> > >> > CONFIG_ARMV7_NONSEC=3Dn >> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >> > >> > the uboot-bin file is generated with this command : >> > >> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >> > >> > At this point,I took a look inside the .config file and I saw that the >> parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >> > some reason,it is not accepted and this could be a problem.... >> > >> > These are the xen config files that I've used : >> > >> > nano freebsd.cfg >> > >> > name=3D"test" >> > kernel=3D"u-boot.bin" >> > extra =3D "console=3Dhvc0" >> > memory=3D256 >> > vcpus=3D1 >> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >> > >> > nano start-freebsd >> > >> > xl create freebsd.cfg >> > xl console freebsd >> > >> > This is what happens when I launch the vm : >> > >> > # ./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 >> 1:cannot (re-)build domain: -3 >> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >> 1:Non-existent domain >> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >> 1:Unable to destroy guest >> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >> 1:Destruction of domain failed >> > freebsd is an invalid domain identifier (rc=3D-6) >> > >> > >> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto >> wrote: >> > So,ok,I should have said "the second u-boot" ; since the first >> u-boot binary is the "u-boot binary located in the RO >> > memory" of the Chromebook". Sorry for the confusion. >> > >> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto >> wrote: >> > ---> There are no specific options in u-boot devoted to FreeBSD >> > >> > This is an important factor. So,what about if,instead of compiling a >> new version of u-boot on the partition 2,I will >> > recompile the u-boot customized version created by the virtual open >> system in 2014,that should be installed on the first >> > partition ? It could work if there are no differences between the >> u-boot that should boot Linux and the u-boot that >> > should boot FreeBSD. >> > >> > Can you give a look at the u-boot source code created by virtual open >> systems ? You can find it on my google drive : >> > >> > >> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?u= sp=3Dsharing >> > >> > I need to understand if I can recompile it without problem so that it >> can satisfy my needs (the ability of the file >> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano >> Stabellini,the xen developer that suggested to me >> > what I could do to have FreeBSD virtualized under Xen on my Arm >> Chromebook) ; otherwise the risk is to find later >> > problems that will make me troubles and that I will not able to fix. >> > >> > I gave a look at the virtual open system u-boot and I didn't see any >> arndale_defconfig inside. So,If I have understood >> > correctly,I should put that file inside the root of the u-boot source >> code,let's say here : >> > >> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >> > >> > .checkpatch.conf README doc >> net >> > .git api drivers >> onenand_ipl >> > .gitignore arch dts >> post >> > COPYING board examples >> rules.mk >> > CREDITS boards.cfg fs >> scripts >> > MAINTAINERS common include >> snapshot.commit >> > MAKEALL config.mk lib >> spl >> > Makefile cros mkconfig >> test >> > PRESUBMIT.cfg disk nand_spl >> tools >> > >> > and I should do : make and make install ? and the file I >> need,u-boot.bin will be generated ? >> > >> > I didn't find any pre made configuration file inside : >> > >> > u-boot-vos # find . -type f -name "exynos*" >> > >> > ./include/exynos-fb.h >> > ./include/configs/exynos5-common.h >> > ./doc/device-tree-bindings/spi/exynos-spi.txt >> > ./doc/device-tree-bindings/usb/exynos-usb.txt >> > ./drivers/power/exynos-tmu.c >> > ./drivers/power/exynos-cpufreq.c >> > ./drivers/video/exynos-fb.c >> > ./drivers/spi/exynos_spi.c >> > ./board/samsung/dts/exynos5250-spring.dts >> > ./board/samsung/dts/exynos5250-smdk5250.dts >> > ./board/samsung/dts/exynos5250-snow.dts >> > ./board/samsung/dts/exynos5250-daisy.dts >> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >> > ./arch/arm/dts/exynos5250.dtsi >> > ./arch/arm/dts/exynos-periph-id.dtsi >> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >> > >> > u-boot-vos # find . -type f -name "arndale*" >> > >> > For sure I can't use a newer version of u-boot because otherwise the >> patches needed to bypass the bootloader protections >> > of the Arm Chromebook (such as a lot of different patches needed to >> boot correctly Linux) will be broken ; anyway,since >> > it works,I don't need to use an updated version of u-boot. >> > >> > ----> As per my experience, you have to respect these two options, >> compiling u-boot for >> > FreeBSD: >> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-maste= r/files/FreeBSD_Fragment >> > >> > It says that I should use these parameters : >> > >> > CONFIG_ARMV7_NONSEC=3Dn >> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >> > >> > These are the parameters used to configure a Linux kernel. I don't >> understand what's the relation between the compilation >> > of a linux kernel and u-boot. In the past I tried to recompile >> u-boot,but I didn't have the need to set up those >> > parameters,so I don't know how to do it (but I know how to recompile a >> Linux kernel). >> > >> > ---> I'm not sure that I'm getting you right, as I don't understand >> what you mean under "the first u-boot". >> > >> > >> > I'm talking about first u-boot because the whole procedure to boot >> Linux on the ARM Chromebook,that's explained here : >> > >> > >> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ >> > >> > >> > at some point they say : >> > >> > >> > To be able to run KVM on ARM platforms, the kernel has to be booted in >> hypervisor mode. Because of this relatively recent >> > requirement (due to the introduction of the virtualization extensions)= , >> up until now all booting methods would boot the >> > kernel in the standard Supervisor mode. >> > >> > For the ARM Chromebook the default boot procedure doesn't allow us to >> boot in hypervisor mode. Although the laptop's boot >> > mechanism is based on the frequently used u-boot, the binary is locate= d >> in RO memory. Fortunately, a chained u-boot >> > mechanism can be used (i.e. starting another u-boot after the >> original). We can then enter hypervisor mode from our >> > custom iteration of u-boot and subsequently load our kernel and >> userspace. >> > >> > So,the first u-boot is the u-boot provided by virtual open >> systems,that's able to chainload the "u-boot binary located in >> > RO memory" , that does not boot Chrome OS in hypervisor mode. We don't >> need it if we want to boot Linux with kvm or xen >> > enabled. >> > >> > >> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >> stanislav.silnicki@mailgate.us> wrote: >> > I'm not an expert in the topic, I only know, that ARM has divide= d >> hardware into two worlds - Secure and >> > Not-So, strictly limiting any software, running in non-secure >> world with access to functions and >> > resources. >> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-har= dware-architecture?lang=3Den >> >> > >> > I'm not sure, that I'm getting you right, as I don't understand what >> you mean under "the first u-boot". >> > >> > As I understand, virtualization (HYP) is running in non-secure world( >> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architect= ure/The-System-Level-Programmers--Model/The-Virtualization-Extens >> > ions), so my guess (only guess!!!), virtualization software has to >> prepare (configure) HW platform in the way, >> > that FreeBSD kernel will not lack any resources, required to configure >> MPU, VA, etc. >> > So, if you lucky to boot virtualizer, which is aware of target OS, tha= t >> maybe you can boot the kernel. Although, I >> > doubt, that you need to boot 'second' u-boot to boot the kernel - ther= e >> is simply ubldr, which you can hook somehow >> > from virtualizer.... >> > >> > Stan >> > >> > >> > >> > Mario Marietto wrote: >> > >> > >> > ---> As I understand, it makes sure that u-boot keeps in secure >> mode during boot and passes control to >> > ubldr, which boots FreeBSD kernel, in that mode. >> > >> > Can you elaborate your sentence more ? I know that the bootloader >> secure mode is bypassed by the virtual open >> > systems u-boot. Are you saying that when the control passes to the >> second u-boot,it will happen in secure >> > mode,so that the bypass that happened loading the first u-boot,is >> annulled ? If this is true,maybe can I boot >> > FreeBSD using the virtual-open-system custom u-boot ? Is this >> compatible with FreeBSD ? Where can I find the >> > u-boot.bin that the xen developer talked about ? thanks bro'. >> > >> > >> > >> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >> stanislav.silnicki@mailgate.us> wrote: >> > Hi Mario, >> > >> > U-Boot beast is hiding in this den: >> https://source.denx.de/u-boot/u-boot.git >> > I took a brief look at your post and it seems to me, that >> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >> > your target armv7 32 bit >> > platform: >> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kc= onfig?ref_type=3Dheads#L3 >> > >> > As for compiling the u-boot, it is a doable task, given that you >> understand what you are doing. There >> > are no specific options in u-boot devoted to FreeBSD. It is a boot >> loader, whose mission to make basic >> > hardware initialization, read you kernel file from some media into RAM >> and then pass it control. >> > >> > Basically, you can grab some defconfig, prepared for any other >> Exynos5250 based board (say, this one: >> > >> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defco= nfig?ref_type=3Dheads) >> and adopt >> > it somehow. >> > >> > As per my experience, you have to respect these two options, compiling >> u-boot for >> > FreeBSD: >> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-maste= r/files/FreeBSD_Fragment >> > >> > As I understand, it makes sure, that u-boot keeps in secure mode durin= g >> boot and passes control to >> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot >> of surprises you may realize. >> > >> > Hope, this will help to progress you tasks >> > Stan >> > >> > Mario Marietto wrote: >> > >> > >> > Hello. >> > >> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >> Chromebook. Basically there are >> > two ways to accomplish this task : >> > >> > 1) to write a patch that allows the FreeBSD kernel to boot as a >> zImage file. This could be >> > accomplished applying this patch to a specific file that's on th= e >> source code of FreeBSD : >> > >> > >> > >> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035= f986c979edef0c9 >> > >> > >> > This patch was written by Julien Grall a lot of time ago and now >> it does not work anymore. >> > This is the reason : >> > >> > >> > It appears FreeBSD-CURRENT removed the last step convertin= g >> 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. >> And I'm not able to fix it. >> > >> > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = : >> > >> > >> > I was trying to explain why and how Julien's patch works so that >> you could be the one >> > to re-do something similar or fix the patch on the FreeBSD kerne= l >> that you are >> > working with. I am happy to help review and write patches but I >> don't work with the >> > FreeBSD kernel so I wouldn't be able to help you quickly. >> However, I might have a >> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >> Because U-Boot >> > definitely boots as Xen on ARM guest firmware/bootloader. You >> should be able to build >> > U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boo= t >> could load FreeBSD >> > from disk or network and start it. For instance as domU config >> file: >> > >> > kernel=3D"/home/petalinux/u-boot.bin" >> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >> > >> > I know it is important to build u-boot with the following config >> to make it work on >> > Xen. >> > >> > CONFIG_CMO_BY_VA_ONLY=3Dy >> > >> > >> > >> > This option seems more doable to me according to my knowledge. But I >> need to understand how to do >> > it. >> > >> > Well,let's say that on the ARM Chromebook I'm forced to use and instal= l >> a customized version of >> > u-boot,created by virtual open systems,because it is the only one that >> allows bypassing its >> > bootloader protection. You can find more information here : >> > >> > >> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/= ?vos=3Dtech >> > >> > This is the relevant section to read : >> > >> > >> > Bootloader : >> > >> > If you wish to skip this chapter you can download a pre-compiled >> binary of the >> > bootloader: >> > >> > >> > $ wget >> > >> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_= u-boot-snow.kpart >> > >> > >> > To be able to run KVM on ARM platforms, the kernel has to be >> booted in hypervisor >> > mode. Because of this relatively recent requirement (due to the >> introduction of the >> > virtualization extensions), up until now all booting methods >> would boot the kernel in >> > the standard Supervisor mode. For the ARM Chromebook the default >> boot procedure >> > doesn't allow us to boot in hypervisor mode. Although the >> laptop's boot mechanism is >> > based on the frequently used u-boot, the binary is located in RO >> memory. Fortunately, >> > a chained u-boot mechanism can be used (i.e. starting another >> u-boot after the >> > original). We can then enter hypervisor mode from our custom >> iteration of u-boot and >> > subsequently load our kernel and userspace. >> > >> > Checkout the needed u-boot code : >> > >> > >> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >> u-boot$ >> > ./scripts/build.sh >> > >> > >> > If successful, a message about how to copy the bootloader on the >> USB flash disk or SD >> > card will appear. We will use it later when preparing the boot >> medium to start our >> > system. If you have followed the Setting up the boot medium >> chapter and you have a >> > prepared boot device, then you can update u-boot by running : >> > >> > >> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >> > >> > >> > >> > so,the needed u-boot that we must use should be installed on the first >> partition of the sd card. >> > >> > There is another relevant section to read : >> > >> > >> > Setting up the boot medium >> > >> > Now it is time to copy all the relevant files that we created in >> the previous >> > chapters,and use them to boot Chromebook with a different kernel >> and OS. In all these >> > examples the device /dev/sdX is used. Take extra care to change >> the examples to the >> > device that you have attached. Insert the boot medium on your >> workstation and >> > carefully execute the following step. First we need to properly >> format the boot >> > medium. >> > >> > In the uboot source directory : >> > >> > >> > $ sudo ./scripts/sdcard.sh /dev/sdX >> > >> > >> > This will erase all data and create 4 partitions in the medium, >> along with copying >> > the u-boot binary to the first partition: >> > >> > >> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >> > Partition 2 =3D not used >> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >> exynos5250-snow.dtb) >> > Partition 4 =3D EXT4 partition for userspace files >> > >> > >> > With u-boot being copied, next is the kernel image and DTB file. >> From the kernel >> > source execute : >> > >> > >> > $ mkdir ../mnt/ >> > $ sudo mount /dev/sdX3 ../mnt/ >> > $ sudo cp arch/arm/boot/uImage ../mnt/ >> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >> > $ sudo umount /dev/sdX3 >> > >> > >> > Finally, we have to copy the Ubuntu userspace filesystem that we >> created earlier: >> > >> > >> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo >> umount /dev/sdX4 >> > >> > >> > >> > Now,my idea is to chainload the already chain loaded u-boot created by >> V.O.S to the new u-boot >> > that we need for booting FreeBSD and that can be installed in the >> partition n.2,as shown in this >> > scheme,because it is not used : >> > >> > >> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >> bit,compatible with FreeBSD on >> > this partition) >> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >> exynos5250-snow.dtb) >> > Partition 4 =3D EXT4 partition for userspace files >> > >> > >> > Take in consideration that default boot string is hardcoded here,in th= e >> snow.h file of the custom >> > u-boot created by VOS : >> > >> > >> > >> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/= snow.h#L101 >> > >> > >> > and it needs to be recompiled because it should point to the partition >> n.2,where I will install >> > the u-boot files as explained here : >> > >> > >> > https://wiki.freebsd.org/arm/Chromebook >> > >> > >> > I have some questions to ask before I start working on this. >> > >> > 1) The xen developer said : >> > >> > >> > You should be able to build U-Boot and use the U-Boot binary as >> Xen guest kernel... >> > >> > >> > >> > where is the u-boot binary,according to this document ? >> > >> > https://wiki.freebsd.org/arm/Chromebook >> > >> > I don't see it. >> > >> > >> > 2) where is the source code of the file that I can get here : >> > >> > >> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/n= v_uboot-snow-simplefb.kpart.bz2 >> > >> > I need the source code if I want to recompile u-boot so that it can >> point to the partition 4. >> > >> > Maybe it can be found on this link : >> > >> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >> > >> > but it can't be opened.... >> > >> > >> > 3) in this specific scenario the source code of u-boot should run on >> arm 32 bit,not on arm >> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's >> powered by a Samsung Exynos >> > 5250 (ARMv7 32 bit Cortex A15) Soc. >> > >> > >> > 4) I'm not sure if I can chainload the customized u-boot created by >> V.O.S that should be >> > installed on the first partition with the u-boot tailored for booting >> FreeBSD that should be >> > installed on the partition 2.... >> > >> > >> > 5) the xen developer said that u-boot should be compiled enabling this >> option : >> > >> > >> > Code: >> > >> > CONFIG_CMO_BY_VA_ONLY=3Dy >> > >> > >> > Well,can you provide some good source that can help me to understand >> how I can recompile u-boot >> > for FreeBSD ? thanks. >> > >> > -- >> > Mario. >> > >> > >> > >> > -- >> > Mario. >> > >> > >> > >> > -- >> > Mario. >> > >> > >> > >> > -- >> > Mario. >> > >> > >> > >> > -- >> > Mario. >> > >> > >> > >> > -- >> > Mario. >> > >> > > > > > -- > Mario. > --000000000000937df7060ce9c0b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd think you'd need the rig= ht virtualization loader. I'm not entirely sure the u-boot.bin you'= ve been creating is for a dom-u..=C2=A0
If I misunderstood, then = the below isn't good advice. Chain booting the u-boot, the first u-boot= initializes things so you want
to start with stage after the SPL= . But the different error messages suggest that it's trying to reboot w= ith kexec, which
isn't supported on armv7 at the moment.
<= /div>

If you could boot in kvm, I think that the followi= ng would work....=C2=A0 Though I'm not entirely sure how to
s= pecify the two .fd files in your setup. The use of qemu is to have an easy = env to debug things... I don't
have a chromebook to try...

My first instinct would be to try qemu on x86 (t= his is the first step of many to get to your destination).

If you could boot the GENERIC_SD image that we produce using qemu = + edk2-arm-code.fd that would
be a huge first step. This will giv= e you the boot loader, I believe, to boot in the VM that you need better
than going via the u-boot route. Since you are booting in a virtual= ized environment, I think it wouldn't
matter which one :).

So, I did the following to boot the virtualized armv= 7 FreeBSD environment, following a post on the forums I found and knew to h= ave the right recipe:
<= br>
1. pkg install qemu
2. mkdir qemu-armv7-env
3. cd qemu-armv7-env
5. xz -= d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz
6. dd if= =3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64
7. dd if=3D/dev/zero of= =3Dpflash1.img bs=3D1m count=3D64
8. dd if=3D/usr/local/share/qemu/edk2-= arm-code.fd of=3Dpflash0.img conv=3Dnotrunc
9. dd if=3D/usr/local/share/= qemu/edk2-arm-vars.fd of=3Dpflash1.img conv=3Dnotrunc
10. cat >= ; start-freebsd-arm.sh
#!/bin/sh
qemu-system-arm \
=C2=A0 -= M virt \
=C2=A0 -m 1024 \
=C2=A0 -drive file=3Dpflash0.img,format=3Dr= aw,if=3Dpflash,readonly=3Don \
=C2=A0 -drive file=3Dpflash1.img,format= =3Draw,if=3Dpflash \
=C2=A0 -drive file=3D$1.img,if=3Dvirtio,cache=3Dwri= tethrough \
=C2=A0 -nographic \
=C2=A0 -serial mon:stdio
^D=
11. chmod +x start-freebsd-arm.sh
12. ./start-freebsd-= arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD

B= ut I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.0:<= /div>

Starting devd.
Starting dhclient.
DHCPDISCOV= ER on vtnet0 to 255.255.255.255 port 67 interval 7
Fatal kernel mode dat= a abort: 'Alignment Fault' on read
trapframe: 0xc4b36a60
FSR= =3D00000001, FAR=3Ddd96701a, spsr=3D20000013
r0 =3D00000000, r1 =3D00000= 001, r2 =3D00000001, r3 =3Dc4b36b4c
r4 =3D00000014, r5 =3Dd6618800, r6 = =3Ddd96702e, r7 =3D0000022c
r8 =3D00000000, r9 =3D0000022c, r10=3Ddd9670= 1a, r11=3Dc4b36b90
r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc = =3Dc04a9750

panic: Fatal abort
cpuid =3D 0
time =3D 1680843057=
KDB: stack backtrace:
#0 0xc035786c at kdb_backtrace+0x48
#1 0xc0= 2fdd20 at vpanic+0x140
#2 0xc02fdbe0 at vpanic+0
#3 0xc06304ac at abo= rt_align+0
#4 0xc063052c at abort_align+0x80
#5 0xc063017c at abort_h= andler+0x480
#6 0xc060f480 at exception_exit+0
#7 0xc04a9750 at udp_i= nput+0x288
#8 0xc0473f54 at ip_input+0x1e0
#9 0xc04447c0 at netisr_di= spatch_src+0xf8
#10 0xc043bf2c at ether_demux+0x1a4
#11 0xc043d5e4 at= ether_nh_input+0x480
#12 0xc04447c0 at netisr_dispatch_src+0xf8
#13 = 0xc043c404 at ether_input+0x50
#14 0xc01c0838 at vtnet_rx_vq_process+0x8= 80
#15 0xc01b70d0 at vtpci_intx_intr+0xac
#16 0xc02b87f0 at ithread_l= oop+0x2ec
#17 0xc02b465c at fork_exit+0xc0
Uptime: 19s

=
I don't know if this is a problem with qemu or FreeBSD's= kernel...

Warner

On Tue, Dec 19, 2023 at= 3:25=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
I've a= sked some help on the channel #arm on Reddit and someone replied :


Maybe his answer can be useful to un= derstand why it does not work.

On Tue, Dec 19, 2023 at 8:33=E2=80= =AFPM Stefano Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/doc= umentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den=
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.
--000000000000937df7060ce9c0b0-- From nobody Wed Dec 20 07:25:15 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sw4pj3DXdz55CxJ for ; Wed, 20 Dec 2023 07:25:33 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sw4ph2jmXz3Gf5 for ; Wed, 20 Dec 2023 07:25:31 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 3BK7PHB2013946 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 20 Dec 2023 09:25:17 +0200 (EET) (envelope-from titus@edc.ro) Received: from tituss-imac.eatlas.local (eatlas.ro [86.126.82.18]) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 3BK7PF4S092591 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2023 09:25:16 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1703057116; bh=pktNa38hjRokKSImBqNM2JfHvbVgTq9i0+dT1GTZHa4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=cKrE8+9rF4oDhC6YF5iFmn/Atx1k9l7Hqdjf4MkzwWS8Gfgs9nnW1eagOhIqy8Nby VIMvMJiIvU4BaoGnRbL02yTgkREevK1q5vCOBTsmKCirbkA2k4gpY0j/lv9KUCMdHD 6wWv31bIfN1TJR+petiqYMU9hT2hQ/YtOOUZBR1E= From: titus Message-Id: <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> Content-Type: multipart/alternative; boundary="Apple-Mail=_FA13BF8B-3EDB-4BA3-9811-F970864C33C7" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook Date: Wed, 20 Dec 2023 09:25:15 +0200 In-Reply-To: Cc: freebsd-arm To: Warner Losh References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sw4ph2jmXz3Gf5 --Apple-Mail=_FA13BF8B-3EDB-4BA3-9811-F970864C33C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 for the panic @ dhcp see=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288 = = https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/ = its a problem with virtio net driver (was fixed by forum user _martin = but never went in the main tree) if you emulate another nic type will work > On Dec 20, 2023, at 6:52 AM, Warner Losh wrote: >=20 > I'd think you'd need the right virtualization loader. I'm not entirely = sure the u-boot.bin you've been creating is for a dom-u..=20 > If I misunderstood, then the below isn't good advice. Chain booting = the u-boot, the first u-boot initializes things so you want > to start with stage after the SPL But the different error messages = suggest that it's trying to reboot with kexec, which > isn't supported on armv7 at the moment. >=20 > If you could boot in kvm, I think that the following would work.... = Though I'm not entirely sure how to > specify the two .fd files in your setup. The use of qemu is to have an = easy env to debug things... I don't > have a chromebook to try... >=20 > My first instinct would be to try qemu on x86 (this is the first step = of many to get to your destination). >=20 > If you could boot the GENERIC_SD image that we produce using qemu + = edk2-arm-code.fd that would > be a huge first step. This will give you the boot loader, I believe, = to boot in the VM that you need better > than going via the u-boot route. Since you are booting in a = virtualized environment, I think it wouldn't > matter which one :). >=20 > So, I did the following to boot the virtualized armv7 FreeBSD = environment, following a post on the forums I found and knew to have the = right recipe: > = https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qem= u.80765/ = >=20 > 1. pkg install qemu > 2. mkdir qemu-armv7-env > 3. cd qemu-armv7-env > 4. fetch = https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-14= .0-RELEASE-arm-armv7-GENERICSD.img.xz = > 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img = conv=3Dnotrunc > 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img = conv=3Dnotrunc > 10. cat > start-freebsd-arm.sh > #!/bin/sh > qemu-system-arm \ > -M virt \ > -m 1024 \ > -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > -nographic \ > -serial mon:stdio > ^D > 11. chmod +x start-freebsd-arm.sh > 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD >=20 > But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and = 14.0: >=20 > Starting devd. > Starting dhclient. > DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc4b36a60 > FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c > r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c > r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 > r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1680843057 > KDB: stack backtrace: > #0 0xc035786c at kdb_backtrace+0x48 > #1 0xc02fdd20 at vpanic+0x140 > #2 0xc02fdbe0 at vpanic+0 > #3 0xc06304ac at abort_align+0 > #4 0xc063052c at abort_align+0x80 > #5 0xc063017c at abort_handler+0x480 > #6 0xc060f480 at exception_exit+0 > #7 0xc04a9750 at udp_input+0x288 > #8 0xc0473f54 at ip_input+0x1e0 > #9 0xc04447c0 at netisr_dispatch_src+0xf8 > #10 0xc043bf2c at ether_demux+0x1a4 > #11 0xc043d5e4 at ether_nh_input+0x480 > #12 0xc04447c0 at netisr_dispatch_src+0xf8 > #13 0xc043c404 at ether_input+0x50 > #14 0xc01c0838 at vtnet_rx_vq_process+0x880 > #15 0xc01b70d0 at vtpci_intx_intr+0xac > #16 0xc02b87f0 at ithread_loop+0x2ec > #17 0xc02b465c at fork_exit+0xc0 > Uptime: 19s >=20 > I don't know if this is a problem with qemu or FreeBSD's kernel... >=20 > Warner >=20 > On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto = > wrote: > I've asked some help on the channel #arm on Reddit and someone replied = : >=20 > = https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_arm3= 2_bit_as_domu_with/ = >=20 > Maybe his answer can be useful to understand why it does not work.=20 >=20 > On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini = > wrote: > +Michal >=20 > Hi Mario, >=20 > I am not sure about booting FreeBSD, but I am certain that u-boot = works > fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config > file: >=20 > name=3D"test" > kernel=3D"u-boot.bin" > extra =3D "console=3Dhvc0" > memory=3D256 > vcpus=3D1 > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >=20 > I don't know for sure if you can boot FreeBSD but you should = definitely > be able to see the u-boot command line prompt. The fact that you are > getting this message: >=20 > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader = found: Invalid kernel >=20 > Means that something is not right in the u-boot configuration or = u-boot > build. Michal and Artem (CCed) might know more. =46rom what I recall, > there was nothing special required to get u-boot.bin to boot as domU > kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >=20 > Cheers, >=20 > Stefano >=20 >=20 > On Tue, 19 Dec 2023, Mario Marietto wrote: > > ....I see that some other interesting files have been produced by = u-boot when I have compiled it : > >=20 > > u-boot > > u-boot.lds > > u-boot.bin > > u-boot.map > > u-boot-nodtb.bin > > u-boot.dtb > > u-boot.srec > > u-boot-dtb.bin > > u-boot.sym > >=20 > > So,maybe I should use a different u-boot* file for booting FreeBSD ? > >=20 > >=20 > > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto = > wrote: > > Hello to everyone. > >=20 > > I have compiled the needed u-boot.bin from scratch using this = procedure : > >=20 > > # git clone https://github.com/u-boot/u-boot.git = > > # cd u-boot > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make = snow_defconfig : this line generates the file .config > > # nano .config and I've added these parameters : > >=20 > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > >=20 > > the uboot-bin file is generated with this command : > >=20 > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make > >=20 > > At this point,I took a look inside the .config file and I saw that = the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for > > some reason,it is not accepted and this could be a problem.... > >=20 > > These are the xen config files that I've used : > >=20 > > nano freebsd.cfg > >=20 > > name=3D"test" > > kernel=3D"u-boot.bin" > > extra =3D "console=3Dhvc0" > > memory=3D256 > > vcpus=3D1 > > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > >=20 > > nano start-freebsd > >=20 > > xl create freebsd.cfg > > xl console freebsd > >=20 > > This is what happens when I launch the vm : > >=20 > > # ./start-freebsd > > =20 > > 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 = 1:cannot (re-)build domain: -3 > > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain = 1:Non-existent domain > > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain = 1:Unable to destroy guest > > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain = 1:Destruction of domain failed > > freebsd is an invalid domain identifier (rc=3D-6) > >=20 > >=20 > > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto = > wrote: > > So,ok,I should have said "the second u-boot" ; since the first = u-boot binary is the "u-boot binary located in the RO > > memory" of the Chromebook". Sorry for the confusion. > >=20 > > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto = > wrote: > > ---> There are no specific options in u-boot devoted to = FreeBSD > >=20 > > This is an important factor. So,what about if,instead of compiling a = new version of u-boot on the partition 2,I will > > recompile the u-boot customized version created by the virtual open = system in 2014,that should be installed on the first > > partition ? It could work if there are no differences between the = u-boot that should boot Linux and the u-boot that > > should boot FreeBSD. > >=20 > > Can you give a look at the u-boot source code created by virtual = open systems ? You can find it on my google drive : > >=20 > > = https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp= =3Dsharing = > >=20 > > I need to understand if I can recompile it without problem so that = it can satisfy my needs (the ability of the file > > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano = Stabellini,the xen developer that suggested to me > > what I could do to have FreeBSD virtualized under Xen on my Arm = Chromebook) ; otherwise the risk is to find later > > problems that will make me troubles and that I will not able to fix. > >=20 > > I gave a look at the virtual open system u-boot and I didn't see any = arndale_defconfig inside. So,If I have understood > > correctly,I should put that file inside the root of the u-boot = source code,let's say here : > >=20 > > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > > =20 > > .checkpatch.conf README doc = net > > .git api drivers = onenand_ipl > > .gitignore arch dts = post > > COPYING board examples = rules.mk > > CREDITS boards.cfg fs = scripts > > MAINTAINERS common include = snapshot.commit > > MAKEALL config.mk = lib spl > > Makefile cros mkconfig = test > > PRESUBMIT.cfg disk nand_spl = tools > >=20 > > and I should do : make and make install ? and the file I = need,u-boot.bin will be generated ?=20 > >=20 > > I didn't find any pre made configuration file inside : > >=20 > > u-boot-vos # find . -type f -name "exynos*"=20 > >=20 > > ./include/exynos-fb.h > > ./include/configs/exynos5-common.h > > ./doc/device-tree-bindings/spi/exynos-spi.txt > > ./doc/device-tree-bindings/usb/exynos-usb.txt > > ./drivers/power/exynos-tmu.c > > ./drivers/power/exynos-cpufreq.c > > ./drivers/video/exynos-fb.c > > ./drivers/spi/exynos_spi.c > > ./board/samsung/dts/exynos5250-spring.dts > > ./board/samsung/dts/exynos5250-smdk5250.dts > > ./board/samsung/dts/exynos5250-snow.dts > > ./board/samsung/dts/exynos5250-daisy.dts > > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h > > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h > > ./arch/arm/dts/exynos5250.dtsi > > ./arch/arm/dts/exynos-periph-id.dtsi > > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=20 > >=20 > > u-boot-vos # find . -type f -name "arndale*" > >=20 > > For sure I can't use a newer version of u-boot because otherwise the = patches needed to bypass the bootloader protections > > of the Arm Chromebook (such as a lot of different patches needed to = boot correctly Linux) will be broken ; anyway,since > > it works,I don't need to use an updated version of u-boot. > >=20 > > ----> As per my experience, you have to respect these two options, = compiling u-boot for > > FreeBSD: = https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/= files/FreeBSD_Fragment = > >=20 > > It says that I should use these parameters : > >=20 > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > >=20 > > These are the parameters used to configure a Linux kernel. I don't = understand what's the relation between the compilation > > of a linux kernel and u-boot. In the past I tried to recompile = u-boot,but I didn't have the need to set up those > > parameters,so I don't know how to do it (but I know how to recompile = a Linux kernel). > >=20 > > ---> I'm not sure that I'm getting you right, as I don't understand = what you mean under "the first u-boot". > >=20 > >=20 > > I'm talking about first u-boot because the whole procedure to boot = Linux on the ARM Chromebook,that's explained here : > >=20 > > = http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ = = > >=20 > >=20 > > at some point they say : > >=20 > >=20 > > To be able to run KVM on ARM platforms, the kernel has to be booted = in hypervisor mode. Because of this relatively recent > > requirement (due to the introduction of the virtualization = extensions), up until now all booting methods would boot the > > kernel in the standard Supervisor mode. > >=20 > > For the ARM Chromebook the default boot procedure doesn't allow us = to boot in hypervisor mode. Although the laptop's boot > > mechanism is based on the frequently used u-boot, the binary is = located in RO memory. Fortunately, a chained u-boot > > mechanism can be used (i.e. starting another u-boot after the = original). We can then enter hypervisor mode from our > > custom iteration of u-boot and subsequently load our kernel and = userspace. > >=20 > > So,the first u-boot is the u-boot provided by virtual open = systems,that's able to chainload the "u-boot binary located in > > RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen > > enabled. > >=20 > >=20 > > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki = > = wrote: > > I'm not an expert in the topic, I only know, that ARM has = divided hardware into two worlds - Secure and > > Not-So, strictly limiting any software, running in non-secure = world with access to functions and > > resources. = https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hardw= are-architecture?lang=3Den = > >=20 > > I'm not sure, that I'm getting you right, as I don't understand what = you mean under "the first u-boot". > >=20 > > As I understand, virtualization (HYP) is running in non-secure = world(https://developer.arm.com/documentation/ddi0406/c/System-Level-Archi= tecture/The-System-Level-Programmers--Model/The-Virtualization-Extens = > > ions), so my guess (only guess!!!), virtualization software has to = prepare (configure) HW platform in the way, > > that FreeBSD kernel will not lack any resources, required to = configure MPU, VA, etc. > > So, if you lucky to boot virtualizer, which is aware of target OS, = that maybe you can boot the kernel. Although, I > > doubt, that you need to boot 'second' u-boot to boot the kernel - = there is simply ubldr, which you can hook somehow > > from virtualizer.... > >=20 > > Stan > >=20 > >=20 > >=20 > > Mario Marietto wrote: > >=20 > >=20 > > ---> As I understand, it makes sure that u-boot keeps in = secure mode during boot and passes control to > > ubldr, which boots FreeBSD kernel, in that mode. > >=20 > > Can you elaborate your sentence more ? I know that the bootloader = secure mode is bypassed by the virtual open > > systems u-boot. Are you saying that when the control passes to the = second u-boot,it will happen in secure > > mode,so that the bypass that happened loading the first u-boot,is = annulled ? If this is true,maybe can I boot > > FreeBSD using the virtual-open-system custom u-boot ? Is this = compatible with FreeBSD ? Where can I find the > > u-boot.bin that the xen developer talked about ? thanks bro'. > >=20 > >=20 > >=20 > > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki = > = wrote: > > Hi Mario, > >=20 > > U-Boot beast is hiding in this den: = https://source.denx.de/u-boot/u-boot.git = > > I took a brief look at your post and it seems to me, that option = CONFIG_CMO_BY_VA_ONLY is irrelevant to > > your target armv7 32 bit > > platform: = https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kcon= fig?ref_type=3Dheads#L3 = > >=20 > > As for compiling the u-boot, it is a doable task, given that you = understand what you are doing. There > > are no specific options in u-boot devoted to FreeBSD. It is a boot = loader, whose mission to make basic > > hardware initialization, read you kernel file from some media into = RAM and then pass it control. > >=20 > > Basically, you can grab some defconfig, prepared for any other = Exynos5250 based board (say, this one: > > = https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconf= ig?ref_type=3Dheads = ) and adopt > > it somehow. > >=20 > > As per my experience, you have to respect these two options, = compiling u-boot for > > FreeBSD: = https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/= files/FreeBSD_Fragment = > >=20 > > As I understand, it makes sure, that u-boot keeps in secure mode = during boot and passes control to > > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a = lot of surprises you may realize. > >=20 > > Hope, this will help to progress you tasks > > Stan > >=20 > > Mario Marietto wrote: > >=20 > >=20 > > Hello. > >=20 > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM = Chromebook. Basically there are > > two ways to accomplish this task : > >=20 > > 1) to write a patch that allows the FreeBSD kernel to boot as = a zImage file. This could be > > accomplished applying this patch to a specific file that's on = the source code of FreeBSD : > >=20 > >=20 > > = https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f9= 86c979edef0c9 = > >=20 > >=20 > > This patch was written by Julien Grall a lot of time ago and = now it does not work anymore. > > This is the reason : > >=20 > >=20 > > 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 > >=20 > >=20 > >=20 > > So,without a rebase of that patch the first option is not = applicable. And I'm not able to fix it. > >=20 > > 2) booting FreeBSD using U-Boot,as explained to me by a xen = developer : > >=20 > >=20 > > I was trying to explain why and how Julien's patch works so = that you could be the one > > to re-do something similar or fix the patch on the FreeBSD = kernel that you are > > working with. I am happy to help review and write patches but = I don't work with the > > FreeBSD kernel so I wouldn't be able to help you quickly. = However, I might have a > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? = Because U-Boot > > definitely boots as Xen on ARM guest firmware/bootloader. You = should be able to build > > U-Boot and use the U-Boot binary as Xen guest kernel, then = U-Boot could load FreeBSD > > from disk or network and start it. For instance as domU config = file: > >=20 > > kernel=3D"/home/petalinux/u-boot.bin" > > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] > >=20 > > I know it is important to build u-boot with the following = config to make it work on > > Xen. > >=20 > > CONFIG_CMO_BY_VA_ONLY=3Dy > >=20 > >=20 > >=20 > > This option seems more doable to me according to my knowledge. But I = need to understand how to do > > it. > >=20 > > Well,let's say that on the ARM Chromebook I'm forced to use and = install a customized version of > > u-boot,created by virtual open systems,because it is the only one = that allows bypassing its > > bootloader protection. You can find more information here : > >=20 > > = http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?v= os=3Dtech = > >=20 > > This is the relevant section to read : > >=20 > >=20 > > Bootloader : > >=20 > > If you wish to skip this chapter you can download a = pre-compiled binary of the > > bootloader: > >=20 > >=20 > > $ wget > > = http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-= boot-snow.kpart = > >=20 > >=20 > > To be able to run KVM on ARM platforms, the kernel has to be = booted in hypervisor > > mode. Because of this relatively recent requirement (due to = the introduction of the > > virtualization extensions), up until now all booting methods = would boot the kernel in > > the standard Supervisor mode. For the ARM Chromebook the = default boot procedure > > doesn't allow us to boot in hypervisor mode. Although the = laptop's boot mechanism is > > based on the frequently used u-boot, the binary is located in = RO memory. Fortunately, > > a chained u-boot mechanism can be used (i.e. starting another = u-boot after the > > original). We can then enter hypervisor mode from our custom = iteration of u-boot and > > subsequently load our kernel and userspace. > >=20 > > Checkout the needed u-boot code : > >=20 > >=20 > > $ git clone git://github.com/virtualopensystems/u-boot.git$ = cd u-boot$ > > ./scripts/build.sh > >=20 > >=20 > > If successful, a message about how to copy the bootloader on = the USB flash disk or SD > > card will appear. We will use it later when preparing the boot = medium to start our > > system. If you have followed the Setting up the boot medium = chapter and you have a > > prepared boot device, then you can update u-boot by running : > >=20 > >=20 > > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 > >=20 > >=20 > >=20 > > so,the needed u-boot that we must use should be installed on the = first partition of the sd card. > >=20 > > There is another relevant section to read : > >=20 > >=20 > > Setting up the boot medium > >=20 > > Now it is time to copy all the relevant files that we created = in the previous > > chapters,and use them to boot Chromebook with a different = kernel and OS. In all these > > examples the device /dev/sdX is used. Take extra care to = change the examples to the > > device that you have attached. Insert the boot medium on your = workstation and > > carefully execute the following step. First we need to = properly format the boot > > medium. > >=20 > > In the uboot source directory : > >=20 > >=20 > > $ sudo ./scripts/sdcard.sh /dev/sdX > >=20 > >=20 > > This will erase all data and create 4 partitions in the = medium, along with copying > > the u-boot binary to the first partition: > >=20 > >=20 > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used > > Partition 3 =3D EXT2 partition for u-boot files (uImage and = exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > >=20 > >=20 > > With u-boot being copied, next is the kernel image and DTB = file. =46rom the kernel > > source execute : > >=20 > >=20 > > $ mkdir ../mnt/ > > $ sudo mount /dev/sdX3 ../mnt/ > > $ sudo cp arch/arm/boot/uImage ../mnt/ > > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ > > $ sudo umount /dev/sdX3 > >=20 > >=20 > > Finally, we have to copy the Ubuntu userspace filesystem that = we created earlier: > >=20 > >=20 > > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo = umount /dev/sdX4 > >=20 > >=20 > >=20 > > Now,my idea is to chainload the already chain loaded u-boot created = by V.O.S to the new u-boot > > that we need for booting FreeBSD and that can be installed in the = partition n.2,as shown in this > > scheme,because it is not used : > >=20 > >=20 > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 = bit,compatible with FreeBSD on > > this partition) > > Partition 3 =3D EXT2 partition for u-boot files (uImage and = exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > >=20 > >=20 > > Take in consideration that default boot string is hardcoded here,in = the snow.h file of the custom > > u-boot created by VOS : > >=20 > >=20 > > = https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/sn= ow.h#L101 = > >=20 > >=20 > > and it needs to be recompiled because it should point to the = partition n.2,where I will install > > the u-boot files as explained here : > >=20 > >=20 > > https://wiki.freebsd.org/arm/Chromebook = > >=20 > >=20 > > I have some questions to ask before I start working on this. > >=20 > > 1) The xen developer said : > >=20 > >=20 > > You should be able to build U-Boot and use the U-Boot binary = as Xen guest kernel... > >=20 > >=20 > >=20 > > where is the u-boot binary,according to this document ? > >=20 > > https://wiki.freebsd.org/arm/Chromebook = > >=20 > > I don't see it. > >=20 > >=20 > > 2) where is the source code of the file that I can get here : > >=20 > > = http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_= uboot-snow-simplefb.kpart.bz2 = > >=20 > > I need the source code if I want to recompile u-boot so that it can = point to the partition 4. > >=20 > > Maybe it can be found on this link : > >=20 > > http://linux-exynos.org/dist/chromebook/nv_uboot/ = > >=20 > > but it can't be opened.... > >=20 > >=20 > > 3) in this specific scenario the source code of u-boot should run on = arm 32 bit,not on arm > > 64,because I have the Samsung Chromebook "SNOW" model = XE303C12,that's powered by a Samsung Exynos > > 5250 (ARMv7 32 bit Cortex A15) Soc. > >=20 > >=20 > > 4) I'm not sure if I can chainload the customized u-boot created by = V.O.S that should be > > installed on the first partition with the u-boot tailored for = booting FreeBSD that should be > > installed on the partition 2.... > >=20 > >=20 > > 5) the xen developer said that u-boot should be compiled enabling = this option : > >=20 > >=20 > > Code: > >=20 > > CONFIG_CMO_BY_VA_ONLY=3Dy > >=20 > >=20 > > Well,can you provide some good source that can help me to understand = how I can recompile u-boot > > for FreeBSD ? thanks. > >=20 > > -- > > Mario. > >=20 > >=20 > >=20 > > -- > > Mario. > >=20 > >=20 > >=20 > > -- > > Mario. > >=20 > >=20 > >=20 > > -- > > Mario. > >=20 > >=20 > >=20 > > -- > > Mario. > >=20 > >=20 > >=20 > > -- > > Mario. > >=20 > > >=20 >=20 > --=20 > Mario. --Apple-Mail=_FA13BF8B-3EDB-4BA3-9811-F970864C33C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 for = the panic @ dhcp see 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288<= /div>
https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-q= emu.89016/

its a problem with virtio net driver (was fixed by forum user = _martin but never went in the main tree)
if you = emulate another nic type will work


On Dec 20, 2023, at 6:52 AM, Warner Losh <imp@bsdimp.com> = wrote:

I'd = think you'd need the right virtualization loader. I'm not entirely sure = the u-boot.bin you've been creating is for a dom-u.. 
If I misunderstood, then the below isn't good advice. Chain = booting the u-boot, the first u-boot initializes things so you = want
to start with stage after the SPL But the = different error messages suggest that it's trying to reboot with kexec, = which
isn't supported on armv7 at the moment.

If = you could boot in kvm, I think that the following would work....  = Though I'm not entirely sure how to
specify the two = .fd files in your setup. The use of qemu is to have an easy env to debug = things... I don't
have a chromebook to try...

My = first instinct would be to try qemu on x86 (this is the first step of = many to get to your destination).

If you could boot the GENERIC_SD image = that we produce using qemu + edk2-arm-code.fd that would
be a huge first step. This will give you the boot loader, I = believe, to boot in the VM that you need better
than = going via the u-boot route. Since you are booting in a virtualized = environment, I think it wouldn't
matter which one = :).

So, I did = the following to boot the virtualized armv7 FreeBSD environment, = following a post on the forums I found and knew to have the right = recipe:
https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-i= mage-in-qemu.80765/

1. pkg install qemu
2. mkdir = qemu-armv7-env
3. cd qemu-armv7-env
4. fetch https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0= /FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz
5. xz -d -T 0 = FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz
6. = dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64
7. = dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64
8. = dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img = conv=3Dnotrunc
9. dd = if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img = conv=3Dnotrunc
10. cat > = start-freebsd-arm.sh
#!/bin/sh
qemu-system-arm \
  -M virt \
  -m 1024 \
  -drive = file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \
  -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash = \
  -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrou= gh \
  -nographic \
  -serial = mon:stdio
^D
11. chmod +x = start-freebsd-arm.sh
12. ./start-freebsd-arm.sh = FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD

But I hit a snag with this on qemu = 8.1.2 and 8.1.3 with both 13.2 and 14.0:

Starting devd.
Starting = dhclient.
DHCPDISCOVER on vtnet0 to 255.255.255.255 port = 67 interval 7
Fatal kernel mode data abort: 'Alignment = Fault' on read
trapframe: 0xc4b36a60
FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013
r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 = =3Dc4b36b4c
r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, = r7 =3D0000022c
r8 =3D00000000, r9 =3D0000022c, = r10=3Ddd96701a, r11=3Dc4b36b90
r12=3D4300ffff, = ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750

panic: Fatal abort
cpuid =3D 0
time= =3D 1680843057
KDB: stack backtrace:
#0 = 0xc035786c at kdb_backtrace+0x48
#1 0xc02fdd20 at = vpanic+0x140
#2 0xc02fdbe0 at vpanic+0
#3 = 0xc06304ac at abort_align+0
#4 0xc063052c at = abort_align+0x80
#5 0xc063017c at abort_handler+0x480
#6 0xc060f480 at exception_exit+0
#7 0xc04a9750 = at udp_input+0x288
#8 0xc0473f54 at ip_input+0x1e0
#9 0xc04447c0 at netisr_dispatch_src+0xf8
#10 = 0xc043bf2c at ether_demux+0x1a4
#11 0xc043d5e4 at = ether_nh_input+0x480
#12 0xc04447c0 at = netisr_dispatch_src+0xf8
#13 0xc043c404 at = ether_input+0x50
#14 0xc01c0838 at = vtnet_rx_vq_process+0x880
#15 0xc01b70d0 at = vtpci_intx_intr+0xac
#16 0xc02b87f0 at = ithread_loop+0x2ec
#17 0xc02b465c at fork_exit+0xc0
Uptime: 19s

I don't know if this is a problem with qemu or FreeBSD's = kernel...

Warner

On Tue, Dec = 19, 2023 at 3:25=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
I've asked some help on the channel #arm on Reddit and = someone replied :

https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freeb= sd_for_arm32_bit_as_domu_with/

Maybe his answer can be useful to = understand why it does not work.

On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano = Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot = works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should = definitely
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader = found: Invalid kernel

Means that something is not right in the u-boot configuration or = u-boot
build. Michal and Artem (CCed) might know more. =46rom what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by = u-boot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD = ?
>
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>       Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this = procedure :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make = snow_defconfig : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
= >
> At this point,I took a look inside the .config file and I saw that = the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
= >
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./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 = 1:cannot (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain = 1:Non-existent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain = 1:Unable to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain = 1:Destruction of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>       So,ok,I should have said "the second = u-boot" ; since the first u-boot binary is the "u-boot binary located in = the RO
>       memory" of the Chromebook". Sorry for the = confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>       ---> There are no specific options in = u-boot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling = a new version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open = system in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the = u-boot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual = open systems ? You can find it on my google drive :
>
> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09B= Rm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that = it can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by = Stefano Stabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm = Chromebook) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to = fix.
>
> I gave a look at the virtual open system u-boot and I didn't see = any arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot = source code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # = ls
>  
> .checkpatch.conf        README =             &n= bsp;    doc =             &n= bsp;       net
> .git =             &n= bsp;      api =             &n= bsp;       drivers =             &n= bsp;   onenand_ipl
> .gitignore =             &n= bsp;arch =             &n= bsp;      dts =             &n= bsp;       post
> COPYING =             &n= bsp;   board =             &n= bsp;     examples =             &n= bsp;  rules.mk
> CREDITS =             &n= bsp;   boards.cfg =             &n= bsp;fs =             &n= bsp;        scripts
= > MAINTAINERS =             co= mmon =             &n= bsp;    include =             &n= bsp;   snapshot.commit
> MAKEALL =             &n= bsp;   config.mk =             &n= bsp; lib =             &n= bsp;       spl
> Makefile =             &n= bsp;  cros =             &n= bsp;      mkconfig =             &n= bsp;  test
> PRESUBMIT.cfg =           disk =             &n= bsp;      nand_spl =             &n= bsp;  tools
>
> and I should do : make and make install ? and the file I = need,u-boot.bin will be generated ? 
>
> I didn't find any pre made configuration file inside :
= >
> u-boot-vos # find . -type f -name "exynos*" 
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c 
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise = the patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to = boot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two = options, compiling u-boot for
> FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-b= oot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't = understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile = u-boot,but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to = recompile a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don't = understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot = Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-ch= romebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted = in hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization = extensions), up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us = to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is = located in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the = original). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and = userspace.
>
> So,the first u-boot is the u-boot provided by virtual open = systems,that's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
>       I'm not an expert in the topic, I only = know, that ARM has divided hardware into two worlds - Secure and
>       Not-So, strictly limiting any software, = running in non-secure world with access to functions and
>       resources. https://developer.arm.com/documentation/den0013/d/Security/Trus= tZone-hardware-architecture?lang=3Den
>
> I'm not sure, that I'm getting you right, as I don't understand = what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure = world(https://developer.arm.com/documentation/ddi0406/c/System-Level-= Architecture/The-System-Level-Programmers--Model/The-Virtualization-Extens=
> ions), so my guess (only guess!!!), virtualization software has to = prepare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to = configure MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, = that maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kernel - = there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>       ---> As I understand, it makes sure = that u-boot keeps in secure mode during boot and passes control to
>       ubldr, which boots FreeBSD kernel, in = that mode.
>
> Can you elaborate your sentence more ? I know that the bootloader = secure mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the = second u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is = annulled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this = compatible with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
>       Hi Mario,
>
> U-Boot  beast is hiding in this den: https://source.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that = option CONFIG_CMO_BY_VA_ONLY is irrelevant to
> your target armv7 32 bit
> platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu= /armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you = understand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot = loader, whose mission to make basic
> hardware initialization, read you kernel file from some media into = RAM and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other = Exynos5250 based board  (say, this one:
> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arnd= ale_defconfig?ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-b= oot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode = during boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a = lot of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>       Hello.
>
>       I'm trying to boot FreeBSD for arm32 bit = as DomU on my ARM Chromebook. Basically there are
>       two ways to accomplish this task :
>
>       1) to write a patch that allows the = FreeBSD kernel to boot as a zImage file. This could be
>       accomplished applying this patch to a = specific file that's on the source code of FreeBSD :
>
>
>       https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391= 472717035f986c979edef0c9
>
>
>       This patch was written by Julien Grall a = lot of time ago and now it does not work anymore.
>       This is the reason :
>
>
>             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. And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen = developer :
>
>
>       I was trying to explain why and how = Julien's patch works so that you could be the one
>       to re-do something similar or fix the = patch on the FreeBSD kernel that you are
>       working with. I am happy to help review = and write patches but I don't work with the
>       FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>       suggestion. Do you know if FreeBSD can be = booted by U-Boot ? Because U-Boot
>       definitely boots as Xen on ARM guest = firmware/bootloader. You should be able to build
>       U-Boot and use the U-Boot binary as Xen = guest kernel, then U-Boot could load FreeBSD
>       from disk or network and start it. For = instance as domU config file:
>
>       kernel=3D"/home/petalinux/u-boot.bin"
>       disk =3D [ = '/home/petalinux/test.img,raw,xvda' ]
>
>       I know it is important to build u-boot = with the following config to make it work on
>       Xen.
>
>       CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But = I need to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use and = install a customized version of
> u-boot,created by virtual open systems,because it is the only one = that allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-ch= romebook/?vos=3Dtech
>
> This is the relevant section to read :
>
>
>       Bootloader :
>
>       If you wish to skip this chapter you can = download a pre-compiled binary of the
>       bootloader:
>
>
>       $ wget
>       http://www.virtualopensystems.com/downloads/guides/kvm_on_chrom= ebook/nv_u-boot-snow.kpart
>
>
>       To be able to run KVM on ARM platforms, = the kernel has to be booted in hypervisor
>       mode. Because of this relatively recent = requirement (due to the introduction of the
>       virtualization extensions), up until now = all booting methods would boot the kernel in
>       the standard Supervisor mode. For the ARM = Chromebook the default boot procedure
>       doesn't allow us to boot in hypervisor = mode. Although the laptop's boot mechanism is
>       based on the frequently used u-boot, the = binary is located in RO memory. Fortunately,
>       a chained u-boot mechanism can be used = (i.e. starting another u-boot after the
>       original). We can then enter hypervisor = mode from our custom iteration of u-boot and
>       subsequently load our kernel and = userspace.
>
>       Checkout the needed u-boot code :
>
>
>       $ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$
>       ./scripts/build.sh
>
>
>       If successful, a message about how to = copy the bootloader on the USB flash disk or SD
>       card will appear. We will use it later = when preparing the boot medium to start our
>       system. If you have followed the Setting = up the boot medium chapter and you have a
>       prepared boot device, then you can update = u-boot by running :
>
>
>       $ sudo dd if=3Dnv_uboot-snow.kpart = of=3D/dev/sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the = first partition of the sd card.
>
> There is another relevant section to read :
>
>
>       Setting up the boot medium
>
>       Now it is time to copy all the relevant = files that we created in the previous
>       chapters,and use them to boot Chromebook = with a different kernel and OS. In all these
>       examples the device /dev/sdX is used. = Take extra care to change the examples to the
>       device that you have attached. Insert the = boot medium on your workstation and
>       carefully execute the following step. = First we need to properly format the boot
>       medium.
>
>       In the uboot source directory :
>
>
>       $ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>       This will erase all data and create 4 = partitions in the medium, along with copying
>       the u-boot binary to the first = partition:
>
>
>       Partition 1 =3D ChromeOS signed binary = (V.O.S chained u-boot)
>       Partition 2 =3D not used
>       Partition 3 =3D EXT2 partition for u-boot = files (uImage and exynos5250-snow.dtb)
>       Partition 4 =3D EXT4 partition for = userspace files
>
>
>       With u-boot being copied, next is the = kernel image and DTB file. =46rom the kernel
>       source execute :
>
>
>       $ mkdir ../mnt/
>       $ sudo mount /dev/sdX3 ../mnt/
>       $ sudo cp arch/arm/boot/uImage ../mnt/
>       $ sudo cp = arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/
>       $ sudo umount /dev/sdX3
>
>
>       Finally, we have to copy the Ubuntu = userspace filesystem that we created earlier:
>
>
>       $ sudo mount /dev/sdX4 mnt/$ sudo cp -a = ./precise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created = by V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the = partition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm = 32 bit,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and = exynos5250-snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in = the snow.h file of the custom
> u-boot created by VOS :
>
>
> https://github.com/virtualopensyste...18a39b6c177dff58a/include= /configs/snow.h#L101
>
>
> and it needs to be recompiled because it should point to the = partition n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>       You should be able to build U-Boot and = use the U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/di= stfiles/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can = point to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_uboot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run = on arm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model = XE303C12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created by = V.O.S that should be
> installed on the first partition with the u-boot tailored for = booting FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling = this option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to = understand how I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.

= --Apple-Mail=_FA13BF8B-3EDB-4BA3-9811-F970864C33C7-- From nobody Wed Dec 20 14:29:14 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwGDL1rqWz551L8 for ; Wed, 20 Dec 2023 14:29:54 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwGDK4gBbz4Z5X for ; Wed, 20 Dec 2023 14:29:53 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a1915034144so676857866b.0 for ; Wed, 20 Dec 2023 06:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703082592; x=1703687392; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XBc436qXB1B0EPuIiu6OT/PUzlzUKensN/4zUe1t/vE=; b=PDuDXKVnoXXnFTTSfYZpZ1jZxINwezC3qTPkOUOGjmMDH28EyHvSekUTzytzMWv3yx dqMwUF/6JnJy63s7K8KrV8EhYkTN4qLEy6DUkrszDyVB+a4YowKHQCPj3Lk5EcJU9a/2 XVCyCErjQHORgnpkEG7RfH/beSU1vUQtbVR65HFRwvpyfXC+5E22S01yJX0E0PL7lHU5 bSqARFdI4qawGewpenrFAugkQjL35vRndqxP49Rza++RDqKze+gJMZryjCxCXkCF49pi fZ4K1oAOhaKWPPUf2taAHw+i4Dv2nKwMyMJ1ho5eRrVWhU8utVlZN7x80/zBVlhKqF+o 2jug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703082592; x=1703687392; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XBc436qXB1B0EPuIiu6OT/PUzlzUKensN/4zUe1t/vE=; b=wa65wYMUwzeZvuhhh8Oqmx8D47F/aGYh6SAvLW2qP/5DsEA44M5R31zsOB/Yzqcb7E QagYvPSFNnbAxniyy/4HF3P6f2e4ONb4aYfqXjmLgjsIVGadW2Kyt/8L2Y9MvpkIOmVd 7TivAFZ2+qnKPlmaxzUEk1M4hv3FYYj4an7KmnwFE2vkmppzOu2RhZz0tYl4IKsvzFbM b5AMfWn5dOb2kNK5dAVr7DEJU0TITW1IE9bLxV4j6TRL81JRtn/IEphVZwfMZCAg31Sn pvDkxNUX2kGcVpiDjKua2cRNsM6MbpyH+TAJf4QGASuVaN5hqtjZppJ3B5sKXhwlXBIU nBBg== X-Gm-Message-State: AOJu0Yxd99wuDYju2LuGnbZrhDIhf56aNJvq8E59UReR540VEqQ3rU4A yxqG+ZapPsJjWAhdmPJGR3wOUpRyabmtr5DkzBY= X-Google-Smtp-Source: AGHT+IFuROEyqY/4uGXI13IEhd7kcnPBsZL+FYIO1799X7f3Zb9CitPKYffddfVtl/VsXgUaY23HCMUjq735cAXh//w= X-Received: by 2002:a17:906:51cf:b0:a23:71cf:ab11 with SMTP id v15-20020a17090651cf00b00a2371cfab11mr1461811ejk.10.1703082591486; Wed, 20 Dec 2023 06:29:51 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Wed, 20 Dec 2023 15:29:14 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Warner Losh Cc: Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: multipart/alternative; boundary="000000000000e38930060cf1d01d" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwGDK4gBbz4Z5X --000000000000e38930060cf1d01d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. @Warner Losh : thanks for your help with the virtualization of FreeBSD with qemu,but I have already achieved this goal. The image file that I'm using (FreeBSD-13.2-RELEASE-armv7.img,raw,xvda) is already able to boot with qemu-kvm on my ARM Chromebook. We have also fixed the virtio-net driver bug on the FreeBSD forum,on this post started by me : https://forums.freebsd.org/threads/im-trying-to-virtualize-freebsd-13-2-for= -armv7-on-my-arm-chromebook-armhf-with-qemu-kvm.89965/ Booting FreeBSD as domU using Xen instead of qemu-kvm is another story. On Wed, Dec 20, 2023 at 5:52=E2=80=AFAM Warner Losh wrote: > I'd think you'd need the right virtualization loader. I'm not entirely > sure the u-boot.bin you've been creating is for a dom-u.. > If I misunderstood, then the below isn't good advice. Chain booting the > u-boot, the first u-boot initializes things so you want > to start with stage after the SPL. But the different error messages > suggest that it's trying to reboot with kexec, which > isn't supported on armv7 at the moment. > > If you could boot in kvm, I think that the following would work.... > Though I'm not entirely sure how to > specify the two .fd files in your setup. The use of qemu is to have an > easy env to debug things... I don't > have a chromebook to try... > > My first instinct would be to try qemu on x86 (this is the first step of > many to get to your destination). > > If you could boot the GENERIC_SD image that we produce using qemu + > edk2-arm-code.fd that would > be a huge first step. This will give you the boot loader, I believe, to > boot in the VM that you need better > than going via the u-boot route. Since you are booting in a virtualized > environment, I think it wouldn't > matter which one :). > > So, I did the following to boot the virtualized armv7 FreeBSD environment= , > following a post on the forums I found and knew to have the right recipe: > > https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qe= mu.80765/ > > 1. pkg install qemu > 2. mkdir qemu-armv7-env > 3. cd qemu-armv7-env > 4. fetch > https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-1= 4.0-RELEASE-arm-armv7-GENERICSD.img.xz > 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv= =3Dnotrunc > 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv= =3Dnotrunc > 10. cat > start-freebsd-arm.sh > #!/bin/sh > qemu-system-arm \ > -M virt \ > -m 1024 \ > -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > -nographic \ > -serial mon:stdio > ^D > 11. chmod +x start-freebsd-arm.sh > 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD > > But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.= 0: > > Starting devd. > Starting dhclient. > DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc4b36a60 > FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c > r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c > r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 > r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 > > panic: Fatal abort > cpuid =3D 0 > time =3D 1680843057 > KDB: stack backtrace: > #0 0xc035786c at kdb_backtrace+0x48 > #1 0xc02fdd20 at vpanic+0x140 > #2 0xc02fdbe0 at vpanic+0 > #3 0xc06304ac at abort_align+0 > #4 0xc063052c at abort_align+0x80 > #5 0xc063017c at abort_handler+0x480 > #6 0xc060f480 at exception_exit+0 > #7 0xc04a9750 at udp_input+0x288 > #8 0xc0473f54 at ip_input+0x1e0 > #9 0xc04447c0 at netisr_dispatch_src+0xf8 > #10 0xc043bf2c at ether_demux+0x1a4 > #11 0xc043d5e4 at ether_nh_input+0x480 > #12 0xc04447c0 at netisr_dispatch_src+0xf8 > #13 0xc043c404 at ether_input+0x50 > #14 0xc01c0838 at vtnet_rx_vq_process+0x880 > #15 0xc01b70d0 at vtpci_intx_intr+0xac > #16 0xc02b87f0 at ithread_loop+0x2ec > #17 0xc02b465c at fork_exit+0xc0 > Uptime: 19s > > I don't know if this is a problem with qemu or FreeBSD's kernel... > > Warner > > On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto > wrote: > >> I've asked some help on the channel #arm on Reddit and someone replied : >> >> >> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_ar= m32_bit_as_domu_with/ >> >> Maybe his answer can be useful to understand why it does not work. >> >> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini < >> sstabellini@kernel.org> wrote: >> >>> +Michal >>> >>> Hi Mario, >>> >>> I am not sure about booting FreeBSD, but I am certain that u-boot works >>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>> file: >>> >>> name=3D"test" >>> kernel=3D"u-boot.bin" >>> extra =3D "console=3Dhvc0" >>> memory=3D256 >>> vcpus=3D1 >>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> >>> I don't know for sure if you can boot FreeBSD but you should definitely >>> be able to see the u-boot command line prompt. The fact that you are >>> getting this message: >>> >>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader >>> found: Invalid kernel >>> >>> Means that something is not right in the u-boot configuration or u-boot >>> build. Michal and Artem (CCed) might know more. From what I recall, >>> there was nothing special required to get u-boot.bin to boot as domU >>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>> >>> Cheers, >>> >>> Stefano >>> >>> >>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>> > ....I see that some other interesting files have been produced by >>> u-boot when I have compiled it : >>> > >>> > u-boot >>> > u-boot.lds >>> > u-boot.bin >>> > u-boot.map >>> > u-boot-nodtb.bin >>> > u-boot.dtb >>> > u-boot.srec >>> > u-boot-dtb.bin >>> > u-boot.sym >>> > >>> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >>> > >>> > >>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto >>> wrote: >>> > Hello to everyone. >>> > >>> > I have compiled the needed u-boot.bin from scratch using this >>> procedure : >>> > >>> > # git clone https://github.com/u-boot/u-boot.git >>> > # cd u-boot >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig= : >>> this line generates the file .config >>> > # nano .config and I've added these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > the uboot-bin file is generated with this command : >>> > >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>> > >>> > At this point,I took a look inside the .config file and I saw that th= e >>> parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>> > some reason,it is not accepted and this could be a problem.... >>> > >>> > These are the xen config files that I've used : >>> > >>> > nano freebsd.cfg >>> > >>> > name=3D"test" >>> > kernel=3D"u-boot.bin" >>> > extra =3D "console=3Dhvc0" >>> > memory=3D256 >>> > vcpus=3D1 >>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> > >>> > nano start-freebsd >>> > >>> > xl create freebsd.cfg >>> > xl console freebsd >>> > >>> > This is what happens when I launch the vm : >>> > >>> > # ./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 >>> 1:cannot (re-)build domain: -3 >>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >>> 1:Non-existent domain >>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >>> 1:Unable to destroy guest >>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >>> 1:Destruction of domain failed >>> > freebsd is an invalid domain identifier (rc=3D-6) >>> > >>> > >>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > So,ok,I should have said "the second u-boot" ; since the first >>> u-boot binary is the "u-boot binary located in the RO >>> > memory" of the Chromebook". Sorry for the confusion. >>> > >>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > ---> There are no specific options in u-boot devoted to FreeBSD >>> > >>> > This is an important factor. So,what about if,instead of compiling a >>> new version of u-boot on the partition 2,I will >>> > recompile the u-boot customized version created by the virtual open >>> system in 2014,that should be installed on the first >>> > partition ? It could work if there are no differences between the >>> u-boot that should boot Linux and the u-boot that >>> > should boot FreeBSD. >>> > >>> > Can you give a look at the u-boot source code created by virtual open >>> systems ? You can find it on my google drive : >>> > >>> > >>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?= usp=3Dsharing >>> > >>> > I need to understand if I can recompile it without problem so that it >>> can satisfy my needs (the ability of the file >>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano >>> Stabellini,the xen developer that suggested to me >>> > what I could do to have FreeBSD virtualized under Xen on my Arm >>> Chromebook) ; otherwise the risk is to find later >>> > problems that will make me troubles and that I will not able to fix. >>> > >>> > I gave a look at the virtual open system u-boot and I didn't see any >>> arndale_defconfig inside. So,If I have understood >>> > correctly,I should put that file inside the root of the u-boot source >>> code,let's say here : >>> > >>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>> > >>> > .checkpatch.conf README doc >>> net >>> > .git api drivers >>> onenand_ipl >>> > .gitignore arch dts >>> post >>> > COPYING board examples >>> rules.mk >>> > CREDITS boards.cfg fs >>> scripts >>> > MAINTAINERS common include >>> snapshot.commit >>> > MAKEALL config.mk lib >>> spl >>> > Makefile cros mkconfig >>> test >>> > PRESUBMIT.cfg disk nand_spl >>> tools >>> > >>> > and I should do : make and make install ? and the file I >>> need,u-boot.bin will be generated ? >>> > >>> > I didn't find any pre made configuration file inside : >>> > >>> > u-boot-vos # find . -type f -name "exynos*" >>> > >>> > ./include/exynos-fb.h >>> > ./include/configs/exynos5-common.h >>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>> > ./drivers/power/exynos-tmu.c >>> > ./drivers/power/exynos-cpufreq.c >>> > ./drivers/video/exynos-fb.c >>> > ./drivers/spi/exynos_spi.c >>> > ./board/samsung/dts/exynos5250-spring.dts >>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>> > ./board/samsung/dts/exynos5250-snow.dts >>> > ./board/samsung/dts/exynos5250-daisy.dts >>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>> > ./arch/arm/dts/exynos5250.dtsi >>> > ./arch/arm/dts/exynos-periph-id.dtsi >>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>> > >>> > u-boot-vos # find . -type f -name "arndale*" >>> > >>> > For sure I can't use a newer version of u-boot because otherwise the >>> patches needed to bypass the bootloader protections >>> > of the Arm Chromebook (such as a lot of different patches needed to >>> boot correctly Linux) will be broken ; anyway,since >>> > it works,I don't need to use an updated version of u-boot. >>> > >>> > ----> As per my experience, you have to respect these two options, >>> compiling u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > It says that I should use these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > These are the parameters used to configure a Linux kernel. I don't >>> understand what's the relation between the compilation >>> > of a linux kernel and u-boot. In the past I tried to recompile >>> u-boot,but I didn't have the need to set up those >>> > parameters,so I don't know how to do it (but I know how to recompile = a >>> Linux kernel). >>> > >>> > ---> I'm not sure that I'm getting you right, as I don't understand >>> what you mean under "the first u-boot". >>> > >>> > >>> > I'm talking about first u-boot because the whole procedure to boot >>> Linux on the ARM Chromebook,that's explained here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / >>> > >>> > >>> > at some point they say : >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be booted i= n >>> hypervisor mode. Because of this relatively recent >>> > requirement (due to the introduction of the virtualization >>> extensions), up until now all booting methods would boot the >>> > kernel in the standard Supervisor mode. >>> > >>> > For the ARM Chromebook the default boot procedure doesn't allow us to >>> boot in hypervisor mode. Although the laptop's boot >>> > mechanism is based on the frequently used u-boot, the binary is >>> located in RO memory. Fortunately, a chained u-boot >>> > mechanism can be used (i.e. starting another u-boot after the >>> original). We can then enter hypervisor mode from our >>> > custom iteration of u-boot and subsequently load our kernel and >>> userspace. >>> > >>> > So,the first u-boot is the u-boot provided by virtual open >>> systems,that's able to chainload the "u-boot binary located in >>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We don'= t >>> need it if we want to boot Linux with kvm or xen >>> > enabled. >>> > >>> > >>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > I'm not an expert in the topic, I only know, that ARM has >>> divided hardware into two worlds - Secure and >>> > Not-So, strictly limiting any software, running in non-secure >>> world with access to functions and >>> > resources. >>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-ha= rdware-architecture?lang=3Den >>> >>> > >>> > I'm not sure, that I'm getting you right, as I don't understand what >>> you mean under "the first u-boot". >>> > >>> > As I understand, virtualization (HYP) is running in non-secure world( >>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architec= ture/The-System-Level-Programmers--Model/The-Virtualization-Extens >>> > ions), so my guess (only guess!!!), virtualization software has to >>> prepare (configure) HW platform in the way, >>> > that FreeBSD kernel will not lack any resources, required to configur= e >>> MPU, VA, etc. >>> > So, if you lucky to boot virtualizer, which is aware of target OS, >>> that maybe you can boot the kernel. Although, I >>> > doubt, that you need to boot 'second' u-boot to boot the kernel - >>> there is simply ubldr, which you can hook somehow >>> > from virtualizer.... >>> > >>> > Stan >>> > >>> > >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > ---> As I understand, it makes sure that u-boot keeps in secure >>> mode during boot and passes control to >>> > ubldr, which boots FreeBSD kernel, in that mode. >>> > >>> > Can you elaborate your sentence more ? I know that the bootloader >>> secure mode is bypassed by the virtual open >>> > systems u-boot. Are you saying that when the control passes to the >>> second u-boot,it will happen in secure >>> > mode,so that the bypass that happened loading the first u-boot,is >>> annulled ? If this is true,maybe can I boot >>> > FreeBSD using the virtual-open-system custom u-boot ? Is this >>> compatible with FreeBSD ? Where can I find the >>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>> > >>> > >>> > >>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > Hi Mario, >>> > >>> > U-Boot beast is hiding in this den: >>> https://source.denx.de/u-boot/u-boot.git >>> > I took a brief look at your post and it seems to me, that >>> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >>> > your target armv7 32 bit >>> > platform: >>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/K= config?ref_type=3Dheads#L3 >>> > >>> > As for compiling the u-boot, it is a doable task, given that you >>> understand what you are doing. There >>> > are no specific options in u-boot devoted to FreeBSD. It is a boot >>> loader, whose mission to make basic >>> > hardware initialization, read you kernel file from some media into RA= M >>> and then pass it control. >>> > >>> > Basically, you can grab some defconfig, prepared for any other >>> Exynos5250 based board (say, this one: >>> > >>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defc= onfig?ref_type=3Dheads) >>> and adopt >>> > it somehow. >>> > >>> > As per my experience, you have to respect these two options, compilin= g >>> u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > As I understand, it makes sure, that u-boot keeps in secure mode >>> during boot and passes control to >>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lo= t >>> of surprises you may realize. >>> > >>> > Hope, this will help to progress you tasks >>> > Stan >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > Hello. >>> > >>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>> Chromebook. Basically there are >>> > two ways to accomplish this task : >>> > >>> > 1) to write a patch that allows the FreeBSD kernel to boot as a >>> zImage file. This could be >>> > accomplished applying this patch to a specific file that's on >>> the source code of FreeBSD : >>> > >>> > >>> > >>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139147271703= 5f986c979edef0c9 >>> > >>> > >>> > This patch was written by Julien Grall a lot of time ago and no= w >>> it does not work anymore. >>> > This is the reason : >>> > >>> > >>> > 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. >>> And I'm not able to fix it. >>> > >>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer= : >>> > >>> > >>> > I was trying to explain why and how Julien's patch works so tha= t >>> you could be the one >>> > to re-do something similar or fix the patch on the FreeBSD >>> kernel that you are >>> > working with. I am happy to help review and write patches but I >>> don't work with the >>> > FreeBSD kernel so I wouldn't be able to help you quickly. >>> However, I might have a >>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >>> Because U-Boot >>> > definitely boots as Xen on ARM guest firmware/bootloader. You >>> should be able to build >>> > U-Boot and use the U-Boot binary as Xen guest kernel, then >>> U-Boot could load FreeBSD >>> > from disk or network and start it. For instance as domU config >>> file: >>> > >>> > kernel=3D"/home/petalinux/u-boot.bin" >>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>> > >>> > I know it is important to build u-boot with the following confi= g >>> to make it work on >>> > Xen. >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > >>> > This option seems more doable to me according to my knowledge. But I >>> need to understand how to do >>> > it. >>> > >>> > Well,let's say that on the ARM Chromebook I'm forced to use and >>> install a customized version of >>> > u-boot,created by virtual open systems,because it is the only one tha= t >>> allows bypassing its >>> > bootloader protection. You can find more information here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= /?vos=3Dtech >>> > >>> > This is the relevant section to read : >>> > >>> > >>> > Bootloader : >>> > >>> > If you wish to skip this chapter you can download a pre-compile= d >>> binary of the >>> > bootloader: >>> > >>> > >>> > $ wget >>> > >>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv= _u-boot-snow.kpart >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be >>> booted in hypervisor >>> > mode. Because of this relatively recent requirement (due to the >>> introduction of the >>> > virtualization extensions), up until now all booting methods >>> would boot the kernel in >>> > the standard Supervisor mode. For the ARM Chromebook the defaul= t >>> boot procedure >>> > doesn't allow us to boot in hypervisor mode. Although the >>> laptop's boot mechanism is >>> > based on the frequently used u-boot, the binary is located in R= O >>> memory. Fortunately, >>> > a chained u-boot mechanism can be used (i.e. starting another >>> u-boot after the >>> > original). We can then enter hypervisor mode from our custom >>> iteration of u-boot and >>> > subsequently load our kernel and userspace. >>> > >>> > Checkout the needed u-boot code : >>> > >>> > >>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>> u-boot$ >>> > ./scripts/build.sh >>> > >>> > >>> > If successful, a message about how to copy the bootloader on th= e >>> USB flash disk or SD >>> > card will appear. We will use it later when preparing the boot >>> medium to start our >>> > system. If you have followed the Setting up the boot medium >>> chapter and you have a >>> > prepared boot device, then you can update u-boot by running : >>> > >>> > >>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>> > >>> > >>> > >>> > so,the needed u-boot that we must use should be installed on the firs= t >>> partition of the sd card. >>> > >>> > There is another relevant section to read : >>> > >>> > >>> > Setting up the boot medium >>> > >>> > Now it is time to copy all the relevant files that we created i= n >>> the previous >>> > chapters,and use them to boot Chromebook with a different kerne= l >>> and OS. In all these >>> > examples the device /dev/sdX is used. Take extra care to change >>> the examples to the >>> > device that you have attached. Insert the boot medium on your >>> workstation and >>> > carefully execute the following step. First we need to properly >>> format the boot >>> > medium. >>> > >>> > In the uboot source directory : >>> > >>> > >>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>> > >>> > >>> > This will erase all data and create 4 partitions in the medium, >>> along with copying >>> > the u-boot binary to the first partition: >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > With u-boot being copied, next is the kernel image and DTB file= . >>> From the kernel >>> > source execute : >>> > >>> > >>> > $ mkdir ../mnt/ >>> > $ sudo mount /dev/sdX3 ../mnt/ >>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>> > $ sudo umount /dev/sdX3 >>> > >>> > >>> > Finally, we have to copy the Ubuntu userspace filesystem that w= e >>> created earlier: >>> > >>> > >>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo >>> umount /dev/sdX4 >>> > >>> > >>> > >>> > Now,my idea is to chainload the already chain loaded u-boot created b= y >>> V.O.S to the new u-boot >>> > that we need for booting FreeBSD and that can be installed in the >>> partition n.2,as shown in this >>> > scheme,because it is not used : >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>> bit,compatible with FreeBSD on >>> > this partition) >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > Take in consideration that default boot string is hardcoded here,in >>> the snow.h file of the custom >>> > u-boot created by VOS : >>> > >>> > >>> > >>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs= /snow.h#L101 >>> > >>> > >>> > and it needs to be recompiled because it should point to the partitio= n >>> n.2,where I will install >>> > the u-boot files as explained here : >>> > >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > >>> > I have some questions to ask before I start working on this. >>> > >>> > 1) The xen developer said : >>> > >>> > >>> > You should be able to build U-Boot and use the U-Boot binary as >>> Xen guest kernel... >>> > >>> > >>> > >>> > where is the u-boot binary,according to this document ? >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > I don't see it. >>> > >>> > >>> > 2) where is the source code of the file that I can get here : >>> > >>> > >>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/= nv_uboot-snow-simplefb.kpart.bz2 >>> > >>> > I need the source code if I want to recompile u-boot so that it can >>> point to the partition 4. >>> > >>> > Maybe it can be found on this link : >>> > >>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>> > >>> > but it can't be opened.... >>> > >>> > >>> > 3) in this specific scenario the source code of u-boot should run on >>> arm 32 bit,not on arm >>> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's >>> powered by a Samsung Exynos >>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>> > >>> > >>> > 4) I'm not sure if I can chainload the customized u-boot created by >>> V.O.S that should be >>> > installed on the first partition with the u-boot tailored for booting >>> FreeBSD that should be >>> > installed on the partition 2.... >>> > >>> > >>> > 5) the xen developer said that u-boot should be compiled enabling thi= s >>> option : >>> > >>> > >>> > Code: >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > Well,can you provide some good source that can help me to understand >>> how I can recompile u-boot >>> > for FreeBSD ? thanks. >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >> >> >> >> -- >> Mario. >> > --=20 Mario. --000000000000e38930060cf1d01d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

@Warner Losh : thanks for your help with the virtualization of FreeB= SD with qemu,but I have already achieved this goal.=C2=A0
The ima= ge file that I'm using (FreeBSD-13.2-RELEASE-a= rmv7.img,raw,xvda) is already able to boot with qemu-kvm on my ARM C= hromebook. We have also fixed the virtio-net driver bug on the FreeBSD foru= m,on this post started by me :


Booting FreeBSD as= domU using Xen instead of qemu-kvm is another story.

<= div class=3D"gmail_quote">
On Wed, Dec= 20, 2023 at 5:52=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
I'd think you&= #39;d need the right virtualization loader. I'm not entirely sure the u= -boot.bin you've been creating is for a dom-u..=C2=A0
If I mi= sunderstood, then the below isn't good advice. Chain booting the u-boot= , the first u-boot initializes things so you want
to start with s= tage after the SPL. But the different error messages suggest that it's = trying to reboot with kexec, which
isn't supported on armv7 a= t the moment.

If you could boot in kvm, I thin= k that the following would work....=C2=A0 Though I'm not entirely sure = how to
specify the two .fd files in your setup. The use of qemu i= s to have an easy env to debug things... I don't
have a chrom= ebook to try...

My first instinct would be to = try qemu on x86 (this is the first step of many to get to your destination)= .

If you could boot the GENERIC_SD image that we p= roduce using qemu + edk2-arm-code.fd that would
be a huge first s= tep. This will give you the boot loader, I believe, to boot in the VM that = you need better
than going via the u-boot route. Since you are bo= oting in a virtualized environment, I think it wouldn't
matte= r which one :).

So, I did the following to boot th= e virtualized armv7 FreeBSD environment, following a post on the forums I f= ound and knew to have the right recipe:

1. pkg install qemu
=
2. mkdir qemu-armv7-env
3. cd qemu-armv7-env
5. xz -d -T 0 FreeBSD-14.0-R= ELEASE-arm-armv7-GENERICSD.img.xz
6. dd if=3D/dev/zero of=3Dpflas= h0.img bs=3D1m count=3D64
7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m = count=3D64
8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash= 0.img conv=3Dnotrunc
9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd o= f=3Dpflash1.img conv=3Dnotrunc
10. cat > start-freebsd-arm.sh<= /div>
#!/bin/sh
qemu-system-arm \
=C2=A0 -M virt \
=C2=A0 -m 1= 024 \
=C2=A0 -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly= =3Don \
=C2=A0 -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \
= =C2=A0 -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \
=C2=A0 -n= ographic \
=C2=A0 -serial mon:stdio
^D
11. chmod +x = start-freebsd-arm.sh
12. ./start-freebsd-arm.sh FreeBSD-14.0-REL= EASE-arm-armv7-GENERICSD

But I hit a snag with thi= s on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.0:

Starting devd.
Starting dhclient.
DHCPDISCOVER on vtnet0 to 255.255.= 255.255 port 67 interval 7
Fatal kernel mode data abort: 'Alignment = Fault' on read
trapframe: 0xc4b36a60
FSR=3D00000001, FAR=3Ddd9670= 1a, spsr=3D20000013
r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 = =3Dc4b36b4c
r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D000002= 2c
r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90
r12= =3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750

panic: F= atal abort
cpuid =3D 0
time =3D 1680843057
KDB: stack backtrace:#0 0xc035786c at kdb_backtrace+0x48
#1 0xc02fdd20 at vpanic+0x140
#= 2 0xc02fdbe0 at vpanic+0
#3 0xc06304ac at abort_align+0
#4 0xc063052c= at abort_align+0x80
#5 0xc063017c at abort_handler+0x480
#6 0xc060f4= 80 at exception_exit+0
#7 0xc04a9750 at udp_input+0x288
#8 0xc0473f54= at ip_input+0x1e0
#9 0xc04447c0 at netisr_dispatch_src+0xf8
#10 0xc0= 43bf2c at ether_demux+0x1a4
#11 0xc043d5e4 at ether_nh_input+0x480
#1= 2 0xc04447c0 at netisr_dispatch_src+0xf8
#13 0xc043c404 at ether_input+0= x50
#14 0xc01c0838 at vtnet_rx_vq_process+0x880
#15 0xc01b70d0 at vtp= ci_intx_intr+0xac
#16 0xc02b87f0 at ithread_loop+0x2ec
#17 0xc02b465c= at fork_exit+0xc0
Uptime: 19s

I don't know= if this is a problem with qemu or FreeBSD's kernel...

Warner

On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Mari= etto <mariet= to2008@gmail.com> wrote:
I've asked some help on the chann= el #arm on Reddit and someone replied :

Maybe his answer can be useful to understand why it does not wo= rk.

On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini = <sstabellini= @kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/doc= umentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den=
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.


--
Mario.
--000000000000e38930060cf1d01d-- From nobody Wed Dec 20 16:57:55 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwKYz11RVz5589C for ; Wed, 20 Dec 2023 17:00:23 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SwKYx4G2xz4q5C for ; Wed, 20 Dec 2023 17:00:21 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mailgate.us header.s=mail header.b=ZTHX6AOm; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from [10.43.199.91] (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 51FA633930 for ; Wed, 20 Dec 2023 20:00:13 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1703091614; bh=OrwJ+kYVe7fKSg7eDspQxYsUMXtC6QZ7cN5TSUFxrwQ=; h=In-Reply-To:References:Subject:From:Date:CC; b=ZTHX6AOm9aWRjWSlPu7oaaIoklb1QJL9lNC0E6fB+WN6zIxu9whG+4PVf9X2zQovK LlwtEG58kKqNSeyUvX16o5rpELktRHr0GE2Z5bvZNDxxf5VAtYI1R28CWECpy1NruW CkIUkFIze/I2/ik3atEsQmRhB54ay9RoBV3kjsBE= In-Reply-To: References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> X-Referenced-Uid: 71554 Thread-Topic: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook User-Agent: Android X-Is-Generated-Message-Id: true List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VCBWAXETIA7O4UQHSJNV7WPWZ88ZGZ" Content-Transfer-Encoding: 7bit Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook From: Stanislav Silnicki Date: Wed, 20 Dec 2023 18:57:55 +0200 CC: freebsd-arm@freebsd.org Message-ID: <54b70672-9ea4-40e2-b346-b579536c0e5c@mailgate.us> X-Spamd-Result: default: False [-0.39 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; URI_COUNT_ODD(1.00)[69]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mailgate.us:s=mail]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[mailgate.us]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SwKYx4G2xz4q5C X-Spamd-Bar: / ------VCBWAXETIA7O4UQHSJNV7WPWZ88ZGZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Mario, you can not edit =2Econfig byhand=2E You have to consider these opti= ons in some _defconfig and then reconfigure/tecompile =E2=81=A3Get BlueMai= l for Android =E2=80=8B On Dec 19, 2023, 5:29 PM, at 5:29 PM, Mario Mariet= to wrote: >Hello to everyone=2E > >I have compil= ed the needed u-boot=2Ebin from scratch using this procedure >: > ># git cl= one https://github=2Ecom/u-boot/u-boot=2Egit ># cd u-boot ># ARCH=3Darm CRO= SS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig : >this >line generat= es the file =2Econfig ># nano =2Econfig and I've added these parameters : >= >CONFIG_ARMV7_NONSEC=3Dn >CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > >the uboo= t-bin file is generated with this command : > ># ARCH=3Darm CROSS_COMPILE= =3Darm-linux-gnueabihf- make > >At this point,I took a look inside the =2Ec= onfig file and I saw that the >parameter "CONFIG_ARMV7_NONSEC=3Dn" has been= removed=2E So,for some >reason,it >is not accepted and this could be a pro= blem=2E=2E=2E=2E > >These are the xen config files that I've used : > >nano= freebsd=2Ecfg > >name=3D"test" >kernel=3D"u-boot=2Ebin" >extra =3D "consol= e=3Dhvc0" >memory=3D256 >vcpus=3D1 >disk =3D [ 'FreeBSD-13=2E2-RELEASE-armv= 7=2Eimg,raw,xvda' ] > >nano start-freebsd > >xl create freebsd=2Ecfg >xl co= nsole freebsd > >This is what happens when I launch the vm : > ># =2E/start= -freebsd > >Parsing config from freebsd=2Ecfg >xc: error: panic: xg_dom_cor= e=2Ec:689: xc_dom_find_loader: no loader >found: >Invalid kernel >libxl: er= ror: libxl_dom=2Ec:571:libxl__build_dom: xc_dom_parse_image >failed >libxl:= error: libxl_create=2Ec:1640:domcreate_rebuild_done: Domain >1:cannot >(re= -)build domain: -3 >libxl: error: libxl_domain=2Ec:1183:libxl__destroy_domi= d: Domain >1:Non-existent domain >libxl: error: libxl_domain=2Ec:1137:domai= n_destroy_callback: Domain >1:Unable >to destroy guest >libxl: error: libxl= _domain=2Ec:1064:domain_destroy_cb: Domain >1:Destruction >of domain failed= >freebsd is an invalid domain identifier (rc=3D-6) > > >On Mon, Dec 18, 20= 23 at 12:39=E2=80=AFPM Mario Marietto >wrote: > >> = So,ok,I should have said "the second u-boot" ; since the first u-boot >> bi= nary is the "u-boot binary located in the RO memory" of the >Chromebook"=2E= >> Sorry for the confusion=2E >> >> On Mon, Dec 18, 2023 at 12:35=E2=80=AF= PM Mario Marietto > >> wrote: >> >>> ---> There a= re no specific options in u-boot devoted to FreeBSD >>> >>> This is an impo= rtant factor=2E So,what about if,instead of compiling a >new >>> version of= u-boot on the partition 2,I will recompile the u-boot >customized >>> vers= ion created by the virtual open system in 2014,that should be >installed >>= > on the first partition ? It could work if there are no differences >betwe= en >>> the u-boot that should boot Linux and the u-boot that should boot >F= reeBSD=2E >>> >>> Can you give a look at the u-boot source code created by = virtual >open >>> systems ? You can find it on my google drive : >>> >>> >>= > >https://drive=2Egoogle=2Ecom/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/vi= ew?usp=3Dsharing >>> >>> I need to understand if I can recompile it without= problem so that >it can >>> satisfy my needs (the ability of the file u-bo= ot=2Ebin to boot FreeBSD >as >>> domU under Xen,as explained by Stefano Sta= bellini,the xen developer >that >>> suggested to me what I could do to have= FreeBSD virtualized under >Xen on my >>> Arm Chromebook) ; otherwise the r= isk is to find later problems that >will >>> make me troubles and that I wi= ll not able to fix=2E >>> >>> I gave a look at the virtual open system u-bo= ot and I didn't see any >arndale_defconfig >>> inside=2E So,If I have under= stood correctly,I should put that file >inside the >>> root of the u-boot s= ource code,let's say here : >>> >>> marietto:/home/marietto/Desktop/Files/u= -boot_FreeBSD/u-boot-vos # ls >>> >>> =2Echeckpatch=2Econf README = doc >>> net >>> =2Egit = api drivers >>> onenand_ipl >>> =2Egi= tignore arch dts >>> po= st >>> COPYING board examples >>> rules= =2Emk >>> CREDITS boards=2Ecfg fs >>> = scripts >>> MAINTAINERS common in= clude >>> snapshot=2Ecommit >>> MAKEALL con= fig=2Emk lib >>> spl >>> Makefile = cros mkconfig >>> test >>> PRESUB= MIT=2Ecfg disk nand_spl >>> too= ls >>> >>> and I should do : make and make install ? and the file I >need,u= -boot=2Ebin >>> will be generated ? >>> >>> I didn't find any pre made conf= iguration file inside : >>> >>> u-boot-vos # find =2E -type f -name "exynos= *" >>> >>> =2E/include/exynos-fb=2Eh >>> =2E/include/configs/exynos5-common= =2Eh >>> =2E/doc/device-tree-bindings/spi/exynos-spi=2Etxt >>> =2E/doc/devi= ce-tree-bindings/usb/exynos-usb=2Etxt >>> =2E/drivers/power/exynos-tmu=2Ec = >>> =2E/drivers/power/exynos-cpufreq=2Ec >>> =2E/drivers/video/exynos-fb=2E= c >>> =2E/drivers/spi/exynos_spi=2Ec >>> =2E/board/samsung/dts/exynos5250-s= pring=2Edts >>> =2E/board/samsung/dts/exynos5250-smdk5250=2Edts >>> =2E/boa= rd/samsung/dts/exynos5250-snow=2Edts >>> =2E/board/samsung/dts/exynos5250-d= aisy=2Edts >>> =2E/arch/arm/include/asm/arch-exynos5/exynos-cpufreq=2Eh >>>= =2E/arch/arm/include/asm/arch-exynos5/exynos-tmu=2Eh >>> =2E/arch/arm/dts/= exynos5250=2Edtsi >>> =2E/arch/arm/dts/exynos-periph-id=2Edtsi >>> =2E/arch= /arm/cpu/armv7/exynos5/exynos_cache=2Ec >>> >>> u-boot-vos # find =2E -type= f -name "arndale*" >>> >>> For sure I can't use a newer version of u-boot = because otherwise the >>> patches needed to bypass the bootloader protectio= ns of the Arm >Chromebook >>> (such as a lot of different patches needed to= boot correctly Linux) >will be >>> broken ; anyway,since it works,I don't = need to use an updated >version of >>> u-boot=2E >>> >>> ----> As per my ex= perience, you have to respect these two options, >>> compiling u-boot for F= reeBSD: >>> >https://github=2Ecom/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment >>> >>> It says that I should use thes= e parameters : >>> >>> CONFIG_ARMV7_NONSEC=3Dn >>> CONFIG_EFI_GRUB_ARM32_WO= RKAROUND=3Dy >>> >>> These are the parameters used to configure a Linux ker= nel=2E I don't >>> understand what's the relation between the compilation o= f a linux >kernel >>> and u-boot=2E In the past I tried to recompile u-boot= ,but I didn't >have the >>> need to set up those parameters,so I don't know= how to do it (but I >know >>> how to recompile a Linux kernel)=2E >>> >>> = >>> ---> I'm not sure that I'm getting you right, as I don't understand >wh= at >>> you mean under "the first u-boot"=2E >>> >>> >>> I'm talking about f= irst u-boot because the whole procedure to boot >Linux >>> on the ARM Chrom= ebook,that's explained here : >>> >>> >http://www=2Evirtualopensystems=2Eco= m/en/solutions/guides/kvm-on-chromebook/ >>> >>> >>> at some point they say= : >>> >>> >>> To be able to run KVM on ARM platforms, the kernel has to be= booted >in >>> hypervisor mode=2E Because of this relatively recent requir= ement (due >to the >>> introduction of the virtualization extensions), up u= ntil now all >booting >>> methods would boot the kernel in the standard Sup= ervisor mode=2E >>> >>> For the ARM Chromebook the default boot procedure d= oesn't allow us >to >>> boot in hypervisor mode=2E Although the laptop's bo= ot mechanism is >based on >>> the frequently used u-boot, the binary is loc= ated in RO memory=2E >>> Fortunately, a chained u-boot mechanism can be use= d (i=2Ee=2E starting >another >>> u-boot after the original)=2E We can then= enter hypervisor mode from >our >>> custom iteration of u-boot and subsequ= ently load our kernel and >userspace=2E >>> >>> So,the first u-boot is the = u-boot provided by virtual open >systems,that's >>> able to chainload the "= u-boot binary located in RO memory" , that >does not >>> boot Chrome OS in = hypervisor mode=2E We don't need it if we want to >boot >>> Linux with kvm = or xen enabled=2E >>> >>> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav= Silnicki < >>> stanislav=2Esilnicki@mailgate=2Eus> wrote: >>> >>>> I'm not= an expert in the topic, I only know, that ARM has divided >>>> hardware in= to two worlds - Secure and Not-So, strictly limiting any >>>> software, run= ning in non-secure world with access to functions and >>>> resources=2E >>>= > >https://developer=2Earm=2Ecom/documentation/den0013/d/Security/TrustZone= -hardware-architecture?lang=3Den >>>> >>>> I'm not sure, that I'm getting y= ou right, as I don't understand >what you >>>> mean under "the first u-boot= "=2E >>>> >>>> As I understand, virtualization (HYP) is running in non-secu= re >world ( >>>> >https://developer=2Earm=2Ecom/documentation/ddi0406/c/Sys= tem-Level-Architecture/The-System-Level-Programmers--Model/The-Virtualizati= on-Extensions), >>>> so my guess (only guess!!!), virtualization software h= as to prepare >>>> (configure) HW platform in the way, that FreeBSD kernel = will not >lack any >>>> resources, required to configure MPU, VA, etc=2E >>= >> So, if you lucky to boot virtualizer, which is aware of target OS, >that= >>>> maybe you can boot the kernel=2E Although, I doubt, that you need to = >boot >>>> 'second' u-boot to boot the kernel - there is simply ubldr, whic= h >you can >>>> hook somehow from virtualizer=2E=2E=2E=2E >>>> >>>> Stan >>= >> >>>> >>>> >>>> Mario Marietto wrote: >>>> >>>> >>>> ---> As I understand= , it makes sure that u-boot keeps in secure >mode >>>> during boot and pass= es control to ubldr, which boots FreeBSD >kernel, in >>>> that mode=2E >>>>= >>>> Can you elaborate your sentence more ? I know that the bootloader >se= cure >>>> mode is bypassed by the virtual open systems u-boot=2E Are you sa= ying >that >>>> when the control passes to the second u-boot,it will happen= in >secure >>>> mode,so that the bypass that happened loading the first u-= boot,is >annulled >>>> ? If this is true,maybe can I boot FreeBSD using the= >virtual-open-system >>>> custom u-boot ? Is this compatible with FreeBSD = ? Where can I find >the >>>> u-boot=2Ebin that the xen developer talked abo= ut ? thanks bro'=2E >>>> >>>> >>>> >>>> On Sun, Dec 17, 2023 at 12:35=E2=80= =AFAM Stanislav Silnicki < >>>> stanislav=2Esilnicki@mailgate=2Eus> wrote: = >>>> >>>>> Hi Mario, >>>>> >>>>> U-Boot beast is hiding in this den: >>>>>= https://source=2Edenx=2Ede/u-boot/u-boot=2Egit >>>>> I took a brief look a= t your post and it seems to me, that option >>>>> CONFIG_CMO_BY_VA_ONLY is = irrelevant to your target armv7 32 bit >>>>> platform: >>>>> >https://sourc= e=2Edenx=2Ede/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_ty= pe=3Dheads#L3 >>>>> >>>>> As for compiling the u-boot, it is a doable task,= given that you >>>>> understand what you are doing=2E There are no specifi= c options in >u-boot >>>>> devoted to FreeBSD=2E It is a boot loader, whose= mission to make >basic >>>>> hardware initialization, read you kernel file= from some media into >RAM and >>>>> then pass it control=2E >>>>> >>>>> Ba= sically, you can grab some defconfig, prepared for any other >>>>> Exynos52= 50 based board (say, this one: >>>>> >https://source=2Edenx=2Ede/u-boot/u-= boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads) >>>>> and ad= opt it somehow=2E >>>>> >>>>> As per my experience, you have to respect the= se two options, >compiling >>>>> u-boot for FreeBSD: >>>>> >https://github= =2Ecom/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD= _Fragment >>>>> >>>>> As I understand, it makes sure, that u-boot keeps in = secure mode >during >>>>> boot and passes control to ubldr, which boots Fre= BSD kernel, in >that mode=2E >>>>> Otherwise, there a lot of surprises you = may realize=2E >>>>> >>>>> Hope, this will help to progress you tasks >>>>>= Stan >>>>> >>>>> Mario Marietto wrote: >>>>> >>>>> >>>>> Hello=2E >>>>> >>= >>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >Chromebook= =2E >>>>> Basically there are two ways to accomplish this task : >>>>> >>>>= > 1) to write a patch that allows the FreeBSD kernel to boot as a >zImage >= >>>> file=2E This could be accomplished applying this patch to a specific >= file >>>>> that's on the source code of FreeBSD : >>>>> >>>>> >>>>> >>>>> >= https://xenbits=2Exen=2Eorg/gitweb/?p=3Dp=2E=2E=2E8;hb=3D0782e25d98cc139147= 2717035f986c979edef0c9 >>>>> > >>>>> >>>>> >>>>> This patch was written by Julien Grall a lot of ti= me ago and now >it >>>>> does not work anymore=2E This is the reason : >>>>= > >>>>> >>>>> It appears FreeBSD-CURRENT removed the last step converting t= he >kernel >>>>> file to kernel=2Ebin=2E The patch can be readily rebased, = but without >>>>> kernel=2Ebin that doesn't do too much=2E >>>>> >>>>> >>>>= > >>>>> So,without a rebase of that patch the first option is not >applicab= le=2E >>>>> And I'm not able to fix it=2E >>>>> >>>>> 2) booting FreeBSD us= ing U-Boot,as explained to me by a xen >developer : >>>>> >>>>> >>>>> I was= trying to explain why and how Julien's patch works so that >you >>>>> coul= d be the one to re-do something similar or fix the patch on >the FreeBSD >>= >>> kernel that you are working with=2E I am happy to help review and >writ= e >>>>> patches but I don't work with the FreeBSD kernel so I wouldn't be >= able to >>>>> help you quickly=2E However, I might have a suggestion=2E Do = you know >if >>>>> FreeBSD can be booted by U-Boot ? Because U-Boot definit= ely boots >as Xen on >>>>> ARM guest firmware/bootloader=2E You should be a= ble to build U-Boot >and use >>>>> the U-Boot binary as Xen guest kernel, t= hen U-Boot could load >FreeBSD from >>>>> disk or network and start it=2E F= or instance as domU config file: >>>>> >>>>> kernel=3D"/home/petalinux/u-bo= ot=2Ebin" >>>>> disk =3D [ '/home/petalinux/test=2Eimg,raw,xvda' ] >>>>> >>= >>> I know it is important to build u-boot with the following config >to >>= >>> make it work on Xen=2E >>>>> >>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> >>>>= > >>>>> >>>>> This option seems more doable to me according to my knowledge= =2E But >I >>>>> need to understand how to do it=2E >>>>> >>>>> Well,let's = say that on the ARM Chromebook I'm forced to use and >install >>>>> a custo= mized version of u-boot,created by virtual open >systems,because it >>>>> i= s the only one that allows bypassing its bootloader protection=2E >You can = >>>>> find more information here : >>>>> >>>>> >>>>> >http://www=2Evirtualo= pensystems=2Ecom/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech >>>>> >>= >>> This is the relevant section to read : >>>>> >>>>> >>>>> Bootloader : >= >>>> >>>>> If you wish to skip this chapter you can download a pre-compiled= >binary >>>>> of the bootloader: >>>>> >>>>> >>>>> $ wget >>>>> >http://ww= w=2Evirtualopensystems=2Ecom/downloads/guides/kvm_on_chromebook/nv_u-boot-s= now=2Ekpart >>>>> >>>>> >>>>> To be able to run KVM on ARM platforms, the k= ernel has to be >booted in >>>>> hypervisor mode=2E Because of this relativ= ely recent requirement >(due to the >>>>> introduction of the virtualizatio= n extensions), up until now all >booting >>>>> methods would boot the kerne= l in the standard Supervisor mode=2E For >the ARM >>>>> Chromebook the defa= ult boot procedure doesn't allow us to boot in >>>>> hypervisor mode=2E Alt= hough the laptop's boot mechanism is based on >the >>>>> frequently used u-= boot, the binary is located in RO memory=2E >Fortunately, a >>>>> chained u= -boot mechanism can be used (i=2Ee=2E starting another u-boot >after >>>>> = the original)=2E We can then enter hypervisor mode from our custom >iterati= on >>>>> of u-boot and subsequently load our kernel and userspace=2E >>>>> = >>>>> Checkout the needed u-boot code : >>>>> >>>>> >>>>> $ git clone git:/= /github=2Ecom/virtualopensystems/u-boot=2Egit$ cd >u-boot$ >>>>> =2E/script= s/build=2Esh >>>>> >>>>> >>>>> If successful, a message about how to copy t= he bootloader on the >USB >>>>> flash disk or SD card will appear=2E We wil= l use it later when >preparing the >>>>> boot medium to start our system=2E= If you have followed the Setting >up the >>>>> boot medium chapter and you= have a prepared boot device, then you >can >>>>> update u-boot by running = : >>>>> >>>>> >>>>> $ sudo dd if=3Dnv_uboot-snow=2Ekpart of=3D/dev/sdX1 >>>= >> >>>>> >>>>> >>>>> so,the needed u-boot that we must use should be instal= led on the >first >>>>> partition of the sd card=2E >>>>> >>>>> There is an= other relevant section to read : >>>>> >>>>> >>>>> Setting up the boot medi= um >>>>> >>>>> Now it is time to copy all the relevant files that we create= d in >the >>>>> previous chapters,and use them to boot Chromebook with a di= fferent >kernel >>>>> and OS=2E In all these examples the device /dev/sdX i= s used=2E Take >extra care >>>>> to change the examples to the device that = you have attached=2E >Insert the >>>>> boot medium on your workstation and = carefully execute the >following step=2E >>>>> First we need to properly fo= rmat the boot medium=2E >>>>> >>>>> In the uboot source directory : >>>>> >= >>>> >>>>> $ sudo =2E/scripts/sdcard=2Esh /dev/sdX >>>>> >>>>> >>>>> This w= ill erase all data and create 4 partitions in the medium, >along >>>>> with= copying the u-boot binary to the first partition: >>>>> >>>>> >>>>> Partit= ion 1 =3D ChromeOS signed binary (V=2EO=2ES chained u-boot) >>>>> Partition= 2 =3D not used >>>>> Partition 3 =3D EXT2 partition for u-boot files (uIma= ge and >>>>> exynos5250-snow=2Edtb) >>>>> Partition 4 =3D EXT4 partition fo= r userspace files >>>>> >>>>> >>>>> With u-boot being copied, next is the k= ernel image and DTB file=2E >From >>>>> the kernel source execute : >>>>> >= >>>> >>>>> $ mkdir =2E=2E/mnt/ >>>>> $ sudo mount /dev/sdX3 =2E=2E/mnt/ >>>= >> $ sudo cp arch/arm/boot/uImage =2E=2E/mnt/ >>>>> $ sudo cp arch/arm/boot= /dts/exynos5250-snow=2Edtb =2E=2E/mnt/ >>>>> $ sudo umount /dev/sdX3 >>>>> = >>>>> >>>>> Finally, we have to copy the Ubuntu userspace filesystem that w= e >>>>> created earlier: >>>>> >>>>> >>>>> $ sudo mount /dev/sdX4 mnt/$ sud= o cp -a =2E/precise/* mnt/$ sudo >umount >>>>> /dev/sdX4 >>>>> >>>>> >>>>> = >>>>> Now,my idea is to chainload the already chain loaded u-boot >created = by >>>>> V=2EO=2ES to the new u-boot that we need for booting FreeBSD and t= hat >can be >>>>> installed in the partition n=2E2,as shown in this scheme,= because it >is not >>>>> used : >>>>> >>>>> >>>>> Partition 1 =3D ChromeOS = signed binary (V=2EO=2ES chained u-boot) >>>>> Partition 2 =3D not used (ma= ybe we can install the u-boot for arm 32 >>>>> bit,compatible with FreeBSD = on this partition) >>>>> Partition 3 =3D EXT2 partition for u-boot files (u= Image and >>>>> exynos5250-snow=2Edtb) >>>>> Partition 4 =3D EXT4 partition= for userspace files >>>>> >>>>> >>>>> Take in consideration that default b= oot string is hardcoded >here,in the >>>>> snow=2Eh file of the custom u-bo= ot created by VOS : >>>>> >>>>> >>>>> >>>>> >https://github=2Ecom/virtualop= ensyste=2E=2E=2E18a39b6c177dff58a/include/configs/snow=2Eh#L101 >>>>> > >>>>> >>>>> >>>>> and it need= s to be recompiled because it should point to the >partition >>>>> n=2E2,wh= ere I will install the u-boot files as explained here : >>>>> >>>>> >>>>> h= ttps://wiki=2Efreebsd=2Eorg/arm/Chromebook >>>>> >>>>> >>>>> I have some qu= estions to ask before I start working on this=2E >>>>> >>>>> 1) The xen dev= eloper said : >>>>> >>>>> >>>>> You should be able to build U-Boot and use = the U-Boot binary as >Xen >>>>> guest kernel=2E=2E=2E >>>>> >>>>> >>>>> >>>= >> where is the u-boot binary,according to this document ? >>>>> >>>>> http= s://wiki=2Efreebsd=2Eorg/arm/Chromebook >>>>> >>>>> I don't see it=2E >>>>>= >>>>> >>>>> 2) where is the source code of the file that I can get here : = >>>>> >>>>> >>>>> >http://commondatastorage=2Egoogleapis=2Ecom/chromeos-loc= almirror/distfiles/nv_uboot-snow-simplefb=2Ekpart=2Ebz2 >>>>> >>>>> I need = the source code if I want to recompile u-boot so that it >can >>>>> point t= o the partition 4=2E >>>>> >>>>> Maybe it can be found on this link : >>>>>= >>>>> http://linux-exynos=2Eorg/dist/chromebook/nv_uboot/ >>>>> >>>>> but = it can't be opened=2E=2E=2E=2E >>>>> >>>>> >>>>> 3) in this specific scenar= io the source code of u-boot should run >on >>>>> arm 32 bit,not on arm 64,= because I have the Samsung Chromebook >"SNOW" model >>>>> XE303C12,that's p= owered by a Samsung Exynos 5250 (ARMv7 32 bit >Cortex A15) >>>>> Soc=2E >>>= >> >>>>> >>>>> 4) I'm not sure if I can chainload the customized u-boot cre= ated >by >>>>> V=2EO=2ES that should be installed on the first partition wi= th the >u-boot >>>>> tailored for booting FreeBSD that should be installed = on the >partition 2=2E=2E=2E=2E >>>>> >>>>> >>>>> 5) the xen developer said= that u-boot should be compiled enabling >this >>>>> option : >>>>> >>>>> >= >>>> Code: >>>>> >>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> >>>>> >>>>> >>>>> We= ll,can you provide some good source that can help me to >understand >>>>> h= ow I can recompile u-boot for FreeBSD ? thanks=2E >>>>> >>>>> -- >>>>> Mari= o=2E >>>>> >>>>> >>>> >>>> -- >>>> Mario=2E >>>> >>>> >>> >>> -- >>> Mario= =2E >>> >> >> >> -- >> Mario=2E >> > > >-- >Mario=2E ------VCBWAXETIA7O4UQHSJNV7WPWZ88ZGZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mario, you c= an not edit =2Econfig byhand=2E You have to consider these options in some = _defconfig and then reconfigure/tecompile

<= !-- tmjah_g_1299s -->Get BlueMail for Android=
On Dec 19, 2023, at 5:29 PM, Mario Marietto <marietto2008@gmail=2Ecom> wr= ote:
Hello to everyone=2E

I have compiled the needed u-boot=2Ebin from= scratch using this procedure :

= # cd u-boot
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_def= config : this line generates the file =2Econfig
= # nano =2Econfig and I've added these par= ameters :

CO= NFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
=

the uboot-b= in file is generated with this command :
=
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- m= ake

At this = point,I took a look inside the =2Econfig file and I saw that the parameter = "CONFIG_ARMV7_NONSEC=3Dn" has been removed=2E So,for some reason,it is not = accepted and this could be a problem=2E=2E=2E=2E
=
These are the xen config files that I've used : =

nano freebsd=2Ecfg =

name=3D"test"
kernel=3D"u-boot=2Ebin"
extra =3D "console=3Dhvc0"
memory=3D256
v= cpus=3D1
disk =3D [ 'FreeBSD-13=2E2-RELEASE-armv7=2Eimg,raw,xvda= ' ]
nano st= art-freebsd

xl create freebsd=2Ecfg
xl console= freebsd

This is what happens when I launch the vm :

= # =2E/start-freebsd
=
 
Parsing config from freebsd=2Ecfg
xc: error: panic: x= g_dom_core=2Ec:689: xc_dom_find_loader: no loader found: Invalid kernel libxl: error: libxl_dom=2Ec:571:libxl__build_dom: xc_dom_parse_image= failed
libxl: error: libxl_create=2Ec:1640:domcreate_rebuild_do= ne: Domain 1:cannot (re-)build domain: -3
libxl: error: libxl_doma= in=2Ec:1183:libxl__destroy_domid: Domain 1:Non-existent domain
lib= xl: error: libxl_domain=2Ec:1137:domain_destroy_callback: Domain 1:Unable t= o destroy guest
libxl: error: libxl_domain=2Ec:1064:domain_destroy= _cb: Domain 1:Destruction of domain failed
fre= ebsd is an invalid domain identifier (rc=3D-6)
=

=

On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM= Mario Marietto <marietto200= 8@gmail=2Ecom> wrote:
So,ok,I should have said "the= second u-boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO memory" of the Chromebook"=2E Sorry for the confusion=2E

On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Mariett= o <mariett= o2008@gmail=2Ecom> wrote:
---= > There are no specific options in u-boot devoted to FreeBSD
=

This is an = important factor=2E So,what about if,instead of compiling a new version of = u-boot on the partition 2,I will recompile the u-boot customized version cr= eated by the virtual open system in 2014,that should be installed on the fi= rst partition ? It could work if there are no differences between the u-boo= t that should boot Linux and the u-boot that should boot FreeBSD=2E

Can you give a look= at the u-boot source code created by virtual open systems ? You can find i= t on my google drive :


I n= eed to understand if I can recompile it without problem so that it can sati= sfy my needs (the ability of the file u-boot=2Ebin to boot FreeBSD as domU = under Xen,as explained by Stefano Stabellini,the xen developer that suggest= ed to me what I could do to have FreeBSD virtualized under Xen on my Arm Ch= romebook) ; otherwise the risk is to find later problems that will make me = troubles and that I will not able to fix=2E

I gave a look at the virtual op= en system u-boot and I didn't see any arndale_defconfig inside=2E So,= If I have understood correctly,I should put that file inside the root of th= e u-boot source code,let's say here :
<= strong>
marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD= /u-boot-vos # ls
 
=2Echeckpatch=2Ec= onf        README    &nbs= p;            &= nbsp;doc            =          net
=2Egi= t             &= nbsp;      api      =             &nb= sp;  drivers         &nbs= p;       onenand_ipl
=2Egiti= gnore            &nb= sp; arch           &= nbsp;        dts    =             &nb= sp;    post
COPYING     = ;            bo= ard             = ;      examples      = ;          rules=2Emk
CREDITS  =             &nb= sp;  boards=2Ecfg         = ;     fs        = ;            &n= bsp; scripts
MAINTAINERS      &nb= sp;      common      = ;            in= clude            &nb= sp;    snapshot=2Ecommit
MAKEALL  &nbs= p;            &= nbsp; config=2Emk=             &n= bsp; lib           &= nbsp;         spl
= Makefile            =     cros        &nbs= p;           mkconfi= g             &= nbsp;  test
PRESUBMIT=2Ecfg     &= nbsp;     disk       = ;            &n= bsp;nand_spl           &n= bsp;    tools

=
an= d I should do : make and make install ? and the file I need,u-boot=2Ebin wi= ll be generated ? 

= I didn't fin= d any pre made configuration file inside :

u-boot-vos # find =2E -type f -name "exynos*" 
=
=
=2E/include/e= xynos-fb=2Eh
=2E/include/configs/exynos5-common=2Eh
= =2E/doc/device-tree-bindings/spi/exynos-spi=2Etxt
=2E/doc/devi= ce-tree-bindings/usb/exynos-usb=2Etxt
=2E/drivers/power/exynos-= tmu=2Ec
=2E/drivers/power/exynos-cpufreq=2Ec
=2E/dr= ivers/video/exynos-fb=2Ec
=2E/drivers/spi/exynos_spi=2Ec
= =2E/board/samsung/dts/exynos5250-spring=2Edts
=2E/board/s= amsung/dts/exynos5250-smdk5250=2Edts
=2E/board/samsung/dts/exyn= os5250-snow=2Edts
=2E/board/samsung/dts/exynos5250-daisy=2Edts =
=2E/arch/arm/include/asm/arch-exynos5/exynos-cpufreq=2Eh
= =2E/arch/arm/include/asm/arch-exynos5/exynos-tmu=2Eh
=2E/= arch/arm/dts/exynos5250=2Edtsi
=2E/arch/arm/dts/exynos-periph-i= d=2Edtsi
=2E/arch/arm/cpu/armv7/exynos5/exynos_cache=2Ec <= /span>

u-boot-vos # find =2E -type f -name "arndale*"

= For sure I can't= use a newer version of u-boot because otherwise the patches needed to bypa= ss the bootloader protections of the Arm Chromebook (such as a lot of diffe= rent patches needed to boot correctly Linux) will be broken ; anyway,since = it works,I don't need to use an updated version of u-boot=2E

= ----> As per my experience, you have to respect these two options,= compiling u-boot for FreeBSD: https://github=2Ecom/freebsd/freebsd-ports/blob/main/sysutil= s/u-boot-master/files/FreeBSD_Fragment

=
It says that I should use= these parameters :

CONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORK= AROUND=3Dy

These a= re the parameters used to configure a Linux kernel=2E I don't understand wh= at's the relation between the compilation of a linux kernel and u-boot=2E I= n the past I tried to recompile u-boot,but I didn't have the need to set up= those parameters,so I don't know how to do it (but I know how to recompile= a Linux kernel)=2E

=

---> I'm not sure that I'm getting you right, as I do= n't understand what you mean under "the first u-boot"=2E

=


I'm talking about first u-boot because the whole = procedure to boot Linux on the ARM Chromebook,that's explained here :

http://www=2Evirtualopensystem= s=2Ecom/en/solutions/guides/kvm-on-chromebook/


=

at some point they say :


To be ab= le to run KVM on ARM platforms, the kernel has to be booted in hypervisor m= ode=2E Because of this relatively recent requirement (due to the introducti= on of the virtualization extensions), up until now all booting methods woul= d boot the kernel in the standard Supervisor mode=2E

For the = ARM Chromebook the default boot procedure doesn't allow us to boot in hyper= visor mode=2E Although the laptop's boot mechanism is based on the frequent= ly used u-boot, the binary is located in RO memory=2E Fortunately, a chaine= d u-boot mechanism can be used (i=2Ee=2E starting another u-boot after the = original)=2E We can then enter hypervisor mode from our custom iteration of= u-boot and subsequently load our kernel and userspace=2E

So,= the first u-boot is the u-boot provided by virtual open systems,that's able= to chainload the "u-boot binary located in RO memory" , that does not boot= Chrome OS in hypervisor mode=2E We don't need it if we want to boot Linux = with kvm or xen enabled=2E


=
On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanisl= av=2Esilnicki@mailgate=2Eus> wrote:
=
=
I'm not an expert in the topic, I only know, t= hat ARM has divided hardware into two worlds - Secure and Not-So, strictly = limiting any software, running in non-secure world with access to functions= and resources=2E https://developer=2Earm=2Ecom/documentation/den0013/d/Security/Trus= tZone-hardware-architecture?lang=3Den

=
I'm no= t sure, that I'm getting you right, as I don't understand what you mean und= er "the first u-boot"=2E

As I understand, virtu= alization (HYP) is running in non-secure world (h= ttps://developer=2Earm=2Ecom/documentation/ddi0406/c/System-Level-Architect= ure/The-System-Level-Programmers--Model/The-Virtualization-Extensions),= so my guess (only guess!!!), virtualization software has to prepare (confi= gure) HW platform in the way, that FreeBSD kernel will not lack any resourc= es, required to configure MPU, VA, etc=2E
So, if you lucky to bo= ot virtualizer, which is aware of target OS, that maybe you can boot the ke= rnel=2E Although, I doubt, that you need to boot 'second' u-boot to boot th= e kernel - there is simply ubldr, which you can hook somehow from virtualiz= er=2E=2E=2E=2E

Stan

<= br>

= Mario Marietto wrote:


=
=
---> As I understand, it= makes sure that u-boot keeps in secure mode during boot and passes control= to ubldr, which boots FreeBSD kernel, in that mode=2E
=

= Can you elaborate your sentence more ? I know that the bootloader secur= e mode is bypassed by the virtual open systems u-boot=2E Are you saying tha= t when the control passes to the second u-boot,it will happen in secure mod= e,so that the bypass that happened loading the first u-boot,is annulled ? I= f this is true,maybe can I boot FreeBSD using the virtual-open-system custo= m u-boot ? Is this compatible with FreeBSD ? Where can I find the u-boot=2E= bin that the xen developer talked about ? thanks bro'=2E
=

=

= On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <= sta= nislav=2Esilnicki@mailgate=2Eus> wrote:
=
=
=
Hi Mario, =

=
U-Boot&nbs= p; beast is hiding in this den: https://source=2Edenx=2Ede/u-boot/u-boot= =2Egit
= I took a brief look at your post and it seems to me, that option=  CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bi= t platform: h= ttps://source=2Edenx=2Ede/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kc= onfig?ref_type=3Dheads#L3
=
As for co= mpiling the u-boot, it is a doable task, given that you understand what you= are doing=2E There are no specific options in u-boot devoted to FreeBSD=2E= It is a boot loader, whose mission to make basic hardware initialization, = read you kernel file from some media into RAM and then pass it control=2E =

Basically, you can grab some defconfig, = prepared for any other Exynos5250 based board  (say, this one: https://source=2Edenx=2Ede/u= -boot/u-boot/-/blob/master/configs/arndale_defconfig?ref_type=3Dheads) = and adopt it somehow=2E
=
As per my exper= ience, you have to respect these two options, compiling u-boot for FreeBSD:=  https://github= =2Ecom/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD= _Fragment

=
As I understand, it mak= es sure, that u-boot keeps in secure mode during boot and passes control to= ubldr, which boots FreBSD kernel, in that mode=2E Otherwise, there a lot o= f surprises you may realize=2E
=
Hope, = this will help to progress you tasks
=
= Stan
Mario Marietto wrote:
=

=
=
Hell= o=2E

= I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chr= omebook=2E Basically there are two ways to accomplish this task : =

1= ) to write a patch that allows the FreeBSD kernel to boot as a zImage file= =2E This could be accomplished applying this patch to a specific file that'= s on the source code of FreeBSD :
=

https://xenbits=2Exen=2Eorg/gitweb/?p=3Dp=2E=2E=2E8;hb=3D0782e25d98cc1= 391472717035f986c979edef0c9
=

This p= atch was written by Julien Grall a lot of time ago and now it does not work= anymore=2E This is the reason :
=

= It appears FreeBSD-CURRENT removed the last step conv= erting the kernel file to kernel=2Ebin=2E The patch can be readily rebased,= but without kernel=2Ebin that doesn't do too much=2E =


= So,without a rebase of that patch the first option is not ap= plicable=2E And I'm not able to fix it=2E
=
2) booting FreeBSD using = U-Boot,as explained to me by a xen developer :
=

=
=
I was trying to explain why and how Jul= ien's patch works so that you could be the one to re-do something similar o= r fix the patch on the FreeBSD kernel that you are working with=2E I am hap= py to help review and write patches but I don't work with the FreeBSD kerne= l so I wouldn't be able to help you quickly=2E However, I might have a sugg= estion=2E Do you know if FreeBSD can be booted by U-Boot ? Because U-Boot d= efinitely boots as Xen on ARM guest firmware/bootloader=2E You should be ab= le to build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Bo= ot could load FreeBSD from disk or network and start it=2E For instance as = domU config file:
=
kernel=3D"/home/petalinux/u-boot=2Ebin" =
disk =3D [ '/ho= me/petalinux/test=2Eimg,raw,xvda' ]
=
I know it is important= to build u-boot with the following config to make it work on Xen=2E =

= CONFIG_CMO_BY_VA_ONLY=3Dy
=
=

Th= is option seems more doable to me according to my knowledge=2E But I need t= o understand how to do it=2E
=
Well,let's say that on the ARM Chromeb= ook I'm forced to use and install a customized version of u-boot,created by= virtual open systems,because it is the only one that allows bypassing its = bootloader protection=2E You can find more information here : =

http://www=2Evirtualopensystems= =2Ecom/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech =

This i= s the relevant section to read :
=

= Bootloader :
=
If you wish to skip thi= s chapter you can download a pre-compiled binary of the bootloader: =

=
$ wget http://www=2Evirtual= opensystems=2Ecom/downloads/guides/kvm_on_chromebook/nv_u-boot-snow=2Ekpart=

=
To be able to run KVM= on ARM platforms, the kernel has to be booted in hypervisor mode=2E Becaus= e of this relatively recent requirement (due to the introduction of the vir= tualization extensions), up until now all booting methods would boot the ke= rnel in the standard Supervisor mode=2E For the ARM Chromebook the default = boot procedure doesn't allow us to boot in hypervisor mode=2E Although the = laptop's boot mechanism is based on the frequently used u-boot, the binary = is located in RO memory=2E Fortunately, a chained u-boot mechanism can be u= sed (i=2Ee=2E starting another u-boot after the original)=2E We can then en= ter hypervisor mode from our custom iteration of u-boot and subsequently lo= ad our kernel and userspace=2E
=
Checkout the needed u-boot = code :

=
$ git clone git://<= a href=3D"http://github=2Ecom/virtualopensystems/u-boot=2Egit$" rel=3D"nofo= llow ugc noopener" target=3D"_blank">github=2Ecom/virtualopensystems/u-bo= ot=2Egit$ cd u-boot$ =2E/scripts/build=2Esh =


= If successful, a message about how to copy the bootlo= ader on the USB flash disk or SD card will appear=2E We will use it later w= hen preparing the boot medium to start our system=2E If you have followed t= he Setting up the boot medium chapter and you have a prepared boot device, = then you can update u-boot by running :
=

= $ sudo dd if=3Dnv_uboot-snow=2Ekpart of=3D/dev/sdX1 =
=

so,the needed u-boot that we must use should be = installed on the first partition of the sd card=2E =

There is another= relevant section to read :
=

= Setting up the boot medium
=
Now it is time= to copy all the relevant files that we created in the previous chapters,an= d use them to boot Chromebook with a different kernel and OS=2E In all thes= e examples the device /dev/sdX is used=2E Take extra care to change the exa= mples to the device that you have attached=2E Insert the boot medium on you= r workstation and carefully execute the following step=2E First we need to = properly format the boot medium=2E
=
In the uboot source dir= ectory :

=
$ sudo =2E/script= s/sdcard=2Esh /dev/sdX
=

Thi= s will erase all data and create 4 partitions in the medium, along with cop= ying the u-boot binary to the first partition: <= br>

= Partition 1 =3D ChromeOS signed binary (V=2EO=2ES chai= ned u-boot)
Par= tition 2 =3D not used
= Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos52= 50-snow=2Edtb)
= Partition 4 =3D EXT4 partition for userspace files =


= With u-boot being copied, next is the kernel image= and DTB file=2E From the kernel source execute : =


= $ mkdir =2E=2E/mnt/
= $ sudo mount /dev/sdX3 =2E=2E/mnt/ =
$ sudo cp arch/arm/boot/uI= mage =2E=2E/mnt/
= $ sudo cp arch/arm/boot/dts/exynos5250-snow=2Edtb =2E=2E/mnt/ =
$ sudo umount /dev/sdX3 =

=
Finally, we have to copy the= Ubuntu userspace filesystem that we created earlier: =


= $ sudo mount /dev/sdX4 mnt/$ sudo cp -a =2E/pre= cise/* mnt/$ sudo umount /dev/sdX4
=
=

Now,= my idea is to chainload the already chain loaded u-boot created by V=2EO=2E= S to the new u-boot that we need for booting FreeBSD and that can be instal= led in the partition n=2E2,as shown in this scheme,because it is not used :=

=
Partition 1 =3D ChromeOS signed binar= y (V=2EO=2ES chained u-boot)
= Partition 2 =3D not used (maybe we can install the u-boot for arm 3= 2 bit,compatible with FreeBSD on this partition) Partition 3 =3D EXT2 partition for u-boot files= (uImage and exynos5250-snow=2Edtb)
= Partition 4 =3D EXT4 partition for userspace files =

Take in consideration that default boot string = is hardcoded here,in the snow=2Eh file of the custom u-boot created by VOS = :

=
https://github=2Ecom/virtualo= pensyste=2E=2E=2E18a39b6c177dff58a/include/configs/snow=2Eh#L101 =

=
and it needs to be recompiled because it sho= uld point to the partition n=2E2,where I will install the u-boot files as e= xplained here :

=
https://wiki=2Efr= eebsd=2Eorg/arm/Chromebook
=

I have = some questions to ask before I start working on this=2E =

1) The xen = developer said :

=
=
= You should be able to build U-Boot and use the U-Boot binary as Xen g= uest kernel=2E=2E=2E
=

where is the u-boo= t binary,according to this document ?
=
https://wiki=2Efreebsd= =2Eorg/arm/Chromebook
=
I don't see it=2E =


= 2) where is the source code of the file that I can get here :=

http://commondatastorage=2Egoogleapis=2Ecom/chromeos-loca= lmirror/distfiles/nv_uboot-snow-simplefb=2Ekpart=2Ebz2 =

I need t= he source code if I want to recompile u-boot so that it can point to the pa= rtition 4=2E

= Maybe it can be found on this link : =

http://linux-exynos=2Eorg/dist/chromebook/nv_uboot/ =

but it = can't be opened=2E=2E=2E=2E
=

3) in this= specific scenario the source code of u-boot should run on arm 32 bit,not o= n arm 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's= powered by a Samsung Exynos 5250 (ARMv7 32 bit Cortex A15) Soc=2E =

<= br> 4) I'm not sure if I can chainload the customi= zed u-boot created by V=2EO=2ES that should be installed on the first parti= tion with the u-boot tailored for booting FreeBSD that should be installed = on the partition 2=2E=2E=2E=2E
=

5) the = xen developer said that u-boot should be compiled enabling this option : =

=
= Code:
=
<= br> 
CONFIG_CMO_BY_VA_ONLY=
=3Dy
<= /div>

= Well,can you provide some good source that can help me to und= erstand how I can recompile u-boot for FreeBSD ? thanks=2E =
=
=
=
= =

=
=
-- =
= Mario=2E
=
=


--
Mario=2E
=
<= /div>

--
Mario=2E
=

--
Mario= =2E


--
Mario=2E
------VCBWAXETIA7O4UQHSJNV7WPWZ88ZGZ-- From nobody Wed Dec 20 18:26:06 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwMTh5PpWz55CnZ for ; Wed, 20 Dec 2023 18:26:48 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwMTg2CxNz3C6H for ; Wed, 20 Dec 2023 18:26:47 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5533ca9cc00so5682152a12.2 for ; Wed, 20 Dec 2023 10:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703096805; x=1703701605; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aMWXI25JlXGCWFl4dQxmcQI9big3lNe9jqDk4SHcohs=; b=e4aOLWPIXRvdMN41c+DehmqzPJyVqmHwZM7uQoCfbbZ7UFvdpfeLjvzQ8PW2GM87i7 sScH5Z4kxPbqOiReD/uAaDbU8cfGRpCGBe4igA/8GEWVnmFW3G4TFuJjpuAhcWhjm1ct vyNMtY8LQRNO5iZhO+//YcQJ/+DJ5PJOwml+69jOQ62Ouro5rJ/4gL58VVUxMrdCZUnq ejCXUlUxQoWWDRPsX0wyzXa/jNq8veykiQCV/uFli9BgezT+YO89OLUKP3kC2LnMVR5G wLu0QA/OaMgw+owKseewS5PEI9QkRq2/Iaz5h/vtqlya7OzLy6+ZhpkSy6mucm0Kq7z/ T6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703096805; x=1703701605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aMWXI25JlXGCWFl4dQxmcQI9big3lNe9jqDk4SHcohs=; b=rTBwViDtfEeZadkgyG1oJAx186i0Di1L9orpCSrRlEgB3cO/ui8Yw3zAIU34cgmFZs SE0NBEq+Idb5MyuBRiW2YhVzZgRKwcQughD/s181ZKZC3U/4uRmad4VknuFaq2y5780h lKUnFYOBLcYhCp9M/XNc7qKpv0u2PfgC0RRL4FMPX6ZD5OOMPp1ZHTQiIiqYiq90Qh0L VJRrskqf3M5OaCSiXdocp0dak75XTmh0ygkCb+Hyft5NOhLA3BKX/RH0gMphKK2BNdH/ sLO+ANXV3HsYP8AWmWoKWloMi/+3g67GUIkYRMF4ed5nrcpNwCfwb3bCyCXv77SOfSkV 5SGA== X-Gm-Message-State: AOJu0YxTwjjvmubDVfWyayLS7U4IKrBb+YfcD7AHuSOPG1kOT/a2HSPc t5Ll8cD+KZy92ovv8hpTgOfDkADz6UJlUB0xwgE= X-Google-Smtp-Source: AGHT+IHQB2dbUu9rzwymoPiGnkxccwWTbjyR12ZBIOUfVCWuN4HLHeoNPJ48mVqTx4X7nL2JQmvBLcgORoHf4xa0Ack= X-Received: by 2002:a17:907:970e:b0:a23:49ec:e09b with SMTP id jg14-20020a170907970e00b00a2349ece09bmr4095247ejc.18.1703096804650; Wed, 20 Dec 2023 10:26:44 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <54b70672-9ea4-40e2-b346-b579536c0e5c@mailgate.us> In-Reply-To: <54b70672-9ea4-40e2-b346-b579536c0e5c@mailgate.us> From: Mario Marietto Date: Wed, 20 Dec 2023 19:26:06 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stanislav Silnicki Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000f32f8060cf520da" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwMTg2CxNz3C6H --0000000000000f32f8060cf520da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> Mario, you can not edit .config by hand. You have to consider these options in some _defconfig and then reconfigure / recompile ok. I did as you have suggested,but I've got the same exact error. I've added the parameter "CONFIG_ARMV7_NONSEC=3Dn" inside the file snow_defconfi= g and then : # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make The u-boot.bin file generated has a different size than that generated before,but the error when I try to boot FreeBSD is the same. On Wed, Dec 20, 2023 at 6:00=E2=80=AFPM Stanislav Silnicki < stanislav.silnicki@mailgate.us> wrote: > Mario, you can not edit .config byhand. You have to consider these option= s > in some _defconfig and then reconfigure/tecompile > > Get BlueMail for Android > On Dec 19, 2023, at 5:29 PM, Mario Marietto > wrote: >> >> Hello to everyone. >> >> I have compiled the needed u-boot.bin from scratch using this procedure = : >> >> # git clone https://github.com/u-boot/u-boot.git >> # cd u-boot >> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig : = this >> line generates the file .config >> # nano .config and I've added these parameters : >> >> CONFIG_ARMV7_NONSEC=3Dn >> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >> >> the uboot-bin file is generated with this command : >> >> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >> >> At this point,I took a look inside the .config file and I saw that the >> parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some reason= ,it >> is not accepted and this could be a problem.... >> >> These are the xen config files that I've used : >> >> nano freebsd.cfg >> >> name=3D"test" >> kernel=3D"u-boot.bin" >> extra =3D "console=3Dhvc0" >> memory=3D256 >> vcpus=3D1 >> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >> >> nano start-freebsd >> >> xl create freebsd.cfg >> xl console freebsd >> >> This is what happens when I launch the vm : >> >> # ./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 faile= d >> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:canno= t >> (re-)build domain: -3 >> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >> 1:Non-existent domain >> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >> 1:Unable to destroy guest >> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructio= n >> of domain failed >> freebsd is an invalid domain identifier (rc=3D-6) >> >> >> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto >> wrote: >> >>> So,ok,I should have said "the second u-boot" ; since the first u-boot >>> binary is the "u-boot binary located in the RO memory" of the Chromeboo= k". >>> Sorry for the confusion. >>> >>> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto >>> wrote: >>> >>>> ---> There are no specific options in u-boot devoted to FreeBSD >>>> >>>> This is an important factor. So,what about if,instead of compiling a >>>> new version of u-boot on the partition 2,I will recompile the u-boot >>>> customized version created by the virtual open system in 2014,that sho= uld >>>> be installed on the first partition ? It could work if there are no >>>> differences between the u-boot that should boot Linux and the u-boot t= hat >>>> should boot FreeBSD. >>>> >>>> Can you give a look at the u-boot source code created by virtual open >>>> systems ? You can find it on my google drive : >>>> >>>> >>>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view= ?usp=3Dsharing >>>> >>>> I need to understand if I can recompile it without problem so that it >>>> can satisfy my needs (the ability of the file u-boot.bin to boot FreeB= SD as >>>> domU under Xen,as explained by Stefano Stabellini,the xen developer th= at >>>> suggested to me what I could do to have FreeBSD virtualized under Xen = on my >>>> Arm Chromebook) ; otherwise the risk is to find later problems that wi= ll >>>> make me troubles and that I will not able to fix. >>>> >>>> I gave a look at the virtual open system u-boot and I didn't see any a= rndale_defconfig >>>> inside. So,If I have understood correctly,I should put that file insid= e the >>>> root of the u-boot source code,let's say here : >>>> >>>> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>>> >>>> .checkpatch.conf README doc >>>> net >>>> .git api drivers >>>> onenand_ipl >>>> .gitignore arch dts >>>> post >>>> COPYING board examples >>>> rules.mk >>>> CREDITS boards.cfg fs >>>> scripts >>>> MAINTAINERS common include >>>> snapshot.commit >>>> MAKEALL config.mk lib >>>> spl >>>> Makefile cros mkconfig >>>> test >>>> PRESUBMIT.cfg disk nand_spl >>>> tools >>>> >>>> and I should do : make and make install ? and the file I >>>> need,u-boot.bin will be generated ? >>>> >>>> I didn't find any pre made configuration file inside : >>>> >>>> u-boot-vos # find . -type f -name "exynos*" >>>> >>>> ./include/exynos-fb.h >>>> ./include/configs/exynos5-common.h >>>> ./doc/device-tree-bindings/spi/exynos-spi.txt >>>> ./doc/device-tree-bindings/usb/exynos-usb.txt >>>> ./drivers/power/exynos-tmu.c >>>> ./drivers/power/exynos-cpufreq.c >>>> ./drivers/video/exynos-fb.c >>>> ./drivers/spi/exynos_spi.c >>>> ./board/samsung/dts/exynos5250-spring.dts >>>> ./board/samsung/dts/exynos5250-smdk5250.dts >>>> ./board/samsung/dts/exynos5250-snow.dts >>>> ./board/samsung/dts/exynos5250-daisy.dts >>>> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>>> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>>> ./arch/arm/dts/exynos5250.dtsi >>>> ./arch/arm/dts/exynos-periph-id.dtsi >>>> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>>> >>>> u-boot-vos # find . -type f -name "arndale*" >>>> >>>> For sure I can't use a newer version of u-boot because otherwise the >>>> patches needed to bypass the bootloader protections of the Arm Chromeb= ook >>>> (such as a lot of different patches needed to boot correctly Linux) wi= ll be >>>> broken ; anyway,since it works,I don't need to use an updated version = of >>>> u-boot. >>>> >>>> ----> As per my experience, you have to respect these two options, >>>> compiling u-boot for FreeBSD: >>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mas= ter/files/FreeBSD_Fragment >>>> >>>> It says that I should use these parameters : >>>> >>>> CONFIG_ARMV7_NONSEC=3Dn >>>> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>> >>>> These are the parameters used to configure a Linux kernel. I don't >>>> understand what's the relation between the compilation of a linux kern= el >>>> and u-boot. In the past I tried to recompile u-boot,but I didn't have = the >>>> need to set up those parameters,so I don't know how to do it (but I kn= ow >>>> how to recompile a Linux kernel). >>>> >>>> >>>> ---> I'm not sure that I'm getting you right, as I don't understand >>>> what you mean under "the first u-boot". >>>> >>>> >>>> I'm talking about first u-boot because the whole procedure to boot >>>> Linux on the ARM Chromebook,that's explained here : >>>> >>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeboo= k/ >>>> >>>> >>>> at some point they say : >>>> >>>> >>>> To be able to run KVM on ARM platforms, the kernel has to be booted in >>>> hypervisor mode. Because of this relatively recent requirement (due to= the >>>> introduction of the virtualization extensions), up until now all booti= ng >>>> methods would boot the kernel in the standard Supervisor mode. >>>> >>>> For the ARM Chromebook the default boot procedure doesn't allow us to >>>> boot in hypervisor mode. Although the laptop's boot mechanism is based= on >>>> the frequently used u-boot, the binary is located in RO memory. >>>> Fortunately, a chained u-boot mechanism can be used (i.e. starting ano= ther >>>> u-boot after the original). We can then enter hypervisor mode from our >>>> custom iteration of u-boot and subsequently load our kernel and usersp= ace. >>>> >>>> So,the first u-boot is the u-boot provided by virtual open >>>> systems,that's able to chainload the "u-boot binary located in RO memo= ry" , >>>> that does not boot Chrome OS in hypervisor mode. We don't need it if w= e >>>> want to boot Linux with kvm or xen enabled. >>>> >>>> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>>> stanislav.silnicki@mailgate.us> wrote: >>>> >>>>> I'm not an expert in the topic, I only know, that ARM has divided >>>>> hardware into two worlds - Secure and Not-So, strictly limiting any >>>>> software, running in non-secure world with access to functions and >>>>> resources. >>>>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-= hardware-architecture?lang=3Den >>>>> >>>>> I'm not sure, that I'm getting you right, as I don't understand what >>>>> you mean under "the first u-boot". >>>>> >>>>> As I understand, virtualization (HYP) is running in non-secure world = ( >>>>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Archit= ecture/The-System-Level-Programmers--Model/The-Virtualization-Extensions), >>>>> so my guess (only guess!!!), virtualization software has to prepare >>>>> (configure) HW platform in the way, that FreeBSD kernel will not lack= any >>>>> resources, required to configure MPU, VA, etc. >>>>> So, if you lucky to boot virtualizer, which is aware of target OS, >>>>> that maybe you can boot the kernel. Although, I doubt, that you need = to >>>>> boot 'second' u-boot to boot the kernel - there is simply ubldr, whic= h you >>>>> can hook somehow from virtualizer.... >>>>> >>>>> Stan >>>>> >>>>> >>>>> >>>>> Mario Marietto wrote: >>>>> >>>>> >>>>> ---> As I understand, it makes sure that u-boot keeps in secure mode >>>>> during boot and passes control to ubldr, which boots FreeBSD kernel, = in >>>>> that mode. >>>>> >>>>> Can you elaborate your sentence more ? I know that the bootloader >>>>> secure mode is bypassed by the virtual open systems u-boot. Are you s= aying >>>>> that when the control passes to the second u-boot,it will happen in s= ecure >>>>> mode,so that the bypass that happened loading the first u-boot,is ann= ulled >>>>> ? If this is true,maybe can I boot FreeBSD using the virtual-open-sys= tem >>>>> custom u-boot ? Is this compatible with FreeBSD ? Where can I find th= e >>>>> u-boot.bin that the xen developer talked about ? thanks bro'. >>>>> >>>>> >>>>> >>>>> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>>>> stanislav.silnicki@mailgate.us> wrote: >>>>> >>>>>> Hi Mario, >>>>>> >>>>>> U-Boot beast is hiding in this den: >>>>>> https://source.denx.de/u-boot/u-boot.git >>>>>> I took a brief look at your post and it seems to me, that option >>>>>> CONFIG_CMO_BY_VA_ONLY is irrelevant to your target armv7 32 bit >>>>>> platform: >>>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv= 8/Kconfig?ref_type=3Dheads#L3 >>>>>> >>>>>> As for compiling the u-boot, it is a doable task, given that you >>>>>> understand what you are doing. There are no specific options in u-bo= ot >>>>>> devoted to FreeBSD. It is a boot loader, whose mission to make basic >>>>>> hardware initialization, read you kernel file from some media into R= AM and >>>>>> then pass it control. >>>>>> >>>>>> Basically, you can grab some defconfig, prepared for any other >>>>>> Exynos5250 based board (say, this one: >>>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_d= efconfig?ref_type=3Dheads) >>>>>> and adopt it somehow. >>>>>> >>>>>> As per my experience, you have to respect these two options, >>>>>> compiling u-boot for FreeBSD: >>>>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-m= aster/files/FreeBSD_Fragment >>>>>> >>>>>> As I understand, it makes sure, that u-boot keeps in secure mode >>>>>> during boot and passes control to ubldr, which boots FreBSD kernel, = in that >>>>>> mode. Otherwise, there a lot of surprises you may realize. >>>>>> >>>>>> Hope, this will help to progress you tasks >>>>>> Stan >>>>>> >>>>>> Mario Marietto wrote: >>>>>> >>>>>> >>>>>> Hello. >>>>>> >>>>>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>>>>> Chromebook. Basically there are two ways to accomplish this task : >>>>>> >>>>>> 1) to write a patch that allows the FreeBSD kernel to boot as a >>>>>> zImage file. This could be accomplished applying this patch to a spe= cific >>>>>> file that's on the source code of FreeBSD : >>>>>> >>>>>> >>>>>> >>>>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139147271= 7035f986c979edef0c9 >>>>>> >>>>>> >>>>>> >>>>>> This patch was written by Julien Grall a lot of time ago and now it >>>>>> does not work anymore. This is the reason : >>>>>> >>>>>> >>>>>> It appears FreeBSD-CURRENT removed the last step converting the >>>>>> kernel file to kernel.bin. The patch can be readily rebased, but wit= hout >>>>>> kernel.bin that doesn't do too much. >>>>>> >>>>>> >>>>>> >>>>>> So,without a rebase of that patch the first option is not applicable= . >>>>>> And I'm not able to fix it. >>>>>> >>>>>> 2) booting FreeBSD using U-Boot,as explained to me by a xen develope= r >>>>>> : >>>>>> >>>>>> >>>>>> I was trying to explain why and how Julien's patch works so that you >>>>>> could be the one to re-do something similar or fix the patch on the = FreeBSD >>>>>> kernel that you are working with. I am happy to help review and writ= e >>>>>> patches but I don't work with the FreeBSD kernel so I wouldn't be ab= le to >>>>>> help you quickly. However, I might have a suggestion. Do you know if >>>>>> FreeBSD can be booted by U-Boot ? Because U-Boot definitely boots as= Xen on >>>>>> ARM guest firmware/bootloader. You should be able to build U-Boot an= d use >>>>>> the U-Boot binary as Xen guest kernel, then U-Boot could load FreeBS= D from >>>>>> disk or network and start it. For instance as domU config file: >>>>>> >>>>>> kernel=3D"/home/petalinux/u-boot.bin" >>>>>> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>>>> >>>>>> I know it is important to build u-boot with the following config to >>>>>> make it work on Xen. >>>>>> >>>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>>> >>>>>> >>>>>> >>>>>> This option seems more doable to me according to my knowledge. But I >>>>>> need to understand how to do it. >>>>>> >>>>>> Well,let's say that on the ARM Chromebook I'm forced to use and >>>>>> install a customized version of u-boot,created by virtual open >>>>>> systems,because it is the only one that allows bypassing its bootloa= der >>>>>> protection. You can find more information here : >>>>>> >>>>>> >>>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeb= ook/?vos=3Dtech >>>>>> >>>>>> This is the relevant section to read : >>>>>> >>>>>> >>>>>> Bootloader : >>>>>> >>>>>> If you wish to skip this chapter you can download a pre-compiled >>>>>> binary of the bootloader: >>>>>> >>>>>> >>>>>> $ wget >>>>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook= /nv_u-boot-snow.kpart >>>>>> >>>>>> >>>>>> To be able to run KVM on ARM platforms, the kernel has to be booted >>>>>> in hypervisor mode. Because of this relatively recent requirement (d= ue to >>>>>> the introduction of the virtualization extensions), up until now all >>>>>> booting methods would boot the kernel in the standard Supervisor mod= e. For >>>>>> the ARM Chromebook the default boot procedure doesn't allow us to bo= ot in >>>>>> hypervisor mode. Although the laptop's boot mechanism is based on th= e >>>>>> frequently used u-boot, the binary is located in RO memory. Fortunat= ely, a >>>>>> chained u-boot mechanism can be used (i.e. starting another u-boot a= fter >>>>>> the original). We can then enter hypervisor mode from our custom ite= ration >>>>>> of u-boot and subsequently load our kernel and userspace. >>>>>> >>>>>> Checkout the needed u-boot code : >>>>>> >>>>>> >>>>>> $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>>>>> u-boot$ ./scripts/build.sh >>>>>> >>>>>> >>>>>> If successful, a message about how to copy the bootloader on the USB >>>>>> flash disk or SD card will appear. We will use it later when prepari= ng the >>>>>> boot medium to start our system. If you have followed the Setting up= the >>>>>> boot medium chapter and you have a prepared boot device, then you ca= n >>>>>> update u-boot by running : >>>>>> >>>>>> >>>>>> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>>>> >>>>>> >>>>>> >>>>>> so,the needed u-boot that we must use should be installed on the >>>>>> first partition of the sd card. >>>>>> >>>>>> There is another relevant section to read : >>>>>> >>>>>> >>>>>> Setting up the boot medium >>>>>> >>>>>> Now it is time to copy all the relevant files that we created in the >>>>>> previous chapters,and use them to boot Chromebook with a different k= ernel >>>>>> and OS. In all these examples the device /dev/sdX is used. Take extr= a care >>>>>> to change the examples to the device that you have attached. Insert = the >>>>>> boot medium on your workstation and carefully execute the following = step. >>>>>> First we need to properly format the boot medium. >>>>>> >>>>>> In the uboot source directory : >>>>>> >>>>>> >>>>>> $ sudo ./scripts/sdcard.sh /dev/sdX >>>>>> >>>>>> >>>>>> This will erase all data and create 4 partitions in the medium, alon= g >>>>>> with copying the u-boot binary to the first partition: >>>>>> >>>>>> >>>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>>> Partition 2 =3D not used >>>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>>> exynos5250-snow.dtb) >>>>>> Partition 4 =3D EXT4 partition for userspace files >>>>>> >>>>>> >>>>>> With u-boot being copied, next is the kernel image and DTB file. Fro= m >>>>>> the kernel source execute : >>>>>> >>>>>> >>>>>> $ mkdir ../mnt/ >>>>>> $ sudo mount /dev/sdX3 ../mnt/ >>>>>> $ sudo cp arch/arm/boot/uImage ../mnt/ >>>>>> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>>>> $ sudo umount /dev/sdX3 >>>>>> >>>>>> >>>>>> Finally, we have to copy the Ubuntu userspace filesystem that we >>>>>> created earlier: >>>>>> >>>>>> >>>>>> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo umoun= t >>>>>> /dev/sdX4 >>>>>> >>>>>> >>>>>> >>>>>> Now,my idea is to chainload the already chain loaded u-boot created >>>>>> by V.O.S to the new u-boot that we need for booting FreeBSD and that= can be >>>>>> installed in the partition n.2,as shown in this scheme,because it is= not >>>>>> used : >>>>>> >>>>>> >>>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>>> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>>>>> bit,compatible with FreeBSD on this partition) >>>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>>> exynos5250-snow.dtb) >>>>>> Partition 4 =3D EXT4 partition for userspace files >>>>>> >>>>>> >>>>>> Take in consideration that default boot string is hardcoded here,in >>>>>> the snow.h file of the custom u-boot created by VOS : >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/conf= igs/snow.h#L101 >>>>>> >>>>>> >>>>>> >>>>>> and it needs to be recompiled because it should point to the >>>>>> partition n.2,where I will install the u-boot files as explained her= e : >>>>>> >>>>>> >>>>>> https://wiki.freebsd.org/arm/Chromebook >>>>>> >>>>>> >>>>>> I have some questions to ask before I start working on this. >>>>>> >>>>>> 1) The xen developer said : >>>>>> >>>>>> >>>>>> You should be able to build U-Boot and use the U-Boot binary as Xen >>>>>> guest kernel... >>>>>> >>>>>> >>>>>> >>>>>> where is the u-boot binary,according to this document ? >>>>>> >>>>>> https://wiki.freebsd.org/arm/Chromebook >>>>>> >>>>>> I don't see it. >>>>>> >>>>>> >>>>>> 2) where is the source code of the file that I can get here : >>>>>> >>>>>> >>>>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfil= es/nv_uboot-snow-simplefb.kpart.bz2 >>>>>> >>>>>> I need the source code if I want to recompile u-boot so that it can >>>>>> point to the partition 4. >>>>>> >>>>>> Maybe it can be found on this link : >>>>>> >>>>>> http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>>>> >>>>>> but it can't be opened.... >>>>>> >>>>>> >>>>>> 3) in this specific scenario the source code of u-boot should run on >>>>>> arm 32 bit,not on arm 64,because I have the Samsung Chromebook "SNOW= " model >>>>>> XE303C12,that's powered by a Samsung Exynos 5250 (ARMv7 32 bit Corte= x A15) >>>>>> Soc. >>>>>> >>>>>> >>>>>> 4) I'm not sure if I can chainload the customized u-boot created by >>>>>> V.O.S that should be installed on the first partition with the u-boo= t >>>>>> tailored for booting FreeBSD that should be installed on the partiti= on >>>>>> 2.... >>>>>> >>>>>> >>>>>> 5) the xen developer said that u-boot should be compiled enabling >>>>>> this option : >>>>>> >>>>>> >>>>>> Code: >>>>>> >>>>>> CONFIG_CMO_BY_VA_ONLY=3Dy >>>>>> >>>>>> >>>>>> >>>>>> Well,can you provide some good source that can help me to understand >>>>>> how I can recompile u-boot for FreeBSD ? thanks. >>>>>> >>>>>> -- >>>>>> Mario. >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Mario. >>>>> >>>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> >>> -- >>> Mario. >>> >> >> >> -- >> Mario. >> > --=20 Mario. --0000000000000f32f8060cf520da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> Mario, you can not edit .config b= y hand. You have to consider these options in some _defconfig and then reco= nfigure / recompile

ok. I did as you have suggeste= d,but I've got the same exact error. I've added the parameter "= ;CONFIG_ARMV7_NONSEC=3Dn" inside the file snow_defconfig and then :

# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make

The u-boot.bin file generated has a diffe= rent size than that generated before,but the error when I try to boot FreeB= SD is the same.

On Wed, Dec 20, 2023 at 6:00=E2=80=AFPM Stani= slav Silnicki <stanisl= av.silnicki@mailgate.us> wrote:
Mario, you can not edit .conf= ig byhand. You have to consider these options in some _defconfig and then r= econfigure/tecompile

On Dec 19, 2023, at 5:29 PM, Mario Marietto <= marietto2008@gm= ail.com> wrote:
Hello to everyone.

I have compiled the needed u-boot.bin from scratch using this procedure = :

# cd u-boot
# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnu= eabihf- make snow_defconfig : this line generates the file .config
# nano .config and I've added these pa= rameters :

CONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

the uboot-bin file is generated with this = command :

# ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnu= eabihf- make

At this point,I took a look inside the .config file and I saw that the p= arameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for some = reason,it is not accepted and this could be a problem....

These are the xen config files that I've used :

nano freebsd.cfg

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc= 0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,ra= w,xvda' ]

nano start-freebsd

xl create freebsd.cfg
xl console freebsd

This is what happens when I launch= the vm :

# ./start-freebsd
=C2=A0
Parsing config from freebsd.cfg
xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Do= main 1:cannot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
freebsd is an invalid domain identifier (rc= =3D-6)


On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com&g= t; wrote:
So,ok,I should have said "the second u-boot" ; since the first= u-boot binary is the "u-boot binary located in the RO memory" of= the Chromebook". Sorry for the confusion.

On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
---> There are no specific options in u-boot devoted to FreeBSD=20

This is an important factor. So,what about if,instead of compiling a = new version of u-boot on the partition 2,I will recompile the u-boot custom= ized version created by the virtual open system in 2014,that should be inst= alled on the first partition ? It could work if there are no differences be= tween the u-boot that should boot Linux and the u-boot that should boot Fre= eBSD.

Can you give a look at the u-boot source code created by virtual open= systems ? You can find it on my google drive :


I need to understand if I can recompile it without problem so that it= can satisfy my needs (the ability of the file u-boot.bin to boot FreeBSD a= s domU under Xen,as explained by Stefano Stabellini,the xen developer that = suggested to me what I could do to have FreeBSD virtualized under Xen on my= Arm Chromebook) ; otherwise the risk is to find later problems that will m= ake me troubles and that I will not able to fix.=20

I gave a look at the virtual open system u-boot and I didn't see = any arndale_defconfig inside. So,If I have understood correctly,I sho= uld put that file inside the root of the u-boot source code,let's say h= ere :

marietto:/home/mari= etto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls
=C2=A0
.checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0net
.git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
.gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules= .mk
CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0snapshot.commit
MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0spl
Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0test
PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools

and I should = do : make and make install ? and the file I need,u-boot.bin will be generat= ed ?=C2=A0

I didn't = find any pre made configuration file inside :

u-boot-vos # find . -type f -name "exynos*<= /span>"=C2=A0

./include/exynos-fb.h ./include/configs/exynos5-common.h
./doc/device-tree-bindings/spi/exynos-spi.txt
./doc/device-tree-bindings/usb/exynos-usb.txt
./drivers/power/exynos-tmu.c
./drivers/power/exynos-cpufreq.c
./drivers/video/exynos-fb.c
./drivers/spi/exynos_spi.c
./board/samsung/dts/exynos5250-spring.dts
./board/samsung/dts/exynos5250-smdk5250.dts
./board/samsung/dts/exynos5250-snow.dts
./board/samsung/dts/exynos5250-daisy.dts
./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
./arch/arm/dts/exynos5250.dtsi
./arch/arm/dts/exynos-periph-id.dtsi
./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0

u-boot-vos # find . -typ= e f -name "arndale*"=

For sure I ca= n't use a newer version of u-boot because otherwise the patches needed = to bypass the bootloader protections of the Arm Chromebook (such as a lot o= f different patches needed to boot correctly Linux) will be broken ; anyway= ,since it works,I don't need to use an updated version of u-boot.

----> As per my experience, you have to respect these two options= , compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u= -boot-master/files/FreeBSD_Fragment

It says that I should use these parameters :

CONFIG_ARMV7_NONSEC=3Dn
CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy

These are the parameters used to configure a Linux k= ernel. I don't understand what's the relation between the compilati= on of a linux kernel and u-boot. In the past I tried to recompile u-boot,bu= t I didn't have the need to set up those parameters,so I don't know= how to do it (but I know how to recompile a Linux kernel).


---> I'm not sure that I'm getting you right, as I don= 9;t understand what you mean under "the first u-boot".


I'm talking about first u-boot because the whole procedure to= boot Linux on the ARM Chromebook,that's explained here :

http://www.virtualopensystems.com/en/= solutions/guides/kvm-on-chromebook/


at some point they say :


To be able to run KVM on ARM platforms, the kernel has to be boot= ed in hypervisor mode. Because of this relatively recent requirement (due t= o the introduction of the virtualization extensions), up until now all boot= ing methods would boot the kernel in the standard Supervisor mode.

For the ARM Chromebook the default boot procedure doesn't all= ow us to boot in hypervisor mode. Although the laptop's boot mechanism = is based on the frequently used u-boot, the binary is located in RO memory.= Fortunately, a chained u-boot mechanism can be used (i.e. starting another= u-boot after the original). We can then enter hypervisor mode from our cus= tom iteration of u-boot and subsequently load our kernel and userspace.

So,the first u-boot is the u-boot provided by virtual open system= s,that's able to chainload the "u-boot binary located in RO memory= " , that does not boot Chrome OS in hypervisor mode. We don't need= it if we want to boot Linux with kvm or xen enabled.


On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
I'm not an expert in the topic, I only know, that ARM has div= ided hardware into two worlds - Secure and Not-So, strictly limiting any so= ftware, running in non-secure world with access to functions and resources.= =C2=A0https://devel= oper.arm.com/documentation/den0013/d/Security/TrustZone-hardware-architectu= re?lang=3Den

I'm not sure, that I'm getting you right, as I don't = understand what you mean under "the first u-boot".

As I understand, virtualization (HYP) is running in non-secure wo= rld (https://developer.arm.com/documentation/ddi0406/= c/System-Level-Architecture/The-System-Level-Programmers--Model/The-Virtual= ization-Extensions), so my guess (only guess!!!), virtualization softwa= re has to prepare (configure) HW platform in the way, that FreeBSD kernel w= ill not lack any resources, required to configure MPU, VA, etc.
So, if you lucky to boot virtualizer, which is aware of target OS= , that maybe you can boot the kernel. Although, I doubt, that you need to b= oot 'second' u-boot to boot the kernel - there is simply ubldr, whi= ch you can hook somehow from virtualizer....

Stan



Mario Marietto wrote:


---> As I understand, it makes sure that u-boot keeps in sec= ure mode during boot and passes control to ubldr, which boots FreeBSD kerne= l, in that mode.

Can you elaborate your sentence more ? I know that the bootload= er secure mode is bypassed by the virtual open systems u-boot. Are you sayi= ng that when the control passes to the second u-boot,it will happen in secu= re mode,so that the bypass that happened loading the first u-boot,is annull= ed ? If this is true,maybe can I boot FreeBSD using the virtual-open-system= custom u-boot ? Is this compatible with FreeBSD ? Where can I find the u-b= oot.bin that the xen developer talked about ? thanks bro'.



On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <= ;stanis= lav.silnicki@mailgate.us> wrote:
Hi Mario,

U-Boot=C2=A0 beast is hiding in this den: https://source.denx.= de/u-boot/u-boot.git
I took a brief look at your post and it seems to me, that = option=C2=A0CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to your target armv7= 32 bit platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kcon= fig?ref_type=3Dheads#L3

As for compiling the u-boot, it is a doable task, given th= at you understand what you are doing. There are no specific options in u-bo= ot devoted to FreeBSD. It is a boot loader, whose mission to make basic har= dware initialization, read you kernel file from some media into RAM and the= n pass it control.

Basically, you can grab some defconfig, prepared for any o= ther Exynos5250 based board=C2=A0 (say, this one: https://source.denx.de/u-boot/u-boot/-/blob/master= /configs/arndale_defconfig?ref_type=3Dheads) and adopt it somehow.

As per my experience, you have to respect these two option= s, compiling u-boot for FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment

As I understand, it makes sure, that u-boot keeps in secur= e mode during boot and passes control to ubldr, which boots FreBSD kernel, = in that mode. Otherwise, there a lot of surprises you may realize.

Hope, this will help to progress you tasks
Stan

Mario Marietto wrote:


Hello.

I'm trying to boot FreeBSD for arm32 bit as Do= mU on my ARM Chromebook. Basically there are two ways to accomplish this ta= sk :

1) to write a patch that allows the FreeBSD kernel= to boot as a zImage file. This could be accomplished applying this patch t= o a specific file that's on the source code of FreeBSD :


https://xenbits.xe= n.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f986c979edef0c9


This patch was written by Julien Grall a lot of ti= me ago and now it does not work anymore. This is the reason :


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. And I'm not able to fix it.

2) booting FreeBSD using U-Boot,as explained to me= by a xen developer :


I was trying to explain why and how Julien's= patch works so that you could be the one to re-do something similar or fix= the patch on the FreeBSD kernel that you are working with. I am happy to h= elp review and write patches but I don't work with the FreeBSD kernel s= o I wouldn't be able to help you quickly. However, I might have a sugge= stion. Do you know if FreeBSD can be booted by U-Boot ? Because U-Boot defi= nitely boots as Xen on ARM guest firmware/bootloader. You should be able to= build U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot co= uld load FreeBSD from disk or network and start it. For instance as domU co= nfig file:

kernel=3D"/home/petalinux/u-boot.bin"
disk =3D [ '/home/petalinux/test.img,raw,xv= da' ]

I know it is important to build u-boot with the= following config to make it work on Xen.

CONFIG_CMO_BY_VA_ONLY=3Dy


This option seems more doable to me according to m= y knowledge. But I need to understand how to do it.

Well,let's say that on the ARM Chromebook I= 9;m forced to use and install a customized version of u-boot,created by vir= tual open systems,because it is the only one that allows bypassing its boot= loader protection. You can find more information here :

http://www.virtualopensystems.com/en/solutions/guides= /kvm-on-chromebook/?vos=3Dtech

This is the relevant section to read :


Bootloader :

If you wish to skip this chapter you can downlo= ad a pre-compiled binary of the bootloader:


$ wget http://www.virtualopensystems.com/downlo= ads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart


To be able to run KVM on ARM platforms, the ker= nel has to be booted in hypervisor mode. Because of this relatively recent = requirement (due to the introduction of the virtualization extensions), up = until now all booting methods would boot the kernel in the standard Supervi= sor mode. For the ARM Chromebook the default boot procedure doesn't all= ow us to boot in hypervisor mode. Although the laptop's boot mechanism = is based on the frequently used u-boot, the binary is located in RO memory.= Fortunately, a chained u-boot mechanism can be used (i.e. starting another= u-boot after the original). We can then enter hypervisor mode from our cus= tom iteration of u-boot and subsequently load our kernel and userspace.

Checkout the needed u-boot code :


$ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$ ./scripts/b= uild.sh


If successful, a message about how to copy the = bootloader on the USB flash disk or SD card will appear. We will use it lat= er when preparing the boot medium to start our system. If you have followed= the Setting up the boot medium chapter and you have a prepared boot device= , then you can update u-boot by running :


$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sd= X1


so,the needed u-boot that we must use should be in= stalled on the first partition of the sd card.

There is another relevant section to read :


Setting up the boot medium

Now it is time to copy all the relevant files t= hat we created in the previous chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these examples the device /dev/sdX is u= sed. Take extra care to change the examples to the device that you have att= ached. Insert the boot medium on your workstation and carefully execute the= following step. First we need to properly format the boot medium.

In the uboot source directory :


$ sudo ./scripts/sdcard.sh /dev/sdX


This will erase all data and create 4 partition= s in the medium, along with copying the u-boot binary to the first partitio= n:


Partition 1 =3D ChromeOS signed binary (V.O.S c= hained u-boot)
Partition 2 =3D not used
Partition 3 =3D EXT2 partition for u-boot files= (uImage and exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace fi= les


With u-boot being copied, next is the kernel im= age and DTB file. From the kernel source execute :


$ mkdir ../mnt/
$ sudo mount /dev/sdX3 ../mnt/
$ sudo cp arch/arm/boot/uImage ../mnt/
$ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb= ../mnt/
$ sudo umount /dev/sdX3


Finally, we have to copy the Ubuntu userspace f= ilesystem that we created earlier:


$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./preci= se/* mnt/$ sudo umount /dev/sdX4


Now,my idea is to chainload the already chain load= ed u-boot created by V.O.S to the new u-boot that we need for booting FreeB= SD and that can be installed in the partition n.2,as shown in this scheme,b= ecause it is not used :


Partition 1 =3D ChromeOS signed binary (V.O.S chai= ned u-boot)
Partition 2 =3D not used (maybe we can install the= u-boot for arm 32 bit,compatible with FreeBSD on this partition)
Partition 3 =3D EXT2 partition for u-boot files (u= Image and exynos5250-snow.dtb)
Partition 4 =3D EXT4 partition for userspace files


Take in consideration that default boot string is = hardcoded here,in the snow.h file of the custom u-boot created by VOS :


https://github.com= /virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101


and it needs to be recompiled because it should po= int to the partition n.2,where I will install the u-boot files as explained= here :


https://wiki.freebsd= .org/arm/Chromebook


I have some questions to ask before I start workin= g on this.

1) The xen developer said :


You should be able to build U-Boot and use the U= -Boot binary as Xen guest kernel...


where is the u-boot binary,according to this docum= ent ?

https://wiki.freebsd= .org/arm/Chromebook

I don't see it.


2) where is the source code of the file that I can= get here :

http://commo= ndatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-si= mplefb.kpart.bz2

I need the source code if I want to recompile u-bo= ot so that it can point to the partition 4.

Maybe it can be found on this link :

http://lin= ux-exynos.org/dist/chromebook/nv_uboot/

but it can't be opened....


3) in this specific scenario the source code of u-= boot should run on arm 32 bit,not on arm 64,because I have the Samsung Chro= mebook "SNOW" model XE303C12,that's powered by a Samsung Exyn= os 5250 (ARMv7 32 bit Cortex A15) Soc.


4) I'm not sure if I can chainload the customi= zed u-boot created by V.O.S that should be installed on the first partition= with the u-boot tailored for booting FreeBSD that should be installed on t= he partition 2....


5) the xen developer said that u-boot should be co= mpiled enabling this option :


Code:=20 

CONFIG_CMO_BY_VA_ONLY=3Dy<=
/code>


Well,can you provide some good source that can hel= p me to understand how I can recompile u-boot for FreeBSD ? thanks.

--
Mario.


--
Mario.


--
Mario.


--
Mario.


--
Mario.


--
Mario.
--0000000000000f32f8060cf520da-- From nobody Wed Dec 20 22:12:46 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwSWF548qz55PY8 for ; Wed, 20 Dec 2023 22:13:29 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwSWD4X4yz3XJg for ; Wed, 20 Dec 2023 22:13:28 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=QuorgpLj; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a2330a92ae6so17376566b.0 for ; Wed, 20 Dec 2023 14:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703110404; x=1703715204; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u1cmjSims7ukcf95xOKI4C2dpiBpFUlvQK1qY4BeDSI=; b=QuorgpLjfCfvaxPl7bRBBYT+krUdTeBciYLlcvFAdexuokUmGGiuK5hfn8AgDUSByT XOezfPoJaPXRPFl8q303ia/fURjtUevbPHcitA4gIhnhdckOhKhygdQS/RlOqiAMlMNy PK2uJvXh3FF/Fi3nOD1KcF6Ake76koKxBrYVvLBu8BefBbjlGa6RZK5hefvIa6XWxPcg VPMum7huNaVcM5Z52zQijjW7RNyssNx06vmnmzB8mRyWZk1FAhvoyYc4MZE3n186bOTP NPYFrTmYQ4LSsQfzqIn2PPqQ3pVxpvgSg3TL/5KoUXtqiuvI8J+Hff7BJIhYsX775Gk/ 36qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703110404; x=1703715204; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u1cmjSims7ukcf95xOKI4C2dpiBpFUlvQK1qY4BeDSI=; b=pFuLctSMgpVMHImZ4DRsSVLZSGR+1nw5mSev4IMiAHOgSbDiW9YzXm/kZLELqDnE0h AG0fc3FvNN0sFV5XYzmlVyaKj+Hg/DDAyfl6Lx6hiHfFDRG77p47lRRULqxfdte1y4z2 rEslihNZBQFvOlIppw2RQquEaFrS2A0z6+J9vMzn3iyJh2Jv7HyKfLj6ttO+0GEoMxo3 VvAyiyQxXR9tS0qS+kpRTkIgHBeH3yD2AMVinKrOklVwrAKiSUsv69a4o765S6eIUm3L +pBUxj1rSpEHuYKe08rFlCSSOhnawlWiLI3x76tV77pjfcYDloz28lI8z76mMbOvIKdx /3rw== X-Gm-Message-State: AOJu0YzQpgfAfsEFWEE93ue2+oDXGILAhkpXO1tJBoUWd9H4KxzSBgas a+mEulFM9O9WEyC9B3SKqM+15SOBfoiZdkH7sCo= X-Google-Smtp-Source: AGHT+IGQAkTjxT1xL9Th3aKUy/ADWmwI/SjYlx55sjKYD4xCvSGfQk3IqP+XiQjFXqp6bSPi4aYosey+ZNQ5P21ie64= X-Received: by 2002:a17:906:5502:b0:a23:3fa2:6a77 with SMTP id r2-20020a170906550200b00a233fa26a77mr2955216ejp.114.1703110404063; Wed, 20 Dec 2023 14:13:24 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Wed, 20 Dec 2023 23:12:46 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Stefano Stabellini Cc: Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: multipart/alternative; boundary="000000000000a5c902060cf84aa5" X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4SwSWD4X4yz3XJg X-Spamd-Bar: --- --000000000000a5c902060cf84aa5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. maybe I'm using the wrong u-boot.bin file. Maybe I found the correct bootloader. It is not the u-boot.bin file,but maybe I can use it anyway,maybe I can convert it to u-boot.bin. Anyway,I'm reading the procedure used here : https://wiki.freebsd.org/arm/Chromebook this is the interesting part : Populating the U-Boot Partition # fetch http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2# bunzip2 nv_uboot-snow-simplefb.kpart.bz2# dd if=3Dnv_uboot-snow-simplefb.kpart of=3D/dev/da0p1 bs=3D1m It seems that the file nv_uboot-snow-simplefb.kpart is able to boot FreeBSD. I tried to follow the tutorial,so I have dd'ed it on the first partition of my sd card : # dd if=3Dnv_uboot-snow-simplefb.kpart of=3D/dev/sdf1 bs=3D1m and then I tried to mount it because I hoped to find the u-boot.bin file inside the partition,but I haven't been able to mount it: $ sudo mount /dev/sdf1 /mnt/sdf1 mount: /mnt/sdf1: wrong fs type, bad option, bad superblock on /dev/sdf1, missing codepage or helper program, or other error. dmesg(1) may have more information after a failed mount system call. Is there a way to convert that kpart file into an u-boot.bin file ? I see that the source code to generate it is not there. Infact this website does not work : http://linux-exynos.org/dist/chromebook/nv_uboot/ On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini wrote: > +Michal > > Hi Mario, > > I am not sure about booting FreeBSD, but I am certain that u-boot works > fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config > file: > > name=3D"test" > kernel=3D"u-boot.bin" > extra =3D "console=3Dhvc0" > memory=3D256 > vcpus=3D1 > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > I don't know for sure if you can boot FreeBSD but you should definitely > be able to see the u-boot command line prompt. The fact that you are > getting this message: > > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: > Invalid kernel > > Means that something is not right in the u-boot configuration or u-boot > build. Michal and Artem (CCed) might know more. From what I recall, > there was nothing special required to get u-boot.bin to boot as domU > kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. > > Cheers, > > Stefano > > > On Tue, 19 Dec 2023, Mario Marietto wrote: > > ....I see that some other interesting files have been produced by u-boo= t > when I have compiled it : > > > > u-boot > > u-boot.lds > > u-boot.bin > > u-boot.map > > u-boot-nodtb.bin > > u-boot.dtb > > u-boot.srec > > u-boot-dtb.bin > > u-boot.sym > > > > So,maybe I should use a different u-boot* file for booting FreeBSD ? > > > > > > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto > wrote: > > Hello to everyone. > > > > I have compiled the needed u-boot.bin from scratch using this procedure= : > > > > # git clone https://github.com/u-boot/u-boot.git > > # cd u-boot > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig := this > line generates the file .config > > # nano .config and I've added these parameters : > > > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > > > the uboot-bin file is generated with this command : > > > > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make > > > > At this point,I took a look inside the .config file and I saw that the > parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for > > some reason,it is not accepted and this could be a problem.... > > > > These are the xen config files that I've used : > > > > nano freebsd.cfg > > > > name=3D"test" > > kernel=3D"u-boot.bin" > > extra =3D "console=3Dhvc0" > > memory=3D256 > > vcpus=3D1 > > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > > > nano start-freebsd > > > > xl create freebsd.cfg > > xl console freebsd > > > > This is what happens when I launch the vm : > > > > # ./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 fail= ed > > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain > 1:cannot (re-)build domain: -3 > > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > 1:Non-existent domain > > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain > 1:Unable to destroy guest > > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain > 1:Destruction of domain failed > > freebsd is an invalid domain identifier (rc=3D-6) > > > > > > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto > wrote: > > So,ok,I should have said "the second u-boot" ; since the first > u-boot binary is the "u-boot binary located in the RO > > memory" of the Chromebook". Sorry for the confusion. > > > > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto > wrote: > > ---> There are no specific options in u-boot devoted to FreeBSD > > > > This is an important factor. So,what about if,instead of compiling a ne= w > version of u-boot on the partition 2,I will > > recompile the u-boot customized version created by the virtual open > system in 2014,that should be installed on the first > > partition ? It could work if there are no differences between the u-boo= t > that should boot Linux and the u-boot that > > should boot FreeBSD. > > > > Can you give a look at the u-boot source code created by virtual open > systems ? You can find it on my google drive : > > > > > https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?us= p=3Dsharing > > > > I need to understand if I can recompile it without problem so that it > can satisfy my needs (the ability of the file > > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano > Stabellini,the xen developer that suggested to me > > what I could do to have FreeBSD virtualized under Xen on my Arm > Chromebook) ; otherwise the risk is to find later > > problems that will make me troubles and that I will not able to fix. > > > > I gave a look at the virtual open system u-boot and I didn't see any > arndale_defconfig inside. So,If I have understood > > correctly,I should put that file inside the root of the u-boot source > code,let's say here : > > > > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > > > > .checkpatch.conf README doc > net > > .git api drivers > onenand_ipl > > .gitignore arch dts > post > > COPYING board examples > rules.mk > > CREDITS boards.cfg fs > scripts > > MAINTAINERS common include > snapshot.commit > > MAKEALL config.mk lib > spl > > Makefile cros mkconfig > test > > PRESUBMIT.cfg disk nand_spl > tools > > > > and I should do : make and make install ? and the file I need,u-boot.bi= n > will be generated ? > > > > I didn't find any pre made configuration file inside : > > > > u-boot-vos # find . -type f -name "exynos*" > > > > ./include/exynos-fb.h > > ./include/configs/exynos5-common.h > > ./doc/device-tree-bindings/spi/exynos-spi.txt > > ./doc/device-tree-bindings/usb/exynos-usb.txt > > ./drivers/power/exynos-tmu.c > > ./drivers/power/exynos-cpufreq.c > > ./drivers/video/exynos-fb.c > > ./drivers/spi/exynos_spi.c > > ./board/samsung/dts/exynos5250-spring.dts > > ./board/samsung/dts/exynos5250-smdk5250.dts > > ./board/samsung/dts/exynos5250-snow.dts > > ./board/samsung/dts/exynos5250-daisy.dts > > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h > > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h > > ./arch/arm/dts/exynos5250.dtsi > > ./arch/arm/dts/exynos-periph-id.dtsi > > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c > > > > u-boot-vos # find . -type f -name "arndale*" > > > > For sure I can't use a newer version of u-boot because otherwise the > patches needed to bypass the bootloader protections > > of the Arm Chromebook (such as a lot of different patches needed to boo= t > correctly Linux) will be broken ; anyway,since > > it works,I don't need to use an updated version of u-boot. > > > > ----> As per my experience, you have to respect these two options, > compiling u-boot for > > FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > > > It says that I should use these parameters : > > > > CONFIG_ARMV7_NONSEC=3Dn > > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > > > > These are the parameters used to configure a Linux kernel. I don't > understand what's the relation between the compilation > > of a linux kernel and u-boot. In the past I tried to recompile > u-boot,but I didn't have the need to set up those > > parameters,so I don't know how to do it (but I know how to recompile a > Linux kernel). > > > > ---> I'm not sure that I'm getting you right, as I don't understand wha= t > you mean under "the first u-boot". > > > > > > I'm talking about first u-boot because the whole procedure to boot Linu= x > on the ARM Chromebook,that's explained here : > > > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / > > > > > > at some point they say : > > > > > > To be able to run KVM on ARM platforms, the kernel has to be booted in > hypervisor mode. Because of this relatively recent > > requirement (due to the introduction of the virtualization extensions), > up until now all booting methods would boot the > > kernel in the standard Supervisor mode. > > > > For the ARM Chromebook the default boot procedure doesn't allow us to > boot in hypervisor mode. Although the laptop's boot > > mechanism is based on the frequently used u-boot, the binary is located > in RO memory. Fortunately, a chained u-boot > > mechanism can be used (i.e. starting another u-boot after the original)= . > We can then enter hypervisor mode from our > > custom iteration of u-boot and subsequently load our kernel and > userspace. > > > > So,the first u-boot is the u-boot provided by virtual open > systems,that's able to chainload the "u-boot binary located in > > RO memory" , that does not boot Chrome OS in hypervisor mode. We don't > need it if we want to boot Linux with kvm or xen > > enabled. > > > > > > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > > I'm not an expert in the topic, I only know, that ARM has divided > hardware into two worlds - Secure and > > Not-So, strictly limiting any software, running in non-secure > world with access to functions and > > resources. > https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hard= ware-architecture?lang=3Den > > > > I'm not sure, that I'm getting you right, as I don't understand what yo= u > mean under "the first u-boot". > > > > As I understand, virtualization (HYP) is running in non-secure world( > https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectu= re/The-System-Level-Programmers--Model/The-Virtualization-Extens > > ions), so my guess (only guess!!!), virtualization software has to > prepare (configure) HW platform in the way, > > that FreeBSD kernel will not lack any resources, required to configure > MPU, VA, etc. > > So, if you lucky to boot virtualizer, which is aware of target OS, that > maybe you can boot the kernel. Although, I > > doubt, that you need to boot 'second' u-boot to boot the kernel - there > is simply ubldr, which you can hook somehow > > from virtualizer.... > > > > Stan > > > > > > > > Mario Marietto wrote: > > > > > > ---> As I understand, it makes sure that u-boot keeps in secure > mode during boot and passes control to > > ubldr, which boots FreeBSD kernel, in that mode. > > > > Can you elaborate your sentence more ? I know that the bootloader secur= e > mode is bypassed by the virtual open > > systems u-boot. Are you saying that when the control passes to the > second u-boot,it will happen in secure > > mode,so that the bypass that happened loading the first u-boot,is > annulled ? If this is true,maybe can I boot > > FreeBSD using the virtual-open-system custom u-boot ? Is this compatibl= e > with FreeBSD ? Where can I find the > > u-boot.bin that the xen developer talked about ? thanks bro'. > > > > > > > > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < > stanislav.silnicki@mailgate.us> wrote: > > Hi Mario, > > > > U-Boot beast is hiding in this den: > https://source.denx.de/u-boot/u-boot.git > > I took a brief look at your post and it seems to me, that > option CONFIG_CMO_BY_VA_ONLY is irrelevant to > > your target armv7 32 bit > > platform: > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kco= nfig?ref_type=3Dheads#L3 > > > > As for compiling the u-boot, it is a doable task, given that you > understand what you are doing. There > > are no specific options in u-boot devoted to FreeBSD. It is a boot > loader, whose mission to make basic > > hardware initialization, read you kernel file from some media into RAM > and then pass it control. > > > > Basically, you can grab some defconfig, prepared for any other > Exynos5250 based board (say, this one: > > > https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defcon= fig?ref_type=3Dheads) > and adopt > > it somehow. > > > > As per my experience, you have to respect these two options, compiling > u-boot for > > FreeBSD: > https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-master= /files/FreeBSD_Fragment > > > > As I understand, it makes sure, that u-boot keeps in secure mode during > boot and passes control to > > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot > of surprises you may realize. > > > > Hope, this will help to progress you tasks > > Stan > > > > Mario Marietto wrote: > > > > > > Hello. > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM > Chromebook. Basically there are > > two ways to accomplish this task : > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a > zImage file. This could be > > accomplished applying this patch to a specific file that's on the > source code of FreeBSD : > > > > > > > https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f= 986c979edef0c9 > > > > > > This patch was written by Julien Grall a lot of time ago and now > it does not work anymore. > > This is the reason : > > > > > > 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. > And I'm not able to fix it. > > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > > > > I was trying to explain why and how Julien's patch works so that > you could be the one > > to re-do something similar or fix the patch on the FreeBSD kernel > that you are > > working with. I am happy to help review and write patches but I > don't work with the > > FreeBSD kernel so I wouldn't be able to help you quickly. However= , > I might have a > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > Because U-Boot > > definitely boots as Xen on ARM guest firmware/bootloader. You > should be able to build > > U-Boot and use the U-Boot binary as Xen guest kernel, then U-Boot > could load FreeBSD > > from disk or network and start it. For instance as domU config > file: > > > > kernel=3D"/home/petalinux/u-boot.bin" > > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] > > > > I know it is important to build u-boot with the following config > to make it work on > > Xen. > > > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > > > > > This option seems more doable to me according to my knowledge. But I > need to understand how to do > > it. > > > > Well,let's say that on the ARM Chromebook I'm forced to use and install > a customized version of > > u-boot,created by virtual open systems,because it is the only one that > allows bypassing its > > bootloader protection. You can find more information here : > > > > > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?= vos=3Dtech > > > > This is the relevant section to read : > > > > > > Bootloader : > > > > If you wish to skip this chapter you can download a pre-compiled > binary of the > > bootloader: > > > > > > $ wget > > > http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u= -boot-snow.kpart > > > > > > To be able to run KVM on ARM platforms, the kernel has to be > booted in hypervisor > > mode. Because of this relatively recent requirement (due to the > introduction of the > > virtualization extensions), up until now all booting methods woul= d > boot the kernel in > > the standard Supervisor mode. For the ARM Chromebook the default > boot procedure > > doesn't allow us to boot in hypervisor mode. Although the laptop'= s > boot mechanism is > > based on the frequently used u-boot, the binary is located in RO > memory. Fortunately, > > a chained u-boot mechanism can be used (i.e. starting another > u-boot after the > > original). We can then enter hypervisor mode from our custom > iteration of u-boot and > > subsequently load our kernel and userspace. > > > > Checkout the needed u-boot code : > > > > > > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd > u-boot$ > > ./scripts/build.sh > > > > > > If successful, a message about how to copy the bootloader on the > USB flash disk or SD > > card will appear. We will use it later when preparing the boot > medium to start our > > system. If you have followed the Setting up the boot medium > chapter and you have a > > prepared boot device, then you can update u-boot by running : > > > > > > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 > > > > > > > > so,the needed u-boot that we must use should be installed on the first > partition of the sd card. > > > > There is another relevant section to read : > > > > > > Setting up the boot medium > > > > Now it is time to copy all the relevant files that we created in > the previous > > chapters,and use them to boot Chromebook with a different kernel > and OS. In all these > > examples the device /dev/sdX is used. Take extra care to change > the examples to the > > device that you have attached. Insert the boot medium on your > workstation and > > carefully execute the following step. First we need to properly > format the boot > > medium. > > > > In the uboot source directory : > > > > > > $ sudo ./scripts/sdcard.sh /dev/sdX > > > > > > This will erase all data and create 4 partitions in the medium, > along with copying > > the u-boot binary to the first partition: > > > > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used > > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > > > > > > With u-boot being copied, next is the kernel image and DTB file. > From the kernel > > source execute : > > > > > > $ mkdir ../mnt/ > > $ sudo mount /dev/sdX3 ../mnt/ > > $ sudo cp arch/arm/boot/uImage ../mnt/ > > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ > > $ sudo umount /dev/sdX3 > > > > > > Finally, we have to copy the Ubuntu userspace filesystem that we > created earlier: > > > > > > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo > umount /dev/sdX4 > > > > > > > > Now,my idea is to chainload the already chain loaded u-boot created by > V.O.S to the new u-boot > > that we need for booting FreeBSD and that can be installed in the > partition n.2,as shown in this > > scheme,because it is not used : > > > > > > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 > bit,compatible with FreeBSD on > > this partition) > > Partition 3 =3D EXT2 partition for u-boot files (uImage and > exynos5250-snow.dtb) > > Partition 4 =3D EXT4 partition for userspace files > > > > > > Take in consideration that default boot string is hardcoded here,in the > snow.h file of the custom > > u-boot created by VOS : > > > > > > > https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/s= now.h#L101 > > > > > > and it needs to be recompiled because it should point to the partition > n.2,where I will install > > the u-boot files as explained here : > > > > > > https://wiki.freebsd.org/arm/Chromebook > > > > > > I have some questions to ask before I start working on this. > > > > 1) The xen developer said : > > > > > > You should be able to build U-Boot and use the U-Boot binary as > Xen guest kernel... > > > > > > > > where is the u-boot binary,according to this document ? > > > > https://wiki.freebsd.org/arm/Chromebook > > > > I don't see it. > > > > > > 2) where is the source code of the file that I can get here : > > > > > http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv= _uboot-snow-simplefb.kpart.bz2 > > > > I need the source code if I want to recompile u-boot so that it can > point to the partition 4. > > > > Maybe it can be found on this link : > > > > http://linux-exynos.org/dist/chromebook/nv_uboot/ > > > > but it can't be opened.... > > > > > > 3) in this specific scenario the source code of u-boot should run on ar= m > 32 bit,not on arm > > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's > powered by a Samsung Exynos > > 5250 (ARMv7 32 bit Cortex A15) Soc. > > > > > > 4) I'm not sure if I can chainload the customized u-boot created by > V.O.S that should be > > installed on the first partition with the u-boot tailored for booting > FreeBSD that should be > > installed on the partition 2.... > > > > > > 5) the xen developer said that u-boot should be compiled enabling this > option : > > > > > > Code: > > > > CONFIG_CMO_BY_VA_ONLY=3Dy > > > > > > Well,can you provide some good source that can help me to understand ho= w > I can recompile u-boot > > for FreeBSD ? thanks. > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > > > > > -- > > Mario. > > > > --=20 Mario. --000000000000a5c902060cf84aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

maybe I'm using t= he wrong u-boot.bin file. Maybe I found the correct bootloader. It is not t= he u-boot.bin file,but maybe I can use it anyway,maybe I can convert it to = u-boot.bin. Anyway,I'm reading the procedure used here :
=

this is the in= teresting part :

Populating the U-Boot Partition

# fetch http://commondatastorage.googleapis.com/= chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 # bunzip2 nv_uboo= t-snow-simplefb.kpart.bz2 # dd if=3Dnv_uboo= t-snow-simplefb.kpart of=3D/dev/da0p1 bs=3D1m


It seem=
s that the file nv_uboot-snow-simplefb.kpart is able to boot FreeBSD. I tri=
ed to follow the tutorial,so I have dd'ed it 
on the first partition=
 of my sd card :

=
# dd if=3Dnv_uboot-snow-simplefb.kpart of=3D/dev/sdf1 bs=3D1m
and then I tried to mount it because I hoped to find the u-boot=
.bin file inside the partition,but I haven't been able to mount it:
=

$ sudo mount /dev/sdf1 /mnt/sdf1

mount: /mnt/sdf1: wrong fs type, bad option, bad superblock on /=
dev/sdf1, missing codepage or helper program, or other error.
dmesg(1) may have more information after a failed mount system call.

Is there a way to convert that kpart file into an u-b=
oot.bin file ? I see that the source code to generate it is not there. 
=

Infact this website does not work : http://linux-exynos.org/dist/chromebook/nv_uboot=
/

=
On Tue, Dec 19, 2023 at 8:33=E2=80=AF= PM Stefano Stabellini <sstabel= lini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/do= cumentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much= .
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.
--000000000000a5c902060cf84aa5-- From nobody Wed Dec 20 22:48:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwTJQ3099z55QqN for ; Wed, 20 Dec 2023 22:49:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwTJP6m0Pz3Yw5 for ; Wed, 20 Dec 2023 22:49:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40c236624edso2075915e9.1 for ; Wed, 20 Dec 2023 14:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703112548; x=1703717348; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QLl0/sOJNQNHzP0ZSNP/GLHXADjZRhMbs6neTnPcJsU=; b=qn4AaCCZXbfspktgGlEE3Ga7eLO9jEgEBD2VmWCSb4AzEj6EIsUn2zvJtKOavEUDJN YP4eWplrQIfMcSi4gsmbjfeU/MljfJm2S9anRocX2S8lUPrRyyhPbbH4+WDmqxXd6H3j sWBoKU7MaE7/TGbKjIOP5Nc2XVw6cuFy2fI8hJvqka4BPAnTC68UFCPpBlb77ncnOB2v oyMaFJstVe9JfLBd3dqBf2OY8vzq56eG6NZMleR0LkdRj9DShoCNEQAo71aGLgdoyJxL PFoM13SMUwwpdl4R75h2XaHjEWV7vD3c60pu3PI4ovI0mTdrB7HOgnY7AUqhU0zrWgQa /VDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703112548; x=1703717348; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QLl0/sOJNQNHzP0ZSNP/GLHXADjZRhMbs6neTnPcJsU=; b=g27L9s35Bk9B28esDuzHG57NcHGb2q6g+XjC3E9I9JGeKXRX8C684ZIiHT8QVq/pmf rXqa6vHn3omV4TsvLhiHCW3a8D0rMx5tGOSgPTThEbbrajUCRnfPC9NJqkSXJ/nIaVN+ qCpZMtDnmtCP8nMh12Eol12NAy299AsQeQkY84BNCyxhfxAsQqog59ViJTNBq4caIkjR j/e3g1AeArPHUyO9vaJDlm8tyLUFjVRotcBLgikLP12S6Ufn/CfdtUVV7YBdukJfxijE oR15QTZoMJl+xZnhuwESm0JI2Y1DG/pm+K5P4evMsMW29vRdIwgZ4qcMl5dw+QOmnZpP oKIw== X-Gm-Message-State: AOJu0Yxe/T1o8Be4tav0ZvZpr4MB8QIKPah75Oyrlvlca/yy+oDh79yU iM496UUxAUxQ5RyEM9TOVlrNwf7Y2/qaLj0Zbccko7x2JmkyT6me1KGgaA== X-Google-Smtp-Source: AGHT+IET2iM39Hs7WyhjwgjkPtruEHDvuP4dw9ewtzQAVzPiI+5IM09PXXH6OpbIoX2jhxMgCvruEhhwIjEDOT8zdkA= X-Received: by 2002:a7b:c38d:0:b0:40a:3750:46ff with SMTP id s13-20020a7bc38d000000b0040a375046ffmr251650wmj.11.1703112548034; Wed, 20 Dec 2023 14:49:08 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> In-Reply-To: <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> From: Warner Losh Date: Wed, 20 Dec 2023 15:48:56 -0700 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: titus Cc: freebsd-arm Content-Type: multipart/alternative; boundary="000000000000703ceb060cf8caea" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwTJP6m0Pz3Yw5 --000000000000703ceb060cf8caea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2023 at 12:25=E2=80=AFAM titus wrote: > for the panic @ dhcp see > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288 > https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/ > > its a problem with virtio net driver (was fixed by forum user _martin but > never went in the main tree) > if you emulate another nic type will work > Indeed it does. https://reviews.freebsd.org/D43136 should fix the problem. I think it's the right thing to do. It's what a lot of other drivers do. Warner > On Dec 20, 2023, at 6:52 AM, Warner Losh wrote: > > I'd think you'd need the right virtualization loader. I'm not entirely > sure the u-boot.bin you've been creating is for a dom-u.. > If I misunderstood, then the below isn't good advice. Chain booting the > u-boot, the first u-boot initializes things so you want > to start with stage after the SPL But the different error messages sugges= t > that it's trying to reboot with kexec, which > isn't supported on armv7 at the moment. > > If you could boot in kvm, I think that the following would work.... > Though I'm not entirely sure how to > specify the two .fd files in your setup. The use of qemu is to have an > easy env to debug things... I don't > have a chromebook to try... > > My first instinct would be to try qemu on x86 (this is the first step of > many to get to your destination). > > If you could boot the GENERIC_SD image that we produce using qemu + > edk2-arm-code.fd that would > be a huge first step. This will give you the boot loader, I believe, to > boot in the VM that you need better > than going via the u-boot route. Since you are booting in a virtualized > environment, I think it wouldn't > matter which one :). > > So, I did the following to boot the virtualized armv7 FreeBSD environment= , > following a post on the forums I found and knew to have the right recipe: > > https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qe= mu.80765/ > > 1. pkg install qemu > 2. mkdir qemu-armv7-env > 3. cd qemu-armv7-env > 4. fetch > https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-1= 4.0-RELEASE-arm-armv7-GENERICSD.img.xz > 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv= =3Dnotrunc > 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv= =3Dnotrunc > 10. cat > start-freebsd-arm.sh > #!/bin/sh > qemu-system-arm \ > -M virt \ > -m 1024 \ > -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > -nographic \ > -serial mon:stdio > ^D > 11. chmod +x start-freebsd-arm.sh > 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD > > But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.= 0: > > Starting devd. > Starting dhclient. > DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc4b36a60 > FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c > r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c > r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 > r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 > > panic: Fatal abort > cpuid =3D 0 > time =3D 1680843057 > KDB: stack backtrace: > #0 0xc035786c at kdb_backtrace+0x48 > #1 0xc02fdd20 at vpanic+0x140 > #2 0xc02fdbe0 at vpanic+0 > #3 0xc06304ac at abort_align+0 > #4 0xc063052c at abort_align+0x80 > #5 0xc063017c at abort_handler+0x480 > #6 0xc060f480 at exception_exit+0 > #7 0xc04a9750 at udp_input+0x288 > #8 0xc0473f54 at ip_input+0x1e0 > #9 0xc04447c0 at netisr_dispatch_src+0xf8 > #10 0xc043bf2c at ether_demux+0x1a4 > #11 0xc043d5e4 at ether_nh_input+0x480 > #12 0xc04447c0 at netisr_dispatch_src+0xf8 > #13 0xc043c404 at ether_input+0x50 > #14 0xc01c0838 at vtnet_rx_vq_process+0x880 > #15 0xc01b70d0 at vtpci_intx_intr+0xac > #16 0xc02b87f0 at ithread_loop+0x2ec > #17 0xc02b465c at fork_exit+0xc0 > Uptime: 19s > > I don't know if this is a problem with qemu or FreeBSD's kernel... > > Warner > > On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto > wrote: > >> I've asked some help on the channel #arm on Reddit and someone replied : >> >> >> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_ar= m32_bit_as_domu_with/ >> >> Maybe his answer can be useful to understand why it does not work. >> >> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini < >> sstabellini@kernel.org> wrote: >> >>> +Michal >>> >>> Hi Mario, >>> >>> I am not sure about booting FreeBSD, but I am certain that u-boot works >>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>> file: >>> >>> name=3D"test" >>> kernel=3D"u-boot.bin" >>> extra =3D "console=3Dhvc0" >>> memory=3D256 >>> vcpus=3D1 >>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> >>> I don't know for sure if you can boot FreeBSD but you should definitely >>> be able to see the u-boot command line prompt. The fact that you are >>> getting this message: >>> >>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader >>> found: Invalid kernel >>> >>> Means that something is not right in the u-boot configuration or u-boot >>> build. Michal and Artem (CCed) might know more. From what I recall, >>> there was nothing special required to get u-boot.bin to boot as domU >>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>> >>> Cheers, >>> >>> Stefano >>> >>> >>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>> > ....I see that some other interesting files have been produced by >>> u-boot when I have compiled it : >>> > >>> > u-boot >>> > u-boot.lds >>> > u-boot.bin >>> > u-boot.map >>> > u-boot-nodtb.bin >>> > u-boot.dtb >>> > u-boot.srec >>> > u-boot-dtb.bin >>> > u-boot.sym >>> > >>> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >>> > >>> > >>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto >>> wrote: >>> > Hello to everyone. >>> > >>> > I have compiled the needed u-boot.bin from scratch using this >>> procedure : >>> > >>> > # git clone https://github.com/u-boot/u-boot.git >>> > # cd u-boot >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig= : >>> this line generates the file .config >>> > # nano .config and I've added these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > the uboot-bin file is generated with this command : >>> > >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>> > >>> > At this point,I took a look inside the .config file and I saw that th= e >>> parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>> > some reason,it is not accepted and this could be a problem.... >>> > >>> > These are the xen config files that I've used : >>> > >>> > nano freebsd.cfg >>> > >>> > name=3D"test" >>> > kernel=3D"u-boot.bin" >>> > extra =3D "console=3Dhvc0" >>> > memory=3D256 >>> > vcpus=3D1 >>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> > >>> > nano start-freebsd >>> > >>> > xl create freebsd.cfg >>> > xl console freebsd >>> > >>> > This is what happens when I launch the vm : >>> > >>> > # ./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 >>> 1:cannot (re-)build domain: -3 >>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >>> 1:Non-existent domain >>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >>> 1:Unable to destroy guest >>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >>> 1:Destruction of domain failed >>> > freebsd is an invalid domain identifier (rc=3D-6) >>> > >>> > >>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > So,ok,I should have said "the second u-boot" ; since the first >>> u-boot binary is the "u-boot binary located in the RO >>> > memory" of the Chromebook". Sorry for the confusion. >>> > >>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > ---> There are no specific options in u-boot devoted to FreeBSD >>> > >>> > This is an important factor. So,what about if,instead of compiling a >>> new version of u-boot on the partition 2,I will >>> > recompile the u-boot customized version created by the virtual open >>> system in 2014,that should be installed on the first >>> > partition ? It could work if there are no differences between the >>> u-boot that should boot Linux and the u-boot that >>> > should boot FreeBSD. >>> > >>> > Can you give a look at the u-boot source code created by virtual open >>> systems ? You can find it on my google drive : >>> > >>> > >>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?= usp=3Dsharing >>> > >>> > I need to understand if I can recompile it without problem so that it >>> can satisfy my needs (the ability of the file >>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano >>> Stabellini,the xen developer that suggested to me >>> > what I could do to have FreeBSD virtualized under Xen on my Arm >>> Chromebook) ; otherwise the risk is to find later >>> > problems that will make me troubles and that I will not able to fix. >>> > >>> > I gave a look at the virtual open system u-boot and I didn't see any >>> arndale_defconfig inside. So,If I have understood >>> > correctly,I should put that file inside the root of the u-boot source >>> code,let's say here : >>> > >>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>> > >>> > .checkpatch.conf README doc >>> net >>> > .git api drivers >>> onenand_ipl >>> > .gitignore arch dts >>> post >>> > COPYING board examples >>> rules.mk >>> > CREDITS boards.cfg fs >>> scripts >>> > MAINTAINERS common include >>> snapshot.commit >>> > MAKEALL config.mk lib >>> spl >>> > Makefile cros mkconfig >>> test >>> > PRESUBMIT.cfg disk nand_spl >>> tools >>> > >>> > and I should do : make and make install ? and the file I >>> need,u-boot.bin will be generated ? >>> > >>> > I didn't find any pre made configuration file inside : >>> > >>> > u-boot-vos # find . -type f -name "exynos*" >>> > >>> > ./include/exynos-fb.h >>> > ./include/configs/exynos5-common.h >>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>> > ./drivers/power/exynos-tmu.c >>> > ./drivers/power/exynos-cpufreq.c >>> > ./drivers/video/exynos-fb.c >>> > ./drivers/spi/exynos_spi.c >>> > ./board/samsung/dts/exynos5250-spring.dts >>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>> > ./board/samsung/dts/exynos5250-snow.dts >>> > ./board/samsung/dts/exynos5250-daisy.dts >>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>> > ./arch/arm/dts/exynos5250.dtsi >>> > ./arch/arm/dts/exynos-periph-id.dtsi >>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>> > >>> > u-boot-vos # find . -type f -name "arndale*" >>> > >>> > For sure I can't use a newer version of u-boot because otherwise the >>> patches needed to bypass the bootloader protections >>> > of the Arm Chromebook (such as a lot of different patches needed to >>> boot correctly Linux) will be broken ; anyway,since >>> > it works,I don't need to use an updated version of u-boot. >>> > >>> > ----> As per my experience, you have to respect these two options, >>> compiling u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > It says that I should use these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > These are the parameters used to configure a Linux kernel. I don't >>> understand what's the relation between the compilation >>> > of a linux kernel and u-boot. In the past I tried to recompile >>> u-boot,but I didn't have the need to set up those >>> > parameters,so I don't know how to do it (but I know how to recompile = a >>> Linux kernel). >>> > >>> > ---> I'm not sure that I'm getting you right, as I don't understand >>> what you mean under "the first u-boot". >>> > >>> > >>> > I'm talking about first u-boot because the whole procedure to boot >>> Linux on the ARM Chromebook,that's explained here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / >>> > >>> > >>> > at some point they say : >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be booted i= n >>> hypervisor mode. Because of this relatively recent >>> > requirement (due to the introduction of the virtualization >>> extensions), up until now all booting methods would boot the >>> > kernel in the standard Supervisor mode. >>> > >>> > For the ARM Chromebook the default boot procedure doesn't allow us to >>> boot in hypervisor mode. Although the laptop's boot >>> > mechanism is based on the frequently used u-boot, the binary is >>> located in RO memory. Fortunately, a chained u-boot >>> > mechanism can be used (i.e. starting another u-boot after the >>> original). We can then enter hypervisor mode from our >>> > custom iteration of u-boot and subsequently load our kernel and >>> userspace. >>> > >>> > So,the first u-boot is the u-boot provided by virtual open >>> systems,that's able to chainload the "u-boot binary located in >>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We don'= t >>> need it if we want to boot Linux with kvm or xen >>> > enabled. >>> > >>> > >>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > I'm not an expert in the topic, I only know, that ARM has >>> divided hardware into two worlds - Secure and >>> > Not-So, strictly limiting any software, running in non-secure >>> world with access to functions and >>> > resources. >>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-ha= rdware-architecture?lang=3Den >>> >>> > >>> > I'm not sure, that I'm getting you right, as I don't understand what >>> you mean under "the first u-boot". >>> > >>> > As I understand, virtualization (HYP) is running in non-secure world( >>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architec= ture/The-System-Level-Programmers--Model/The-Virtualization-Extens >>> > ions), so my guess (only guess!!!), virtualization software has to >>> prepare (configure) HW platform in the way, >>> > that FreeBSD kernel will not lack any resources, required to configur= e >>> MPU, VA, etc. >>> > So, if you lucky to boot virtualizer, which is aware of target OS, >>> that maybe you can boot the kernel. Although, I >>> > doubt, that you need to boot 'second' u-boot to boot the kernel - >>> there is simply ubldr, which you can hook somehow >>> > from virtualizer.... >>> > >>> > Stan >>> > >>> > >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > ---> As I understand, it makes sure that u-boot keeps in secure >>> mode during boot and passes control to >>> > ubldr, which boots FreeBSD kernel, in that mode. >>> > >>> > Can you elaborate your sentence more ? I know that the bootloader >>> secure mode is bypassed by the virtual open >>> > systems u-boot. Are you saying that when the control passes to the >>> second u-boot,it will happen in secure >>> > mode,so that the bypass that happened loading the first u-boot,is >>> annulled ? If this is true,maybe can I boot >>> > FreeBSD using the virtual-open-system custom u-boot ? Is this >>> compatible with FreeBSD ? Where can I find the >>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>> > >>> > >>> > >>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > Hi Mario, >>> > >>> > U-Boot beast is hiding in this den: >>> https://source.denx.de/u-boot/u-boot.git >>> > I took a brief look at your post and it seems to me, that >>> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >>> > your target armv7 32 bit >>> > platform: >>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/K= config?ref_type=3Dheads#L3 >>> > >>> > As for compiling the u-boot, it is a doable task, given that you >>> understand what you are doing. There >>> > are no specific options in u-boot devoted to FreeBSD. It is a boot >>> loader, whose mission to make basic >>> > hardware initialization, read you kernel file from some media into RA= M >>> and then pass it control. >>> > >>> > Basically, you can grab some defconfig, prepared for any other >>> Exynos5250 based board (say, this one: >>> > >>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defc= onfig?ref_type=3Dheads) >>> and adopt >>> > it somehow. >>> > >>> > As per my experience, you have to respect these two options, compilin= g >>> u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > As I understand, it makes sure, that u-boot keeps in secure mode >>> during boot and passes control to >>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lo= t >>> of surprises you may realize. >>> > >>> > Hope, this will help to progress you tasks >>> > Stan >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > Hello. >>> > >>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>> Chromebook. Basically there are >>> > two ways to accomplish this task : >>> > >>> > 1) to write a patch that allows the FreeBSD kernel to boot as a >>> zImage file. This could be >>> > accomplished applying this patch to a specific file that's on >>> the source code of FreeBSD : >>> > >>> > >>> > >>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139147271703= 5f986c979edef0c9 >>> > >>> > >>> > This patch was written by Julien Grall a lot of time ago and no= w >>> it does not work anymore. >>> > This is the reason : >>> > >>> > >>> > 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. >>> And I'm not able to fix it. >>> > >>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer= : >>> > >>> > >>> > I was trying to explain why and how Julien's patch works so tha= t >>> you could be the one >>> > to re-do something similar or fix the patch on the FreeBSD >>> kernel that you are >>> > working with. I am happy to help review and write patches but I >>> don't work with the >>> > FreeBSD kernel so I wouldn't be able to help you quickly. >>> However, I might have a >>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >>> Because U-Boot >>> > definitely boots as Xen on ARM guest firmware/bootloader. You >>> should be able to build >>> > U-Boot and use the U-Boot binary as Xen guest kernel, then >>> U-Boot could load FreeBSD >>> > from disk or network and start it. For instance as domU config >>> file: >>> > >>> > kernel=3D"/home/petalinux/u-boot.bin" >>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>> > >>> > I know it is important to build u-boot with the following confi= g >>> to make it work on >>> > Xen. >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > >>> > This option seems more doable to me according to my knowledge. But I >>> need to understand how to do >>> > it. >>> > >>> > Well,let's say that on the ARM Chromebook I'm forced to use and >>> install a customized version of >>> > u-boot,created by virtual open systems,because it is the only one tha= t >>> allows bypassing its >>> > bootloader protection. You can find more information here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= /?vos=3Dtech >>> > >>> > This is the relevant section to read : >>> > >>> > >>> > Bootloader : >>> > >>> > If you wish to skip this chapter you can download a pre-compile= d >>> binary of the >>> > bootloader: >>> > >>> > >>> > $ wget >>> > >>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv= _u-boot-snow.kpart >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be >>> booted in hypervisor >>> > mode. Because of this relatively recent requirement (due to the >>> introduction of the >>> > virtualization extensions), up until now all booting methods >>> would boot the kernel in >>> > the standard Supervisor mode. For the ARM Chromebook the defaul= t >>> boot procedure >>> > doesn't allow us to boot in hypervisor mode. Although the >>> laptop's boot mechanism is >>> > based on the frequently used u-boot, the binary is located in R= O >>> memory. Fortunately, >>> > a chained u-boot mechanism can be used (i.e. starting another >>> u-boot after the >>> > original). We can then enter hypervisor mode from our custom >>> iteration of u-boot and >>> > subsequently load our kernel and userspace. >>> > >>> > Checkout the needed u-boot code : >>> > >>> > >>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>> u-boot$ >>> > ./scripts/build.sh >>> > >>> > >>> > If successful, a message about how to copy the bootloader on th= e >>> USB flash disk or SD >>> > card will appear. We will use it later when preparing the boot >>> medium to start our >>> > system. If you have followed the Setting up the boot medium >>> chapter and you have a >>> > prepared boot device, then you can update u-boot by running : >>> > >>> > >>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>> > >>> > >>> > >>> > so,the needed u-boot that we must use should be installed on the firs= t >>> partition of the sd card. >>> > >>> > There is another relevant section to read : >>> > >>> > >>> > Setting up the boot medium >>> > >>> > Now it is time to copy all the relevant files that we created i= n >>> the previous >>> > chapters,and use them to boot Chromebook with a different kerne= l >>> and OS. In all these >>> > examples the device /dev/sdX is used. Take extra care to change >>> the examples to the >>> > device that you have attached. Insert the boot medium on your >>> workstation and >>> > carefully execute the following step. First we need to properly >>> format the boot >>> > medium. >>> > >>> > In the uboot source directory : >>> > >>> > >>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>> > >>> > >>> > This will erase all data and create 4 partitions in the medium, >>> along with copying >>> > the u-boot binary to the first partition: >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > With u-boot being copied, next is the kernel image and DTB file= . >>> From the kernel >>> > source execute : >>> > >>> > >>> > $ mkdir ../mnt/ >>> > $ sudo mount /dev/sdX3 ../mnt/ >>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>> > $ sudo umount /dev/sdX3 >>> > >>> > >>> > Finally, we have to copy the Ubuntu userspace filesystem that w= e >>> created earlier: >>> > >>> > >>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo >>> umount /dev/sdX4 >>> > >>> > >>> > >>> > Now,my idea is to chainload the already chain loaded u-boot created b= y >>> V.O.S to the new u-boot >>> > that we need for booting FreeBSD and that can be installed in the >>> partition n.2,as shown in this >>> > scheme,because it is not used : >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>> bit,compatible with FreeBSD on >>> > this partition) >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > Take in consideration that default boot string is hardcoded here,in >>> the snow.h file of the custom >>> > u-boot created by VOS : >>> > >>> > >>> > >>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs= /snow.h#L101 >>> > >>> > >>> > and it needs to be recompiled because it should point to the partitio= n >>> n.2,where I will install >>> > the u-boot files as explained here : >>> > >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > >>> > I have some questions to ask before I start working on this. >>> > >>> > 1) The xen developer said : >>> > >>> > >>> > You should be able to build U-Boot and use the U-Boot binary as >>> Xen guest kernel... >>> > >>> > >>> > >>> > where is the u-boot binary,according to this document ? >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > I don't see it. >>> > >>> > >>> > 2) where is the source code of the file that I can get here : >>> > >>> > >>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/= nv_uboot-snow-simplefb.kpart.bz2 >>> > >>> > I need the source code if I want to recompile u-boot so that it can >>> point to the partition 4. >>> > >>> > Maybe it can be found on this link : >>> > >>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>> > >>> > but it can't be opened.... >>> > >>> > >>> > 3) in this specific scenario the source code of u-boot should run on >>> arm 32 bit,not on arm >>> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's >>> powered by a Samsung Exynos >>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>> > >>> > >>> > 4) I'm not sure if I can chainload the customized u-boot created by >>> V.O.S that should be >>> > installed on the first partition with the u-boot tailored for booting >>> FreeBSD that should be >>> > installed on the partition 2.... >>> > >>> > >>> > 5) the xen developer said that u-boot should be compiled enabling thi= s >>> option : >>> > >>> > >>> > Code: >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > Well,can you provide some good source that can help me to understand >>> how I can recompile u-boot >>> > for FreeBSD ? thanks. >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >> >> >> >> -- >> Mario. >> > > --000000000000703ceb060cf8caea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 20, 2023 at 12:25=E2=80= =AFAM titus <titus@edc.ro> wrote:=
for the panic @ dhcp see=C2=A0
<= a href=3D"https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qem= u.89016/" target=3D"_blank">https://forums.freebsd.org/threads/kernel-panic= -on-armv7-with-qemu.89016/

its a problem with = virtio net driver (was fixed by forum user _martin but never went in the ma= in tree)
if you emulate another nic type will work

Indeed it does.


should fix the problem. I think it's th= e right thing to do. It's what a lot of other drivers do.
Warner
=C2=A0
On Dec 20, 2023, at 6:52 AM, Warner Losh <imp@bsdimp.com> wrote:=

I'd think you'= ;d need the right virtualization loader. I'm not entirely sure the u-bo= ot.bin you've been creating is for a dom-u..=C2=A0
If I misun= derstood, then the below isn't good advice. Chain booting the u-boot, t= he first u-boot initializes things so you want
to start with stag= e after the SPL But the different error messages suggest that it's tryi= ng to reboot with kexec, which
isn't supported on armv7 at th= e moment.

If you could boot in kvm, I think th= at the following would work....=C2=A0 Though I'm not entirely sure how = to
specify the two .fd files in your setup. The use of qemu is to= have an easy env to debug things... I don't
have a chromeboo= k to try...

My first instinct would be to try = qemu on x86 (this is the first step of many to get to your destination).

If you could boot the GENERIC_SD image that we produ= ce using qemu + edk2-arm-code.fd that would
be a huge first step.= This will give you the boot loader, I believe, to boot in the VM that you = need better
than going via the u-boot route. Since you are bootin= g in a virtualized environment, I think it wouldn't
matter wh= ich one :).

So, I did the following to boot the vi= rtualized armv7 FreeBSD environment, following a post on the forums I found= and knew to have the right recipe:

1. pkg install qemu
2. mkdir qemu-armv7-env
3. cd qemu-armv7-env
5. xz -d -T 0 FreeBSD-14.0-RELEA= SE-arm-armv7-GENERICSD.img.xz
6. dd if=3D/dev/zero of=3Dpflash0.i= mg bs=3D1m count=3D64
7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m coun= t=3D64
8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.im= g conv=3Dnotrunc
9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3D= pflash1.img conv=3Dnotrunc
10. cat > start-freebsd-arm.sh
#!/bin/sh
qemu-system-arm \
=C2=A0 -M virt \
=C2=A0 -m 1024 = \
=C2=A0 -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Do= n \
=C2=A0 -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \
=C2= =A0 -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \
=C2=A0 -nogr= aphic \
=C2=A0 -serial mon:stdio
^D
11. chmod +x sta= rt-freebsd-arm.sh
12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEAS= E-arm-armv7-GENERICSD

But I hit a snag with this o= n qemu 8.1.2 and 8.1.3 with both 13.2 and 14.0:

St= arting devd.
Starting dhclient.
DHCPDISCOVER on vtnet0 to 255.255.255= .255 port 67 interval 7
Fatal kernel mode data abort: 'Alignment Fau= lt' on read
trapframe: 0xc4b36a60
FSR=3D00000001, FAR=3Ddd96701a,= spsr=3D20000013
r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc= 4b36b4c
r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022cr8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90
r12=3D4= 300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750

panic: Fatal= abort
cpuid =3D 0
time =3D 1680843057
KDB: stack backtrace:
#0= 0xc035786c at kdb_backtrace+0x48
#1 0xc02fdd20 at vpanic+0x140
#2 0x= c02fdbe0 at vpanic+0
#3 0xc06304ac at abort_align+0
#4 0xc063052c at = abort_align+0x80
#5 0xc063017c at abort_handler+0x480
#6 0xc060f480 a= t exception_exit+0
#7 0xc04a9750 at udp_input+0x288
#8 0xc0473f54 at = ip_input+0x1e0
#9 0xc04447c0 at netisr_dispatch_src+0xf8
#10 0xc043bf= 2c at ether_demux+0x1a4
#11 0xc043d5e4 at ether_nh_input+0x480
#12 0x= c04447c0 at netisr_dispatch_src+0xf8
#13 0xc043c404 at ether_input+0x50<= br>#14 0xc01c0838 at vtnet_rx_vq_process+0x880
#15 0xc01b70d0 at vtpci_i= ntx_intr+0xac
#16 0xc02b87f0 at ithread_loop+0x2ec
#17 0xc02b465c at = fork_exit+0xc0
Uptime: 19s

I don't know if = this is a problem with qemu or FreeBSD's kernel...

=
Warner

On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto= <marietto20= 08@gmail.com> wrote:
I've asked some help on the channel #= arm on Reddit and someone replied :


Maybe his answer can be useful to understand why it does not work. =

On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini <sstabellini@kerne= l.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/doc= umentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den=
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.

--000000000000703ceb060cf8caea-- From nobody Wed Dec 20 23:07:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwTjJ6CSHz55S33 for ; Wed, 20 Dec 2023 23:07:16 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwTjJ2gYrz3bdK for ; Wed, 20 Dec 2023 23:07:16 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a22f59c6ae6so19071666b.1 for ; Wed, 20 Dec 2023 15:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703113634; x=1703718434; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5tvXPRe/mAQjg0sddjHVIyS7OLk6FPp+bxTAGQzZ2XI=; b=Hn00AfiP9yyOBYe+fthKsOSCuuITsMUm/HM9qziswGp41dYe/Mm/s8A++ooUTtLjKX Lhs9dSITk5uXxVodC2cBB+wsd6ES/vAeFQcHtUb3IeJvEiA21h+0SLNoCRH+FtKyIyZT c2KdBT62DWkECzLKR3oWRS0QqHtS6YVrLN7Nwk2PiRBOy6oV7nrSmMJfvF7Qds4ncNJJ 9ss54N5Ys2L0X/749n+sl+dqK/lXA/+iyQjYalwDFz1D564TnawcIBLz8TNjQTeylzvA zu4uPABj2+kw5QQ0n7bXoLk+k2ovf6dVvFacv1r5f3pqPBMu7HI6hXHA0HOe65MQ0hTd NKHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703113634; x=1703718434; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5tvXPRe/mAQjg0sddjHVIyS7OLk6FPp+bxTAGQzZ2XI=; b=vaCQSXnqSZmRBT4u1++HPn7q7LiWqscQSwx/od7vtZpmMaQIgU54cJzX3sM+uLWWod 2bESfKwarvsjt9KqpiEWBejz7n1xTKVIlbdAG1uj7On0mKWcOPnPql/ZUJpuuxctKXhx xpRhaxGiUXm3FQsKRfTzYm2s1s24b9evBiB1+XXXYAD/AHorscXbEebiz1Jxeb6vC4DO UM6+26DVTbQfz6BjnzWRO1EqGEwSGs4nEFbWjilsmIEziGTIk4bS/DWOR/PZTU6b8a4C ydKtYWeUYf5mLd/vTy4dzDX5H2BwfJs7o+OvhGGRF/pArPG+Oa6o4i3toj2seads0NBf x7Vg== X-Gm-Message-State: AOJu0YyVfieojbCF0OkuOAQnW8ohnBZSmhDY6cYHBrybvwMqma+nHOS3 LTJyV4fgi3IDXOjvQ4fXsQBZ5G+x0Fc1gTmkXJk= X-Google-Smtp-Source: AGHT+IEfs6aJRtOA9pYaP2n4IkEAZ05Il064hHM4MIu1DqmwA2xfvqr6aym2jGZNgvCtg/w6gOb18nQgDpIG4Mg6Q1U= X-Received: by 2002:a17:906:2b16:b0:a23:6a65:9fc3 with SMTP id a22-20020a1709062b1600b00a236a659fc3mr1174610ejg.63.1703113634075; Wed, 20 Dec 2023 15:07:14 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> In-Reply-To: From: Mario Marietto Date: Thu, 21 Dec 2023 00:07:01 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Warner Losh Cc: titus , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000002bd665060cf90b00" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwTjJ2gYrz3bdK --0000000000002bd665060cf90b00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Warner,you didnt read one of my last email,where i said that i have fixed that bug and I can boot my freebsd image with qemu and even the network interface works well. I remember to you that my project is to boot freebsd under xen. Thanks. Il mer 20 dic 2023, 23:49 Warner Losh ha scritto: > > > On Wed, Dec 20, 2023 at 12:25=E2=80=AFAM titus wrote: > >> for the panic @ dhcp see >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288 >> https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016= / >> >> its a problem with virtio net driver (was fixed by forum user _martin bu= t >> never went in the main tree) >> if you emulate another nic type will work >> > > Indeed it does. > > https://reviews.freebsd.org/D43136 > > should fix the problem. I think it's the right thing to do. It's what a > lot of other drivers do. > > Warner > > >> On Dec 20, 2023, at 6:52 AM, Warner Losh wrote: >> >> I'd think you'd need the right virtualization loader. I'm not entirely >> sure the u-boot.bin you've been creating is for a dom-u.. >> If I misunderstood, then the below isn't good advice. Chain booting the >> u-boot, the first u-boot initializes things so you want >> to start with stage after the SPL But the different error messages >> suggest that it's trying to reboot with kexec, which >> isn't supported on armv7 at the moment. >> >> If you could boot in kvm, I think that the following would work.... >> Though I'm not entirely sure how to >> specify the two .fd files in your setup. The use of qemu is to have an >> easy env to debug things... I don't >> have a chromebook to try... >> >> My first instinct would be to try qemu on x86 (this is the first step of >> many to get to your destination). >> >> If you could boot the GENERIC_SD image that we produce using qemu + >> edk2-arm-code.fd that would >> be a huge first step. This will give you the boot loader, I believe, to >> boot in the VM that you need better >> than going via the u-boot route. Since you are booting in a virtualized >> environment, I think it wouldn't >> matter which one :). >> >> So, I did the following to boot the virtualized armv7 FreeBSD >> environment, following a post on the forums I found and knew to have the >> right recipe: >> >> https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-q= emu.80765/ >> >> 1. pkg install qemu >> 2. mkdir qemu-armv7-env >> 3. cd qemu-armv7-env >> 4. fetch >> https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-= 14.0-RELEASE-arm-armv7-GENERICSD.img.xz >> 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz >> 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 >> 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 >> 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img >> conv=3Dnotrunc >> 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img >> conv=3Dnotrunc >> 10. cat > start-freebsd-arm.sh >> #!/bin/sh >> qemu-system-arm \ >> -M virt \ >> -m 1024 \ >> -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ >> -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ >> -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ >> -nographic \ >> -serial mon:stdio >> ^D >> 11. chmod +x start-freebsd-arm.sh >> 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD >> >> But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and >> 14.0: >> >> Starting devd. >> Starting dhclient. >> DHCPDISCOVER on vtnet0 to 255.255.255255 port 67 interval 7 >> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xc4b36a60 >> FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 >> r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c >> r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c >> r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 >> r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 >> >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1680843057 >> KDB: stack backtrace: >> #0 0xc035786c at kdb_backtrace+0x48 >> #1 0xc02fdd20 at vpanic+0x140 >> #2 0xc02fdbe0 at vpanic+0 >> #3 0xc06304ac at abort_align+0 >> #4 0xc063052c at abort_align+0x80 >> #5 0xc063017c at abort_handler+0x480 >> #6 0xc060f480 at exception_exit+0 >> #7 0xc04a9750 at udp_input+0x288 >> #8 0xc0473f54 at ip_input+0x1e0 >> #9 0xc04447c0 at netisr_dispatch_src+0xf8 >> #10 0xc043bf2c at ether_demux+0x1a4 >> #11 0xc043d5e4 at ether_nh_input+0x480 >> #12 0xc04447c0 at netisr_dispatch_src+0xf8 >> #13 0xc043c404 at ether_input+0x50 >> #14 0xc01c0838 at vtnet_rx_vq_process+0x880 >> #15 0xc01b70d0 at vtpci_intx_intr+0xac >> #16 0xc02b87f0 at ithread_loop+0x2ec >> #17 0xc02b465c at fork_exit+0xc0 >> Uptime: 19s >> >> I don't know if this is a problem with qemu or FreeBSD's kernel... >> >> Warner >> >> On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto >> wrote: >> >>> I've asked some help on the channel #arm on Reddit and someone replied = : >>> >>> >>> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_a= rm32_bit_as_domu_with/ >>> >>> Maybe his answer can be useful to understand why it does not work. >>> >>> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini < >>> sstabellini@kernel.org> wrote: >>> >>>> +Michal >>>> >>>> Hi Mario, >>>> >>>> I am not sure about booting FreeBSD, but I am certain that u-boot work= s >>>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>>> file: >>>> >>>> name=3D"test" >>>> kernel=3D"u-boot.bin" >>>> extra =3D "console=3Dhvc0" >>>> memory=3D256 >>>> vcpus=3D1 >>>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>> >>>> I don't know for sure if you can boot FreeBSD but you should definitel= y >>>> be able to see the u-boot command line prompt. The fact that you are >>>> getting this message: >>>> >>>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader >>>> found: Invalid kernel >>>> >>>> Means that something is not right in the u-boot configuration or u-boo= t >>>> build. Michal and Artem (CCed) might know more. From what I recall, >>>> there was nothing special required to get u-boot.bin to boot as domU >>>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>>> >>>> Cheers, >>>> >>>> Stefano >>>> >>>> >>>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>>> > ....I see that some other interesting files have been produced by >>>> u-boot when I have compiled it : >>>> > >>>> > u-boot >>>> > u-boot.lds >>>> > u-boot.bin >>>> > u-boot.map >>>> > u-boot-nodtb.bin >>>> > u-boot.dtb >>>> > u-boot.srec >>>> > u-boot-dtb.bin >>>> > u-boot.sym >>>> > >>>> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >>>> > >>>> > >>>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto < >>>> marietto2008@gmail.com> wrote: >>>> > Hello to everyone. >>>> > >>>> > I have compiled the needed u-boot.bin from scratch using this >>>> procedure : >>>> > >>>> > # git clone https://github.com/u-boot/u-boot.git >>>> > # cd u-boot >>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfi= g : >>>> this line generates the file .config >>>> > # nano .config and I've added these parameters : >>>> > >>>> > CONFIG_ARMV7_NONSEC=3Dn >>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>> > >>>> > the uboot-bin file is generated with this command : >>>> > >>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>>> > >>>> > At this point,I took a look inside the .config file and I saw that >>>> the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>>> > some reason,it is not accepted and this could be a problem.... >>>> > >>>> > These are the xen config files that I've used : >>>> > >>>> > nano freebsd.cfg >>>> > >>>> > name=3D"test" >>>> > kernel=3D"u-boot.bin" >>>> > extra =3D "console=3Dhvc0" >>>> > memory=3D256 >>>> > vcpus=3D1 >>>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>> > >>>> > nano start-freebsd >>>> > >>>> > xl create freebsd.cfg >>>> > xl console freebsd >>>> > >>>> > This is what happens when I launch the vm : >>>> > >>>> > # ./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 >>>> 1:cannot (re-)build domain: -3 >>>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >>>> 1:Non-existent domain >>>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >>>> 1:Unable to destroy guest >>>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >>>> 1:Destruction of domain failed >>>> > freebsd is an invalid domain identifier (rc=3D-6) >>>> > >>>> > >>>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto < >>>> marietto2008@gmail.com> wrote: >>>> > So,ok,I should have said "the second u-boot" ; since the first >>>> u-boot binary is the "u-boot binary located in the RO >>>> > memory" of the Chromebook". Sorry for the confusion. >>>> > >>>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto < >>>> marietto2008@gmail.com> wrote: >>>> > ---> There are no specific options in u-boot devoted to FreeBS= D >>>> > >>>> > This is an important factor. So,what about if,instead of compiling a >>>> new version of u-boot on the partition 2,I will >>>> > recompile the u-boot customized version created by the virtual open >>>> system in 2014,that should be installed on the first >>>> > partition ? It could work if there are no differences between the >>>> u-boot that should boot Linux and the u-boot that >>>> > should boot FreeBSD. >>>> > >>>> > Can you give a look at the u-boot source code created by virtual ope= n >>>> systems ? You can find it on my google drive : >>>> > >>>> > >>>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view= ?usp=3Dsharing >>>> > >>>> > I need to understand if I can recompile it without problem so that i= t >>>> can satisfy my needs (the ability of the file >>>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano >>>> Stabellini,the xen developer that suggested to me >>>> > what I could do to have FreeBSD virtualized under Xen on my Arm >>>> Chromebook) ; otherwise the risk is to find later >>>> > problems that will make me troubles and that I will not able to fix. >>>> > >>>> > I gave a look at the virtual open system u-boot and I didn't see any >>>> arndale_defconfig inside. So,If I have understood >>>> > correctly,I should put that file inside the root of the u-boot sourc= e >>>> code,let's say here : >>>> > >>>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>>> > >>>> > .checkpatch.conf README doc >>>> net >>>> > .git api drivers >>>> onenand_ipl >>>> > .gitignore arch dts >>>> post >>>> > COPYING board examples >>>> rules.mk >>>> > CREDITS boards.cfg fs >>>> scripts >>>> > MAINTAINERS common include >>>> snapshot.commit >>>> > MAKEALL config.mk lib >>>> spl >>>> > Makefile cros mkconfig >>>> test >>>> > PRESUBMIT.cfg disk nand_spl >>>> tools >>>> > >>>> > and I should do : make and make install ? and the file I >>>> need,u-boot.bin will be generated ? >>>> > >>>> > I didn't find any pre made configuration file inside : >>>> > >>>> > u-boot-vos # find . -type f -name "exynos*" >>>> > >>>> > ./include/exynos-fb.h >>>> > ./include/configs/exynos5-common.h >>>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>>> > ./drivers/power/exynos-tmu.c >>>> > ./drivers/power/exynos-cpufreq.c >>>> > ./drivers/video/exynos-fb.c >>>> > ./drivers/spi/exynos_spi.c >>>> > ./board/samsung/dts/exynos5250-spring.dts >>>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>>> > ./board/samsung/dts/exynos5250-snow.dts >>>> > ./board/samsung/dts/exynos5250-daisy.dts >>>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>>> > ./arch/arm/dts/exynos5250.dtsi >>>> > ./arch/arm/dts/exynos-periph-id.dtsi >>>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>>> > >>>> > u-boot-vos # find . -type f -name "arndale*" >>>> > >>>> > For sure I can't use a newer version of u-boot because otherwise the >>>> patches needed to bypass the bootloader protections >>>> > of the Arm Chromebook (such as a lot of different patches needed to >>>> boot correctly Linux) will be broken ; anyway,since >>>> > it works,I don't need to use an updated version of u-boot. >>>> > >>>> > ----> As per my experience, you have to respect these two options, >>>> compiling u-boot for >>>> > FreeBSD: >>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mas= ter/files/FreeBSD_Fragment >>>> > >>>> > It says that I should use these parameters : >>>> > >>>> > CONFIG_ARMV7_NONSEC=3Dn >>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>> > >>>> > These are the parameters used to configure a Linux kernel. I don't >>>> understand what's the relation between the compilation >>>> > of a linux kernel and u-boot. In the past I tried to recompile >>>> u-boot,but I didn't have the need to set up those >>>> > parameters,so I don't know how to do it (but I know how to recompile >>>> a Linux kernel). >>>> > >>>> > ---> I'm not sure that I'm getting you right, as I don't understand >>>> what you mean under "the first u-boot". >>>> > >>>> > >>>> > I'm talking about first u-boot because the whole procedure to boot >>>> Linux on the ARM Chromebook,that's explained here : >>>> > >>>> > >>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeboo= k/ >>>> > >>>> > >>>> > at some point they say : >>>> > >>>> > >>>> > To be able to run KVM on ARM platforms, the kernel has to be booted >>>> in hypervisor mode. Because of this relatively recent >>>> > requirement (due to the introduction of the virtualization >>>> extensions), up until now all booting methods would boot the >>>> > kernel in the standard Supervisor mode. >>>> > >>>> > For the ARM Chromebook the default boot procedure doesn't allow us t= o >>>> boot in hypervisor mode. Although the laptop's boot >>>> > mechanism is based on the frequently used u-boot, the binary is >>>> located in RO memory. Fortunately, a chained u-boot >>>> > mechanism can be used (i.e. starting another u-boot after the >>>> original). We can then enter hypervisor mode from our >>>> > custom iteration of u-boot and subsequently load our kernel and >>>> userspace. >>>> > >>>> > So,the first u-boot is the u-boot provided by virtual open >>>> systems,that's able to chainload the "u-boot binary located in >>>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We >>>> don't need it if we want to boot Linux with kvm or xen >>>> > enabled. >>>> > >>>> > >>>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>>> stanislav.silnicki@mailgate.us> wrote: >>>> > I'm not an expert in the topic, I only know, that ARM has >>>> divided hardware into two worlds - Secure and >>>> > Not-So, strictly limiting any software, running in non-secure >>>> world with access to functions and >>>> > resources. >>>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-h= ardware-architecture?lang=3Den >>>> >>>> > >>>> > I'm not sure, that I'm getting you right, as I don't understand what >>>> you mean under "the first u-boot". >>>> > >>>> > As I understand, virtualization (HYP) is running in non-secure world= ( >>>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Archite= cture/The-System-Level-Programmers--Model/The-Virtualization-Extens >>>> > ions), so my guess (only guess!!!), virtualization software has to >>>> prepare (configure) HW platform in the way, >>>> > that FreeBSD kernel will not lack any resources, required to >>>> configure MPU, VA, etc. >>>> > So, if you lucky to boot virtualizer, which is aware of target OS, >>>> that maybe you can boot the kernel. Although, I >>>> > doubt, that you need to boot 'second' u-boot to boot the kernel - >>>> there is simply ubldr, which you can hook somehow >>>> > from virtualizer.... >>>> > >>>> > Stan >>>> > >>>> > >>>> > >>>> > Mario Marietto wrote: >>>> > >>>> > >>>> > ---> As I understand, it makes sure that u-boot keeps in secur= e >>>> mode during boot and passes control to >>>> > ubldr, which boots FreeBSD kernel, in that mode. >>>> > >>>> > Can you elaborate your sentence more ? I know that the bootloader >>>> secure mode is bypassed by the virtual open >>>> > systems u-boot. Are you saying that when the control passes to the >>>> second u-boot,it will happen in secure >>>> > mode,so that the bypass that happened loading the first u-boot,is >>>> annulled ? If this is true,maybe can I boot >>>> > FreeBSD using the virtual-open-system custom u-boot ? Is this >>>> compatible with FreeBSD ? Where can I find the >>>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>>> > >>>> > >>>> > >>>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>>> stanislav.silnicki@mailgate.us> wrote: >>>> > Hi Mario, >>>> > >>>> > U-Boot beast is hiding in this den: >>>> https://source.denx.de/u-boot/u-boot.git >>>> > I took a brief look at your post and it seems to me, that >>>> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >>>> > your target armv7 32 bit >>>> > platform: >>>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/= Kconfig?ref_type=3Dheads#L3 >>>> > >>>> > As for compiling the u-boot, it is a doable task, given that you >>>> understand what you are doing. There >>>> > are no specific options in u-boot devoted to FreeBSD. It is a boot >>>> loader, whose mission to make basic >>>> > hardware initialization, read you kernel file from some media into >>>> RAM and then pass it control. >>>> > >>>> > Basically, you can grab some defconfig, prepared for any other >>>> Exynos5250 based board (say, this one: >>>> > >>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_def= config?ref_type=3Dheads) >>>> and adopt >>>> > it somehow. >>>> > >>>> > As per my experience, you have to respect these two options, >>>> compiling u-boot for >>>> > FreeBSD: >>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mas= ter/files/FreeBSD_Fragment >>>> > >>>> > As I understand, it makes sure, that u-boot keeps in secure mode >>>> during boot and passes control to >>>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a >>>> lot of surprises you may realize. >>>> > >>>> > Hope, this will help to progress you tasks >>>> > Stan >>>> > >>>> > Mario Marietto wrote: >>>> > >>>> > >>>> > Hello. >>>> > >>>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>>> Chromebook. Basically there are >>>> > two ways to accomplish this task : >>>> > >>>> > 1) to write a patch that allows the FreeBSD kernel to boot as = a >>>> zImage file. This could be >>>> > accomplished applying this patch to a specific file that's on >>>> the source code of FreeBSD : >>>> > >>>> > >>>> > >>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc13914727170= 35f986c979edef0c9 >>>> > >>>> > >>>> > This patch was written by Julien Grall a lot of time ago and >>>> now it does not work anymore. >>>> > This is the reason : >>>> > >>>> > >>>> > It appears FreeBSD-CURRENT removed the last step >>>> converting the kernel file to >>>> > kernel.bin. The patch can be readily rebased, but withou= t >>>> kernel.bin that >>>> > doesn't do too much >>>> > >>>> > >>>> > >>>> > So,without a rebase of that patch the first option is not applicable= . >>>> And I'm not able to fix it. >>>> > >>>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen develope= r >>>> : >>>> > >>>> > >>>> > I was trying to explain why and how Julien's patch works so >>>> that you could be the one >>>> > to re-do something similar or fix the patch on the FreeBSD >>>> kernel that you are >>>> > working with. I am happy to help review and write patches but = I >>>> don't work with the >>>> > FreeBSD kernel so I wouldn't be able to help you quickly. >>>> However, I might have a >>>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >>>> Because U-Boot >>>> > definitely boots as Xen on ARM guest firmware/bootloader. You >>>> should be able to build >>>> > U-Boot and use the U-Boot binary as Xen guest kernel, then >>>> U-Boot could load FreeBSD >>>> > from disk or network and start it. For instance as domU config >>>> file: >>>> > >>>> > kernel=3D"/home/petalinux/u-boot.bin" >>>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>> > >>>> > I know it is important to build u-boot with the following >>>> config to make it work on >>>> > Xen. >>>> > >>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>> > >>>> > >>>> > >>>> > This option seems more doable to me according to my knowledge. But I >>>> need to understand how to do >>>> > it. >>>> > >>>> > Well,let's say that on the ARM Chromebook I'm forced to use and >>>> install a customized version of >>>> > u-boot,created by virtual open systems,because it is the only one >>>> that allows bypassing its >>>> > bootloader protection. You can find more information here : >>>> > >>>> > >>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeboo= k/?vos=3Dtech >>>> > >>>> > This is the relevant section to read : >>>> > >>>> > >>>> > Bootloader : >>>> > >>>> > If you wish to skip this chapter you can download a >>>> pre-compiled binary of the >>>> > bootloader: >>>> > >>>> > >>>> > $ wget >>>> > >>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/n= v_u-boot-snow.kpart >>>> > >>>> > >>>> > To be able to run KVM on ARM platforms, the kernel has to be >>>> booted in hypervisor >>>> > mode. Because of this relatively recent requirement (due to th= e >>>> introduction of the >>>> > virtualization extensions), up until now all booting methods >>>> would boot the kernel in >>>> > the standard Supervisor mode. For the ARM Chromebook the >>>> default boot procedure >>>> > doesn't allow us to boot in hypervisor mode. Although the >>>> laptop's boot mechanism is >>>> > based on the frequently used u-boot, the binary is located in >>>> RO memory. Fortunately, >>>> > a chained u-boot mechanism can be used (i.e. starting another >>>> u-boot after the >>>> > original). We can then enter hypervisor mode from our custom >>>> iteration of u-boot and >>>> > subsequently load our kernel and userspace. >>>> > >>>> > Checkout the needed u-boot code : >>>> > >>>> > >>>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>>> u-boot$ >>>> > ./scripts/build.sh >>>> > >>>> > >>>> > If successful, a message about how to copy the bootloader on >>>> the USB flash disk or SD >>>> > card will appear. We will use it later when preparing the boot >>>> medium to start our >>>> > system. If you have followed the Setting up the boot medium >>>> chapter and you have a >>>> > prepared boot device, then you can update u-boot by running : >>>> > >>>> > >>>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>> > >>>> > >>>> > >>>> > so,the needed u-boot that we must use should be installed on the >>>> first partition of the sd card. >>>> > >>>> > There is another relevant section to read : >>>> > >>>> > >>>> > Setting up the boot medium >>>> > >>>> > Now it is time to copy all the relevant files that we created >>>> in the previous >>>> > chapters,and use them to boot Chromebook with a different >>>> kernel and OS. In all these >>>> > examples the device /dev/sdX is used. Take extra care to chang= e >>>> the examples to the >>>> > device that you have attached. Insert the boot medium on your >>>> workstation and >>>> > carefully execute the following step. First we need to properl= y >>>> format the boot >>>> > medium. >>>> > >>>> > In the uboot source directory : >>>> > >>>> > >>>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>>> > >>>> > >>>> > This will erase all data and create 4 partitions in the medium= , >>>> along with copying >>>> > the u-boot binary to the first partition: >>>> > >>>> > >>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> > Partition 2 =3D not used >>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>> exynos5250-snow.dtb) >>>> > Partition 4 =3D EXT4 partition for userspace files >>>> > >>>> > >>>> > With u-boot being copied, next is the kernel image and DTB >>>> file. From the kernel >>>> > source execute : >>>> > >>>> > >>>> > $ mkdir ../mnt/ >>>> > $ sudo mount /dev/sdX3 ../mnt/ >>>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>> > $ sudo umount /dev/sdX3 >>>> > >>>> > >>>> > Finally, we have to copy the Ubuntu userspace filesystem that >>>> we created earlier: >>>> > >>>> > >>>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo >>>> umount /dev/sdX4 >>>> > >>>> > >>>> > >>>> > Now,my idea is to chainload the already chain loaded u-boot created >>>> by V.O.S to the new u-boot >>>> > that we need for booting FreeBSD and that can be installed in the >>>> partition n.2,as shown in this >>>> > scheme,because it is not used : >>>> > >>>> > >>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>>> bit,compatible with FreeBSD on >>>> > this partition) >>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>> exynos5250-snow.dtb) >>>> > Partition 4 =3D EXT4 partition for userspace files >>>> > >>>> > >>>> > Take in consideration that default boot string is hardcoded here,in >>>> the snow.h file of the custom >>>> > u-boot created by VOS : >>>> > >>>> > >>>> > >>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/config= s/snow.h#L101 >>>> > >>>> > >>>> > and it needs to be recompiled because it should point to the >>>> partition n.2,where I will install >>>> > the u-boot files as explained here : >>>> > >>>> > >>>> > https://wiki.freebsd.org/arm/Chromebook >>>> > >>>> > >>>> > I have some questions to ask before I start working on this. >>>> > >>>> > 1) The xen developer said : >>>> > >>>> > >>>> > You should be able to build U-Boot and use the U-Boot binary a= s >>>> Xen guest kernel... >>>> > >>>> > >>>> > >>>> > where is the u-boot binary,according to this document ? >>>> > >>>> > https://wiki.freebsd.org/arm/Chromebook >>>> > >>>> > I don't see it. >>>> > >>>> > >>>> > 2) where is the source code of the file that I can get here : >>>> > >>>> > >>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles= /nv_uboot-snow-simplefb.kpart.bz2 >>>> > >>>> > I need the source code if I want to recompile u-boot so that it can >>>> point to the partition 4. >>>> > >>>> > Maybe it can be found on this link : >>>> > >>>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>> > >>>> > but it can't be opened.... >>>> > >>>> > >>>> > 3) in this specific scenario the source code of u-boot should run on >>>> arm 32 bit,not on arm >>>> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that'= s >>>> powered by a Samsung Exynos >>>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>>> > >>>> > >>>> > 4) I'm not sure if I can chainload the customized u-boot created by >>>> V.O.S that should be >>>> > installed on the first partition with the u-boot tailored for bootin= g >>>> FreeBSD that should be >>>> > installed on the partition 2.... >>>> > >>>> > >>>> > 5) the xen developer said that u-boot should be compiled enabling >>>> this option : >>>> > >>>> > >>>> > Code: >>>> > >>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>> > >>>> > >>>> > Well,can you provide some good source that can help me to understand >>>> how I can recompile u-boot >>>> > for FreeBSD ? thanks. >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>> >>> >>> >>> -- >>> Mario. >>> >> >> --0000000000002bd665060cf90b00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Warner,you didnt read one of my last email,where i said t= hat i have fixed that bug and I can boot my freebsd image with qemu and eve= n the network interface works well. I remember to you that my project is to= boot freebsd under xen. Thanks.

Il mer 20 dic 2023, 23:49 Warner Losh <<= a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com> ha scritto:


On W= ed, Dec 20, 2023 at 12:25=E2=80=AFAM titus <titus@edc.ro> wrote:
for the panic @ d= hcp see=C2=A0

its a problem with virtio= net driver (was fixed by forum user _martin but never went in the main tre= e)
if you emulate another nic type will work

Indeed it does.


should fix t= he problem. I think it's the right thing to do. It's what a lot of = other drivers do.

Warner
=C2=A0
On Dec 20, 2023, at 6:52 AM, Warner Losh <imp@bsdimp.com> wrote:

I'd = think you'd need the right virtualization loader. I'm not entirely = sure the u-boot.bin you've been creating is for a dom-u..=C2=A0
If I misunderstood, then the below isn't good advice. Chain booting = the u-boot, the first u-boot initializes things so you want
to st= art with stage after the SPL But the different error messages suggest that = it's trying to reboot with kexec, which
isn't supported o= n armv7 at the moment.

If you could boot in kv= m, I think that the following would work....=C2=A0 Though I'm not entir= ely sure how to
specify the two .fd files in your setup. The use = of qemu is to have an easy env to debug things... I don't
hav= e a chromebook to try...

My first instinct wou= ld be to try qemu on x86 (this is the first step of many to get to your des= tination).

If you could boot the GENERIC_SD image = that we produce using qemu + edk2-arm-code.fd that would
be a hug= e first step. This will give you the boot loader, I believe, to boot in the= VM that you need better
than going via the u-boot route. Since y= ou are booting in a virtualized environment, I think it wouldn't
<= div>matter which one :).

So, I did the following t= o boot the virtualized armv7 FreeBSD environment, following a post on the f= orums I found and knew to have the right recipe:

1. pkg install qemu
2. mkdir qemu-armv7-env
3. cd qe= mu-armv7-env
5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.i= mg.xz
6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D647. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64
8. dd if=3D/us= r/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv=3Dnotrunc
9. d= d if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv=3Dnotru= nc
10. cat > start-freebsd-arm.sh
#!/bin/sh
qemu-= system-arm \
=C2=A0 -M virt \
=C2=A0 -m 1024 \
=C2=A0 -drive file= =3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \
=C2=A0 -drive fi= le=3Dpflash1.img,format=3Draw,if=3Dpflash \
=C2=A0 -drive file=3D$1.img,= if=3Dvirtio,cache=3Dwritethrough \
=C2=A0 -nographic \
=C2=A0 -serial= mon:stdio
^D
11. chmod +x start-freebsd-arm.sh
12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD

But I hit a snag with this on qemu 8.1.2 and 8.1.3 wi= th both 13.2 and 14.0:

Starting devd.
Starting = dhclient.
DHCPDISCOVER on vtnet0 to 255.255.255255 port 67 interval 7Fatal kernel mode data abort: 'Alignment Fault' on read
trapfra= me: 0xc4b36a60
FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013
r0 =3D= 00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c
r4 =3D00000014,= r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c
r8 =3D00000000, r9 =3D00= 00022c, r10=3Ddd96701a, r11=3Dc4b36b90
r12=3D4300ffff, ssp=3Dc4b36af0, s= lr=3Dc04a9728, pc =3Dc04a9750

panic: Fatal abort
cpuid =3D 0
t= ime =3D 1680843057
KDB: stack backtrace:
#0 0xc035786c at kdb_backtra= ce+0x48
#1 0xc02fdd20 at vpanic+0x140
#2 0xc02fdbe0 at vpanic+0
#3= 0xc06304ac at abort_align+0
#4 0xc063052c at abort_align+0x80
#5 0xc= 063017c at abort_handler+0x480
#6 0xc060f480 at exception_exit+0
#7 0= xc04a9750 at udp_input+0x288
#8 0xc0473f54 at ip_input+0x1e0
#9 0xc04= 447c0 at netisr_dispatch_src+0xf8
#10 0xc043bf2c at ether_demux+0x1a4#11 0xc043d5e4 at ether_nh_input+0x480
#12 0xc04447c0 at netisr_dispatc= h_src+0xf8
#13 0xc043c404 at ether_input+0x50
#14 0xc01c0838 at vtnet= _rx_vq_process+0x880
#15 0xc01b70d0 at vtpci_intx_intr+0xac
#16 0xc02= b87f0 at ithread_loop+0x2ec
#17 0xc02b465c at fork_exit+0xc0
Uptime: = 19s

I don't know if this is a problem with qem= u or FreeBSD's kernel...

Warner

On Tu= e, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto <marietto2008@gmai= l.com> wrote:
I've asked some help on the channel #arm on = Reddit and someone replied :

=

Maybe his answer can be useful to understand why it doe= s not work.

On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabe= llini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <mariett= o2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git=
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <mariet= to2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <mariet= to2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> = https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp= =3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/mai= n/sysutils/u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.= arm.com/documentation/den0013/d/Security/TrustZone-hardware-architecture?la= ng=3Den
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer noreferrer" target=3D"_blank">https://developer.arm.com/do= cumentation/ddi0406/c/System-Level-Architecture/The-System-Level-Programmer= s--Model/The-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: ht= tps://source.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/mas= ter/arch/arm/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale= _defconfig?ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/mai= n/sysutils/u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb= =3D0782e25d98cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> h= ttp://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos= =3Dtech
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/= guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://github.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> h= ttps://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow= .h#L101
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook >
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook >
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmi= rror/distfiles/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chrome= book/nv_uboot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.

--0000000000002bd665060cf90b00-- From nobody Wed Dec 20 23:13:17 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwTrZ6kYMz55RsG for ; Wed, 20 Dec 2023 23:13:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwTrZ1mgnz3c1c for ; Wed, 20 Dec 2023 23:13:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-55322dbabf6so221021a12.0 for ; Wed, 20 Dec 2023 15:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703114011; x=1703718811; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jq3+TfyKCYWg8XgUn7f9m5cgtFMrivK9N2g3DX/cjio=; b=BBI9f7A0Arc/3pAVHnu4sKqTV0RFdcjTlRflS11FfnZYqRP0/PySutKDOvHRCPRR4X PTtEmmbFrva2ReJ1zBxJv+143+K+8yMwJy5IkW+hB22PDUaVMccLCLR+RBHm3ugbd4Mv RVQF+OsjFHssuF5tOka1xI/V986hAnVttT7KpvbA2+tMQMSBQboQZuxlI0iPsbJ3jenO 3DCHVt5mH1HBw5F3QnmZmpEqWqYzAc0gLTXFPLpSx2+vK1ipCRY9v8YL73+s2SwyN7aS Qz+qXpkFrGSnTNA51OxGPnnFRHutLr6G9LcwXRXybWBKXcl2C6U6J1K36W2ucC7b0jdv 5Bcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703114011; x=1703718811; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jq3+TfyKCYWg8XgUn7f9m5cgtFMrivK9N2g3DX/cjio=; b=n+x/sij3kwWugoJrYWQmDAzqvFp9T8yLG+N0/Hqbzf5rerueBU7glc90CEXvtK4cXF ZQnltfAS3rD0Y+mpIKV16EajxNHWrcFiIsAhBFJJNYbK8vOgKz0UK0XAhN7dEJI/QXyW Na89DOIVGLdbtRv/V7f0KaDR/1iCvpxYnt8lSHlGuM0CnBDCsb7sym1vYo2cZEHp6p5C kZn0m+l0dJ4jjSwsb+A9X5cYse07CqoEsMMJEMaMmTh75INPoRhR9rSVnVkWOgsq6vHq gNDNXeMqPZoCgQXLae74b4JvgLoi9vM822jjqwLzjKodfaHqOws9jaXLFI8MMcfkVv0x 9AoA== X-Gm-Message-State: AOJu0Yx2sZubG0futF8MmZvAkyiMP040yfRw+zgrwwWUTGXArycU47Dq /dDXAAJ3UlvS3H8hKBvxvwjb1R8779vde+j7puPLYM+dmXeim8sHPs4= X-Google-Smtp-Source: AGHT+IFGk7pFZqbjFjz4X3DYr12HamKg/7xvGqgP/Rszm1MvvP/5i1Kv4qhYm6MWUtzYDyYMq5VuBkvtN6dkFAxMyrQ= X-Received: by 2002:a17:907:961f:b0:a26:9d95:a34b with SMTP id gb31-20020a170907961f00b00a269d95a34bmr457642ejc.139.1703114010414; Wed, 20 Dec 2023 15:13:30 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> In-Reply-To: From: Warner Losh Date: Wed, 20 Dec 2023 16:13:17 -0700 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Mario Marietto Cc: titus , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000009a6559060cf9214e" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwTrZ1mgnz3c1c --0000000000009a6559060cf9214e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2023, 4:07=E2=80=AFPM Mario Marietto wrote: > Warner,you didnt read one of my last email,where i said that i have fixed > that bug and I can boot my freebsd image with qemu and even the network > interface works well. I remember to you that my project is to boot freebs= d > under xen. Thanks. > I do... but I've not been able to locate your fix.... I do know it's not relevant to these rest of this thread. I'd hoped the .fd files from EDK II might be helpful instead of uboot... but now I'm less sure it would be useful... Warner Il mer 20 dic 2023, 23:49 Warner Losh ha scritto: > >> >> >> On Wed, Dec 20, 2023 at 12:25=E2=80=AFAM titus wrote: >> >>> for the panic @ dhcp see >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288 >>> https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.8901= 6/ >>> >>> its a problem with virtio net driver (was fixed by forum user _martin >>> but never went in the main tree) >>> if you emulate another nic type will work >>> >> >> Indeed it does. >> >> https://reviews.freebsd.org/D43136 >> >> should fix the problem. I think it's the right thing to do. It's what a >> lot of other drivers do. >> >> Warner >> >> >>> On Dec 20, 2023, at 6:52 AM, Warner Losh wrote: >>> >>> I'd think you'd need the right virtualization loader. I'm not entirely >>> sure the u-boot.bin you've been creating is for a dom-u.. >>> If I misunderstood, then the below isn't good advice. Chain booting the >>> u-boot, the first u-boot initializes things so you want >>> to start with stage after the SPL But the different error messages >>> suggest that it's trying to reboot with kexec, which >>> isn't supported on armv7 at the moment. >>> >>> If you could boot in kvm, I think that the following would work.... >>> Though I'm not entirely sure how to >>> specify the two .fd files in your setup. The use of qemu is to have an >>> easy env to debug things... I don't >>> have a chromebook to try... >>> >>> My first instinct would be to try qemu on x86 (this is the first step o= f >>> many to get to your destination). >>> >>> If you could boot the GENERIC_SD image that we produce using qemu + >>> edk2-arm-code.fd that would >>> be a huge first step. This will give you the boot loader, I believe, to >>> boot in the VM that you need better >>> than going via the u-boot route. Since you are booting in a virtualized >>> environment, I think it wouldn't >>> matter which one :). >>> >>> So, I did the following to boot the virtualized armv7 FreeBSD >>> environment, following a post on the forums I found and knew to have th= e >>> right recipe: >>> >>> https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-= qemu.80765/ >>> >>> 1. pkg install qemu >>> 2. mkdir qemu-armv7-env >>> 3. cd qemu-armv7-env >>> 4. fetch >>> https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD= -14.0-RELEASE-arm-armv7-GENERICSD.img.xz >>> 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz >>> 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 >>> 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 >>> 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img >>> conv=3Dnotrunc >>> 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img >>> conv=3Dnotrunc >>> 10. cat > start-freebsd-arm.sh >>> #!/bin/sh >>> qemu-system-arm \ >>> -M virt \ >>> -m 1024 \ >>> -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ >>> -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ >>> -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ >>> -nographic \ >>> -serial mon:stdio >>> ^D >>> 11. chmod +x start-freebsd-arm.sh >>> 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD >>> >>> But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and >>> 14.0: >>> >>> Starting devd. >>> Starting dhclient. >>> DHCPDISCOVER on vtnet0 to 255.255.255255 port 67 interval 7 >>> Fatal kernel mode data abort: 'Alignment Fault' on read >>> trapframe: 0xc4b36a60 >>> FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 >>> r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c >>> r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c >>> r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 >>> r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 >>> >>> panic: Fatal abort >>> cpuid =3D 0 >>> time =3D 1680843057 >>> KDB: stack backtrace: >>> #0 0xc035786c at kdb_backtrace+0x48 >>> #1 0xc02fdd20 at vpanic+0x140 >>> #2 0xc02fdbe0 at vpanic+0 >>> #3 0xc06304ac at abort_align+0 >>> #4 0xc063052c at abort_align+0x80 >>> #5 0xc063017c at abort_handler+0x480 >>> #6 0xc060f480 at exception_exit+0 >>> #7 0xc04a9750 at udp_input+0x288 >>> #8 0xc0473f54 at ip_input+0x1e0 >>> #9 0xc04447c0 at netisr_dispatch_src+0xf8 >>> #10 0xc043bf2c at ether_demux+0x1a4 >>> #11 0xc043d5e4 at ether_nh_input+0x480 >>> #12 0xc04447c0 at netisr_dispatch_src+0xf8 >>> #13 0xc043c404 at ether_input+0x50 >>> #14 0xc01c0838 at vtnet_rx_vq_process+0x880 >>> #15 0xc01b70d0 at vtpci_intx_intr+0xac >>> #16 0xc02b87f0 at ithread_loop+0x2ec >>> #17 0xc02b465c at fork_exit+0xc0 >>> Uptime: 19s >>> >>> I don't know if this is a problem with qemu or FreeBSD's kernel... >>> >>> Warner >>> >>> On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto >>> wrote: >>> >>>> I've asked some help on the channel #arm on Reddit and someone replied= : >>>> >>>> >>>> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_= arm32_bit_as_domu_with/ >>>> >>>> Maybe his answer can be useful to understand why it does not work. >>>> >>>> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini < >>>> sstabellini@kernel.org> wrote: >>>> >>>>> +Michal >>>>> >>>>> Hi Mario, >>>>> >>>>> I am not sure about booting FreeBSD, but I am certain that u-boot wor= ks >>>>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>>>> file: >>>>> >>>>> name=3D"test" >>>>> kernel=3D"u-boot.bin" >>>>> extra =3D "console=3Dhvc0" >>>>> memory=3D256 >>>>> vcpus=3D1 >>>>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>>> >>>>> I don't know for sure if you can boot FreeBSD but you should definite= ly >>>>> be able to see the u-boot command line prompt. The fact that you are >>>>> getting this message: >>>>> >>>>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader >>>>> found: Invalid kernel >>>>> >>>>> Means that something is not right in the u-boot configuration or u-bo= ot >>>>> build. Michal and Artem (CCed) might know more. From what I recall, >>>>> there was nothing special required to get u-boot.bin to boot as domU >>>>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>>>> >>>>> Cheers, >>>>> >>>>> Stefano >>>>> >>>>> >>>>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>>>> > ....I see that some other interesting files have been produced by >>>>> u-boot when I have compiled it : >>>>> > >>>>> > u-boot >>>>> > u-boot.lds >>>>> > u-boot.bin >>>>> > u-boot.map >>>>> > u-boot-nodtb.bin >>>>> > u-boot.dtb >>>>> > u-boot.srec >>>>> > u-boot-dtb.bin >>>>> > u-boot.sym >>>>> > >>>>> > So,maybe I should use a different u-boot* file for booting FreeBSD = ? >>>>> > >>>>> > >>>>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto < >>>>> marietto2008@gmail.com> wrote: >>>>> > Hello to everyone. >>>>> > >>>>> > I have compiled the needed u-boot.bin from scratch using this >>>>> procedure : >>>>> > >>>>> > # git clone https://github.com/u-boot/u-boot.git >>>>> > # cd u-boot >>>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconf= ig : >>>>> this line generates the file .config >>>>> > # nano .config and I've added these parameters : >>>>> > >>>>> > CONFIG_ARMV7_NONSEC=3Dn >>>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>>> > >>>>> > the uboot-bin file is generated with this command : >>>>> > >>>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>>>> > >>>>> > At this point,I took a look inside the .config file and I saw that >>>>> the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>>>> > some reason,it is not accepted and this could be a problem.... >>>>> > >>>>> > These are the xen config files that I've used : >>>>> > >>>>> > nano freebsd.cfg >>>>> > >>>>> > name=3D"test" >>>>> > kernel=3D"u-boot.bin" >>>>> > extra =3D "console=3Dhvc0" >>>>> > memory=3D256 >>>>> > vcpus=3D1 >>>>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>>> > >>>>> > nano start-freebsd >>>>> > >>>>> > xl create freebsd.cfg >>>>> > xl console freebsd >>>>> > >>>>> > This is what happens when I launch the vm : >>>>> > >>>>> > # ./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 >>>>> 1:cannot (re-)build domain: -3 >>>>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >>>>> 1:Non-existent domain >>>>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >>>>> 1:Unable to destroy guest >>>>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >>>>> 1:Destruction of domain failed >>>>> > freebsd is an invalid domain identifier (rc=3D-6) >>>>> > >>>>> > >>>>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto < >>>>> marietto2008@gmail.com> wrote: >>>>> > So,ok,I should have said "the second u-boot" ; since the firs= t >>>>> u-boot binary is the "u-boot binary located in the RO >>>>> > memory" of the Chromebook". Sorry for the confusion. >>>>> > >>>>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto < >>>>> marietto2008@gmail.com> wrote: >>>>> > ---> There are no specific options in u-boot devoted to FreeB= SD >>>>> > >>>>> > This is an important factor. So,what about if,instead of compiling = a >>>>> new version of u-boot on the partition 2,I will >>>>> > recompile the u-boot customized version created by the virtual open >>>>> system in 2014,that should be installed on the first >>>>> > partition ? It could work if there are no differences between the >>>>> u-boot that should boot Linux and the u-boot that >>>>> > should boot FreeBSD. >>>>> > >>>>> > Can you give a look at the u-boot source code created by virtual >>>>> open systems ? You can find it on my google drive : >>>>> > >>>>> > >>>>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/vie= w?usp=3Dsharing >>>>> > >>>>> > I need to understand if I can recompile it without problem so that >>>>> it can satisfy my needs (the ability of the file >>>>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefan= o >>>>> Stabellini,the xen developer that suggested to me >>>>> > what I could do to have FreeBSD virtualized under Xen on my Arm >>>>> Chromebook) ; otherwise the risk is to find later >>>>> > problems that will make me troubles and that I will not able to fix= . >>>>> > >>>>> > I gave a look at the virtual open system u-boot and I didn't see an= y >>>>> arndale_defconfig inside. So,If I have understood >>>>> > correctly,I should put that file inside the root of the u-boot >>>>> source code,let's say here : >>>>> > >>>>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # l= s >>>>> > >>>>> > .checkpatch.conf README doc >>>>> net >>>>> > .git api drivers >>>>> onenand_ipl >>>>> > .gitignore arch dts >>>>> post >>>>> > COPYING board examples >>>>> rules.mk >>>>> > CREDITS boards.cfg fs >>>>> scripts >>>>> > MAINTAINERS common include >>>>> snapshot.commit >>>>> > MAKEALL config.mk lib >>>>> spl >>>>> > Makefile cros mkconfig >>>>> test >>>>> > PRESUBMIT.cfg disk nand_spl >>>>> tools >>>>> > >>>>> > and I should do : make and make install ? and the file I >>>>> need,u-boot.bin will be generated ? >>>>> > >>>>> > I didn't find any pre made configuration file inside : >>>>> > >>>>> > u-boot-vos # find . -type f -name "exynos*" >>>>> > >>>>> > ./include/exynos-fb.h >>>>> > ./include/configs/exynos5-common.h >>>>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>>>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>>>> > ./drivers/power/exynos-tmu.c >>>>> > ./drivers/power/exynos-cpufreq.c >>>>> > ./drivers/video/exynos-fb.c >>>>> > ./drivers/spi/exynos_spi.c >>>>> > ./board/samsung/dts/exynos5250-spring.dts >>>>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>>>> > ./board/samsung/dts/exynos5250-snow.dts >>>>> > ./board/samsung/dts/exynos5250-daisy.dts >>>>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>>>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>>>> > ./arch/arm/dts/exynos5250.dtsi >>>>> > ./arch/arm/dts/exynos-periph-id.dtsi >>>>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>>>> > >>>>> > u-boot-vos # find . -type f -name "arndale*" >>>>> > >>>>> > For sure I can't use a newer version of u-boot because otherwise th= e >>>>> patches needed to bypass the bootloader protections >>>>> > of the Arm Chromebook (such as a lot of different patches needed to >>>>> boot correctly Linux) will be broken ; anyway,since >>>>> > it works,I don't need to use an updated version of u-boot. >>>>> > >>>>> > ----> As per my experience, you have to respect these two options, >>>>> compiling u-boot for >>>>> > FreeBSD: >>>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-ma= ster/files/FreeBSD_Fragment >>>>> > >>>>> > It says that I should use these parameters : >>>>> > >>>>> > CONFIG_ARMV7_NONSEC=3Dn >>>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>>> > >>>>> > These are the parameters used to configure a Linux kernel. I don't >>>>> understand what's the relation between the compilation >>>>> > of a linux kernel and u-boot. In the past I tried to recompile >>>>> u-boot,but I didn't have the need to set up those >>>>> > parameters,so I don't know how to do it (but I know how to recompil= e >>>>> a Linux kernel). >>>>> > >>>>> > ---> I'm not sure that I'm getting you right, as I don't understand >>>>> what you mean under "the first u-boot". >>>>> > >>>>> > >>>>> > I'm talking about first u-boot because the whole procedure to boot >>>>> Linux on the ARM Chromebook,that's explained here : >>>>> > >>>>> > >>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebo= ok/ >>>>> > >>>>> > >>>>> > at some point they say : >>>>> > >>>>> > >>>>> > To be able to run KVM on ARM platforms, the kernel has to be booted >>>>> in hypervisor mode. Because of this relatively recent >>>>> > requirement (due to the introduction of the virtualization >>>>> extensions), up until now all booting methods would boot the >>>>> > kernel in the standard Supervisor mode. >>>>> > >>>>> > For the ARM Chromebook the default boot procedure doesn't allow us >>>>> to boot in hypervisor mode. Although the laptop's boot >>>>> > mechanism is based on the frequently used u-boot, the binary is >>>>> located in RO memory. Fortunately, a chained u-boot >>>>> > mechanism can be used (i.e. starting another u-boot after the >>>>> original). We can then enter hypervisor mode from our >>>>> > custom iteration of u-boot and subsequently load our kernel and >>>>> userspace. >>>>> > >>>>> > So,the first u-boot is the u-boot provided by virtual open >>>>> systems,that's able to chainload the "u-boot binary located in >>>>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We >>>>> don't need it if we want to boot Linux with kvm or xen >>>>> > enabled. >>>>> > >>>>> > >>>>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>>>> stanislav.silnicki@mailgate.us> wrote: >>>>> > I'm not an expert in the topic, I only know, that ARM has >>>>> divided hardware into two worlds - Secure and >>>>> > Not-So, strictly limiting any software, running in non-secure >>>>> world with access to functions and >>>>> > resources. >>>>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-= hardware-architecture?lang=3Den >>>>> >>>>> > >>>>> > I'm not sure, that I'm getting you right, as I don't understand wha= t >>>>> you mean under "the first u-boot". >>>>> > >>>>> > As I understand, virtualization (HYP) is running in non-secure worl= d( >>>>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Archit= ecture/The-System-Level-Programmers--Model/The-Virtualization-Extens >>>>> > ions), so my guess (only guess!!!), virtualization software has to >>>>> prepare (configure) HW platform in the way, >>>>> > that FreeBSD kernel will not lack any resources, required to >>>>> configure MPU, VA, etc. >>>>> > So, if you lucky to boot virtualizer, which is aware of target OS, >>>>> that maybe you can boot the kernel. Although, I >>>>> > doubt, that you need to boot 'second' u-boot to boot the kernel - >>>>> there is simply ubldr, which you can hook somehow >>>>> > from virtualizer.... >>>>> > >>>>> > Stan >>>>> > >>>>> > >>>>> > >>>>> > Mario Marietto wrote: >>>>> > >>>>> > >>>>> > ---> As I understand, it makes sure that u-boot keeps in >>>>> secure mode during boot and passes control to >>>>> > ubldr, which boots FreeBSD kernel, in that mode. >>>>> > >>>>> > Can you elaborate your sentence more ? I know that the bootloader >>>>> secure mode is bypassed by the virtual open >>>>> > systems u-boot. Are you saying that when the control passes to the >>>>> second u-boot,it will happen in secure >>>>> > mode,so that the bypass that happened loading the first u-boot,is >>>>> annulled ? If this is true,maybe can I boot >>>>> > FreeBSD using the virtual-open-system custom u-boot ? Is this >>>>> compatible with FreeBSD ? Where can I find the >>>>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>>>> > >>>>> > >>>>> > >>>>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>>>> stanislav.silnicki@mailgate.us> wrote: >>>>> > Hi Mario, >>>>> > >>>>> > U-Boot beast is hiding in this den: >>>>> https://source.denx.de/u-boot/u-boot.git >>>>> > I took a brief look at your post and it seems to me, that >>>>> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >>>>> > your target armv7 32 bit >>>>> > platform: >>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8= /Kconfig?ref_type=3Dheads#L3 >>>>> > >>>>> > As for compiling the u-boot, it is a doable task, given that you >>>>> understand what you are doing. There >>>>> > are no specific options in u-boot devoted to FreeBSD. It is a boot >>>>> loader, whose mission to make basic >>>>> > hardware initialization, read you kernel file from some media into >>>>> RAM and then pass it control. >>>>> > >>>>> > Basically, you can grab some defconfig, prepared for any other >>>>> Exynos5250 based board (say, this one: >>>>> > >>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_de= fconfig?ref_type=3Dheads) >>>>> and adopt >>>>> > it somehow. >>>>> > >>>>> > As per my experience, you have to respect these two options, >>>>> compiling u-boot for >>>>> > FreeBSD: >>>>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-ma= ster/files/FreeBSD_Fragment >>>>> > >>>>> > As I understand, it makes sure, that u-boot keeps in secure mode >>>>> during boot and passes control to >>>>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a >>>>> lot of surprises you may realize. >>>>> > >>>>> > Hope, this will help to progress you tasks >>>>> > Stan >>>>> > >>>>> > Mario Marietto wrote: >>>>> > >>>>> > >>>>> > Hello. >>>>> > >>>>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>>>> Chromebook. Basically there are >>>>> > two ways to accomplish this task : >>>>> > >>>>> > 1) to write a patch that allows the FreeBSD kernel to boot as >>>>> a zImage file. This could be >>>>> > accomplished applying this patch to a specific file that's on >>>>> the source code of FreeBSD : >>>>> > >>>>> > >>>>> > >>>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717= 035f986c979edef0c9 >>>>> > >>>>> > >>>>> > This patch was written by Julien Grall a lot of time ago and >>>>> now it does not work anymore. >>>>> > This is the reason : >>>>> > >>>>> > >>>>> > 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. And I'm not able to fix it. >>>>> > >>>>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen >>>>> developer : >>>>> > >>>>> > >>>>> > I was trying to explain why and how Julien's patch works so >>>>> that you could be the one >>>>> > to re-do something similar or fix the patch on the FreeBSD >>>>> kernel that you are >>>>> > working with. I am happy to help review and write patches but >>>>> I don't work with the >>>>> > FreeBSD kernel so I wouldn't be able to help you quickly. >>>>> However, I might have a >>>>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >>>>> Because U-Boot >>>>> > definitely boots as Xen on ARM guest firmware/bootloader. You >>>>> should be able to build >>>>> > U-Boot and use the U-Boot binary as Xen guest kernel, then >>>>> U-Boot could load FreeBSD >>>>> > from disk or network and start it. For instance as domU confi= g >>>>> file: >>>>> > >>>>> > kernel=3D"/home/petalinux/u-boot.bin" >>>>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>>> > >>>>> > I know it is important to build u-boot with the following >>>>> config to make it work on >>>>> > Xen. >>>>> > >>>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> > >>>>> > >>>>> > >>>>> > This option seems more doable to me according to my knowledge. But = I >>>>> need to understand how to do >>>>> > it. >>>>> > >>>>> > Well,let's say that on the ARM Chromebook I'm forced to use and >>>>> install a customized version of >>>>> > u-boot,created by virtual open systems,because it is the only one >>>>> that allows bypassing its >>>>> > bootloader protection. You can find more information here : >>>>> > >>>>> > >>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebo= ok/?vos=3Dtech >>>>> > >>>>> > This is the relevant section to read : >>>>> > >>>>> > >>>>> > Bootloader : >>>>> > >>>>> > If you wish to skip this chapter you can download a >>>>> pre-compiled binary of the >>>>> > bootloader: >>>>> > >>>>> > >>>>> > $ wget >>>>> > >>>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/= nv_u-boot-snow.kpart >>>>> > >>>>> > >>>>> > To be able to run KVM on ARM platforms, the kernel has to be >>>>> booted in hypervisor >>>>> > mode. Because of this relatively recent requirement (due to >>>>> the introduction of the >>>>> > virtualization extensions), up until now all booting methods >>>>> would boot the kernel in >>>>> > the standard Supervisor mode. For the ARM Chromebook the >>>>> default boot procedure >>>>> > doesn't allow us to boot in hypervisor mode. Although the >>>>> laptop's boot mechanism is >>>>> > based on the frequently used u-boot, the binary is located in >>>>> RO memory. Fortunately, >>>>> > a chained u-boot mechanism can be used (i.e. starting another >>>>> u-boot after the >>>>> > original). We can then enter hypervisor mode from our custom >>>>> iteration of u-boot and >>>>> > subsequently load our kernel and userspace. >>>>> > >>>>> > Checkout the needed u-boot code : >>>>> > >>>>> > >>>>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ >>>>> cd u-boot$ >>>>> > ./scripts/build.sh >>>>> > >>>>> > >>>>> > If successful, a message about how to copy the bootloader on >>>>> the USB flash disk or SD >>>>> > card will appear. We will use it later when preparing the boo= t >>>>> medium to start our >>>>> > system. If you have followed the Setting up the boot medium >>>>> chapter and you have a >>>>> > prepared boot device, then you can update u-boot by running : >>>>> > >>>>> > >>>>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>>> > >>>>> > >>>>> > >>>>> > so,the needed u-boot that we must use should be installed on the >>>>> first partition of the sd card. >>>>> > >>>>> > There is another relevant section to read : >>>>> > >>>>> > >>>>> > Setting up the boot medium >>>>> > >>>>> > Now it is time to copy all the relevant files that we created >>>>> in the previous >>>>> > chapters,and use them to boot Chromebook with a different >>>>> kernel and OS. In all these >>>>> > examples the device /dev/sdX is used. Take extra care to >>>>> change the examples to the >>>>> > device that you have attached. Insert the boot medium on your >>>>> workstation and >>>>> > carefully execute the following step. First we need to >>>>> properly format the boot >>>>> > medium. >>>>> > >>>>> > In the uboot source directory : >>>>> > >>>>> > >>>>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>>>> > >>>>> > >>>>> > This will erase all data and create 4 partitions in the >>>>> medium, along with copying >>>>> > the u-boot binary to the first partition: >>>>> > >>>>> > >>>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>> > Partition 2 =3D not used >>>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>> exynos5250-snow.dtb) >>>>> > Partition 4 =3D EXT4 partition for userspace files >>>>> > >>>>> > >>>>> > With u-boot being copied, next is the kernel image and DTB >>>>> file. From the kernel >>>>> > source execute : >>>>> > >>>>> > >>>>> > $ mkdir ../mnt/ >>>>> > $ sudo mount /dev/sdX3 ../mnt/ >>>>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>>>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>>> > $ sudo umount /dev/sdX3 >>>>> > >>>>> > >>>>> > Finally, we have to copy the Ubuntu userspace filesystem that >>>>> we created earlier: >>>>> > >>>>> > >>>>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sud= o >>>>> umount /dev/sdX4 >>>>> > >>>>> > >>>>> > >>>>> > Now,my idea is to chainload the already chain loaded u-boot created >>>>> by V.O.S to the new u-boot >>>>> > that we need for booting FreeBSD and that can be installed in the >>>>> partition n.2,as shown in this >>>>> > scheme,because it is not used : >>>>> > >>>>> > >>>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 3= 2 >>>>> bit,compatible with FreeBSD on >>>>> > this partition) >>>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>>>> exynos5250-snow.dtb) >>>>> > Partition 4 =3D EXT4 partition for userspace files >>>>> > >>>>> > >>>>> > Take in consideration that default boot string is hardcoded here,in >>>>> the snow.h file of the custom >>>>> > u-boot created by VOS : >>>>> > >>>>> > >>>>> > >>>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/confi= gs/snow.h#L101 >>>>> > >>>>> > >>>>> > and it needs to be recompiled because it should point to the >>>>> partition n.2,where I will install >>>>> > the u-boot files as explained here : >>>>> > >>>>> > >>>>> > https://wiki.freebsd.org/arm/Chromebook >>>>> > >>>>> > >>>>> > I have some questions to ask before I start working on this. >>>>> > >>>>> > 1) The xen developer said : >>>>> > >>>>> > >>>>> > You should be able to build U-Boot and use the U-Boot binary >>>>> as Xen guest kernel... >>>>> > >>>>> > >>>>> > >>>>> > where is the u-boot binary,according to this document ? >>>>> > >>>>> > https://wiki.freebsd.org/arm/Chromebook >>>>> > >>>>> > I don't see it. >>>>> > >>>>> > >>>>> > 2) where is the source code of the file that I can get here : >>>>> > >>>>> > >>>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfile= s/nv_uboot-snow-simplefb.kpart.bz2 >>>>> > >>>>> > I need the source code if I want to recompile u-boot so that it can >>>>> point to the partition 4. >>>>> > >>>>> > Maybe it can be found on this link : >>>>> > >>>>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>>> > >>>>> > but it can't be opened.... >>>>> > >>>>> > >>>>> > 3) in this specific scenario the source code of u-boot should run o= n >>>>> arm 32 bit,not on arm >>>>> > 64,because I have the Samsung Chromebook "SNOW" model >>>>> XE303C12,that's powered by a Samsung Exynos >>>>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>>>> > >>>>> > >>>>> > 4) I'm not sure if I can chainload the customized u-boot created by >>>>> V.O.S that should be >>>>> > installed on the first partition with the u-boot tailored for >>>>> booting FreeBSD that should be >>>>> > installed on the partition 2.... >>>>> > >>>>> > >>>>> > 5) the xen developer said that u-boot should be compiled enabling >>>>> this option : >>>>> > >>>>> > >>>>> > Code: >>>>> > >>>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>>> > >>>>> > >>>>> > Well,can you provide some good source that can help me to understan= d >>>>> how I can recompile u-boot >>>>> > for FreeBSD ? thanks. >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mario. >>>>> > >>>>> > >>>> >>>> >>>> >>>> -- >>>> Mario. >>>> >>> >>> --0000000000009a6559060cf9214e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 20, 2023, 4:07=E2=80=AFPM Mario Marietto &= lt;marietto2008@gmail.com> wrote:
Warner,you didnt read one of my last email,wher= e i said that i have fixed that bug and I can boot my freebsd image with qe= mu and even the network interface works well. I remember to you that my pro= ject is to boot freebsd under xen. Thanks.

I do... but I've not been a= ble to locate your fix....=C2=A0 I do know it's not relevant to these r= est of this thread.

I= 9;d hoped the .fd files from EDK II might be helpful instead of uboot... bu= t now I'm less sure it would be useful...

Warner

Il mer 20 dic 2023, = 23:49 Warner Losh <imp@bsdimp.com> ha scritto:

On Wed, = Dec 20, 2023 at 12:25=E2=80=AFAM titus <titus@edc.ro= > wrote:
for the panic @ dhcp see=C2=A0

its a problem with virtio net driver (= was fixed by forum user _martin but never went in the main tree)
= if you emulate another nic type will work

=
Indeed it does.


sho= uld fix the problem. I think it's the right thing to do. It's what = a lot of other drivers do.

Warner
=C2=A0=
On Dec 20, 2023, at 6:52 AM, Warner Losh <imp@bsdimp.com> wrote:

I'd think you'd need the right virtualizatio= n loader. I'm not entirely sure the u-boot.bin you've been creating= is for a dom-u..=C2=A0
If I misunderstood, then the below isn= 9;t good advice. Chain booting the u-boot, the first u-boot initializes thi= ngs so you want
to start with stage after the SPL But the differe= nt error messages suggest that it's trying to reboot with kexec, which<= /div>
isn't supported on armv7 at the moment.

If you could boot in kvm, I think that the following would work....= =C2=A0 Though I'm not entirely sure how to
specify the two .f= d files in your setup. The use of qemu is to have an easy env to debug thin= gs... I don't
have a chromebook to try...

<= /div>
My first instinct would be to try qemu on x86 (this is the first = step of many to get to your destination).

If you c= ould boot the GENERIC_SD image that we produce using qemu + edk2-arm-code.f= d that would
be a huge first step. This will give you the boot lo= ader, I believe, to boot in the VM that you need better
than goin= g via the u-boot route. Since you are booting in a virtualized environment,= I think it wouldn't
matter which one :).

So, I did the following to boot the virtualized armv7 FreeBSD environ= ment, following a post on the forums I found and knew to have the right rec= ipe:

1. pkg install qemu=
2. mkdir qemu-armv7-env
3. cd qemu-armv7-env
4. fetch https://download.freebsd.org/rel= eases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.im= g.xz
5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.i= mg.xz
6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D647. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64
8. dd if=3D/us= r/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv=3Dnotrunc
9. d= d if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv=3Dnotru= nc
10. cat > start-freebsd-arm.sh
#!/bin/sh
qemu-= system-arm \
=C2=A0 -M virt \
=C2=A0 -m 1024 \
=C2=A0 -drive file= =3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \
=C2=A0 -drive fi= le=3Dpflash1.img,format=3Draw,if=3Dpflash \
=C2=A0 -drive file=3D$1.img,= if=3Dvirtio,cache=3Dwritethrough \
=C2=A0 -nographic \
=C2=A0 -serial= mon:stdio
^D
11. chmod +x start-freebsd-arm.sh
12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD

But I hit a snag with this on qemu 8.1.2 and 8.1.3 wi= th both 13.2 and 14.0:

Starting devd.
Starting = dhclient.
DHCPDISCOVER on vtnet0 to 255.255.255255 port 67 interval 7Fatal kernel mode data abort: 'Alignment Fault' on read
trapfra= me: 0xc4b36a60
FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013
r0 =3D= 00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c
r4 =3D00000014,= r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c
r8 =3D00000000, r9 =3D00= 00022c, r10=3Ddd96701a, r11=3Dc4b36b90
r12=3D4300ffff, ssp=3Dc4b36af0, s= lr=3Dc04a9728, pc =3Dc04a9750

panic: Fatal abort
cpuid =3D 0
t= ime =3D 1680843057
KDB: stack backtrace:
#0 0xc035786c at kdb_backtra= ce+0x48
#1 0xc02fdd20 at vpanic+0x140
#2 0xc02fdbe0 at vpanic+0
#3= 0xc06304ac at abort_align+0
#4 0xc063052c at abort_align+0x80
#5 0xc= 063017c at abort_handler+0x480
#6 0xc060f480 at exception_exit+0
#7 0= xc04a9750 at udp_input+0x288
#8 0xc0473f54 at ip_input+0x1e0
#9 0xc04= 447c0 at netisr_dispatch_src+0xf8
#10 0xc043bf2c at ether_demux+0x1a4#11 0xc043d5e4 at ether_nh_input+0x480
#12 0xc04447c0 at netisr_dispatc= h_src+0xf8
#13 0xc043c404 at ether_input+0x50
#14 0xc01c0838 at vtnet= _rx_vq_process+0x880
#15 0xc01b70d0 at vtpci_intx_intr+0xac
#16 0xc02= b87f0 at ithread_loop+0x2ec
#17 0xc02b465c at fork_exit+0xc0
Uptime: = 19s

I don't know if this is a problem with qem= u or FreeBSD's kernel...

Warner

On Tu= e, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
I've asked some help o= n the channel #arm on Reddit and someone replied :

https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_f= reebsd_for_arm32_bit_as_domu_with/

Maybe his a= nswer can be useful to understand why it does not work.
On Tue, D= ec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github= .com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq= 5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0lib =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/= freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD_Fragment >
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-ch= romebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote: >=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/documentation/den0013/d/Security/TrustZone-ha= rdware-architecture?lang=3Den
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https:= //developer.arm.com/documentation/ddi0406/c/System-Level-Architecture/The-S= ystem-Level-Programmers--Model/The-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.silnicki@mailgate.us> wrote: >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://source.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-= boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> https://source.denx.de/u-boot/u-boot/-/blob/= master/configs/arndale_defconfig?ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/= freebsd-ports/blob/main/sysutils/u-boot-master/files/FreeBSD_Fragment >
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/= gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.virtualopensystems.com/en/solutions/guides/= kvm-on-chromebook/?vos=3Dtech
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopen= systems.com/downloads/guides/kvm_on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://github.com/virtualopensystems/u-boot.git$= cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://github.com/virtualopensyste...18a39b6c177dff58= a/include/configs/snow.h#L101
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.or= g/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.or= g/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapi= s.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 >
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-= exynos.org/dist/chromebook/nv_uboot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.

--0000000000009a6559060cf9214e-- From nobody Thu Dec 21 01:53:37 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwYPc3SfQz546pr for ; Thu, 21 Dec 2023 01:53:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwYPb3Qpwz4L9P for ; Thu, 21 Dec 2023 01:53:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="O3vJC/Tr"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703123633; bh=a5S7Ff0Xk4xgRf/Z0tbOrBTpk8mup9Atrc7pcMrhUlk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=O3vJC/Tr+kmUvRZTWuGVmAz47SyKGEHlR5IacqNQ7NylJOkcDYEL9LXr3PTAsykXMZGJtW6z8f4sjmXQgn2/fCRJOCqjkcO02CtJUad4F2GgMDh7a4BM57J1wE+csQV7HF9f2WSEJAJ7GvTi5jp39mxtE4eO3vAq/DrvzS1Y4+Oaa4kxoJYabyf7Z0np4OHm432LraBFNLtJZ9xkQDY+m0yaDDcU0czfcDMgKxUnLud+sJ+1WFsNIhiQmcpCMg686S/k9F+fS7QswFk2NL8qKHbFfiH6+Z/qE+hsz4zYYoHnUGNaVWge1XupuimPSRSZjQ+1lWBtXLhBcI9L19at3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703123633; bh=5IXWLY3IPEgipB/iaJ6VVpeE8WMpDo1c6bNZi16paIM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ti8wPR0C7LyKUeN6wuyfmMC9fBFyEy83q2sadtVJKKN1/A4sPOsiXn8EI0o3DlIutwGsQ/p2x6x96lex7uljORxxTwEqusmYB2fc9LZqCCGKpIQ/zVlL/xOcEXqnaMACd13XSnrH12MjWXyvVJ4fTydGftcQmSj3K7itjVSGU6ejltu09S2shZRcuO+ADnBzp+ajKu3MoH5oX33MFQLgR3F5KjKA6IasJS9h4vPDqBdC5htaPc0RgAuZC1mqFTT8ZA3fSQkHN0Tsc5yMLyCBdNoSnVzJa7mw1zoiLGTWXtdSPBWfEel8PVzcvso6Jy1dgoPhKiJzPDSLyY1dAdRI2A== X-YMail-OSG: wNN14okVM1kder7m7uamBRpZdlXyludq.yEcwQVBNyYgGa8zXe.Cdq5fg4iOQKh wyfwHP_Gt0K0jONm1G83zeylUyMaY8EhAfIy_Y9L1gxU2w8Bw4rkucnUcEU1KEqgz_dKximUDMoh Jxg05984CUjxu94w5fzlgY9lbzW2PgfILxxAg9Ooaw0piYjbOGWXYIQTCG.aNAD9wVWdxIwa9Lht uWQrR0TDRBO2AdlNIQ41ZC2y.c2VdJ4UzBM2eHnIl9pb.GWCZe18bqqPpqNqXaaEi7DRtH2FKEOo LxX2Qn09Mnf_5HfDawkHyUWCnKOS_cpbP7shVTzySZDsehtgy6uDZvK4cOWi_EYFMsTka1Poa3Yf SQD1sI4z7MqERLhDilr4Z0zoldIPowEgC2_o7XDvdYZMvdon5SEtE.Iiym9dAxDmBbtyDjypDeDg MpjHyly0uQnzgpu7GQecrcZSec652nw8OeFAFg.XBaLE1lXfwH9rSe8Nl3uRDHPGY7aWTuxaL1T4 G8e6QYwl6gPy.K_NyTFrWlHwm2SR1IbofG55d.yTOVE0TZfxZZaOMmTb_gLN2Ycvh7FrdiTaeUcN bA5BL46wGXeANypV1Y6vcEl9AoTRv2RFCzGl2NrB_WsEaZA_I7Z72d2l3FQjeps8RLIf4uHV_6f3 wViAFAbYqIAPC1fsUQ2S.tJ7poJRJt2lOrViDb8.6JMiBNmnT6D1i9D9OCj9UtT1UuDtg59cgvg5 LVVl07rS4Ul1nlkcIWyyHaNMSW7BaNSCXCO.5HgYU63JQ0y5knTnN9xvT2x2PYkP_02cwXr4Bwqs ZgsREg_plePRHVy9rEk3CDSc_7J6tMyXVV0RAP5kTzaDp.i2KLHOyxij0t9JN1tkSNB0_MROyGvq V31m86pKwf1b1MCvELTJdW69BJ0DE1LQr6npp72rSd.7MreQ7f4HctUpYm5idxxMTYOqG.Ocd2Th kQo2zVFvX4SB0k89uI8qmCvyaeJPR34IRw_Hq8YsVhrsR_GZSTWhFvhmxSJpo6FEfGI6PFZ3kLTe Ys1NGZwbeVTuTtX9iRESEbFNckgX3jxBEgaOljHU0MYI5_9Pl_7bemi4cGxzmWh0lIsdWn.wAyWQ n5FruQ1TGEIPHEKmkeCzaoW7FuLm0t6AwjvPZfowYnSK4gLb4rGchszkiAp9MWlQeR3tPZ7XUxYD PaxCC8dZLaGSL2658Gig11Pw79qHXxsyozHBMYFCKmpbMN0aT9aOZuENjIyAQOQkXr5L8vpb9FAt B_dp01yiLeaU7_Uud_8QMQx1VAgJ6n0iISoJUHGJmmk.Lwrip6A8gNF0_MbxjtMF5dWyTIPI.EA. UFjM0_c2U6JBMuTWP1dZZ3p9BmXHzjazdRiJd3ZVi4RTBvSk_MHbqHmzDdE2tQq_dUGh9R8556Sq .CvQ8TEOs0.rznSg_H6RQwiIR.148o8sofedtU02EGvLvDGZ0w1kmvuuY50pJDopN5_ftsrHbSuT w_SgfmosS95jTAQflleGskQv.CS2rEI64mo0_E5sWfMhTdnJLCD_dyW2504Z.zrqwLz1IabwqXKM pEr.zdoWG9aikRr3ODQ7lII.89aU2svHqPrMFsKU0_srrZ6c54c65yxTXbRzUmKVPFzJDXeB29Nf cdikZHh7Wp_OrtQYdYsvYH_WgByBUDCrT3tlYNVj7pA9uEOGzChWr0c.CTbP5wM4p_54wMls1aYT .QFz9W8BgqPQxUqNF83PUSyAH0CU85zeU0av.ULpCdaE5C03_v1WIH0LWCfn.Qn5KxKj5XmXpGjE HXQgcoYdjxHdvQIRSjUlLcO_vWPwd4kquyrwt_Q9JVNOYpGP6MO.kyFmp7y01ZyisFUVVQ_1_aR5 hd9rQ7C0to78mN4O5fEl95Os4seT8SxZw.roak6CVD4XM0H2iZo.NYMnrgpDCLb2z3P90SJhlZW3 hCL3wfsa.XlfhPkZRiGUNPTnWr_gZY4wV_GB7cd9_H.Yh8W9BW45UUJtz_sNFNJH2uLt55N7USkb 3PKQg2MUvFUpDVJklemQUGGRJg.jagottj4MK0G9Z1pyXLn4r2T3Wu3toGUd4fG1K6DZM5Ejm0iu 9V2FGcH9Vm.v_exNpE65mZ0iD7.C1RxiyjURyioKGm8MHfkij263YphoE7o9ZdRJHPs7ZmZ1LuP5 6M9tp7FZIA81gNbrCvFpY53d0F4QafBkgt6lSi2nE8.UL4_WskQNVqS_uq9SDHLcYmvCLawxnBTU bpwyvlV5M9VW9L8xq7ckhDt75SuCnvBA2EFAVxlNgaqm2JsaCe4h6yOTCZw-- X-Sonic-MF: X-Sonic-ID: af738ee6-dfa3-4e01-9d00-c1a38104a310 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 21 Dec 2023 01:53:53 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fa55c5a16e6016421a240639cbe912f8; Thu, 21 Dec 2023 01:53:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: FYI: stable/14 arm64-aarch64-RPI snapshot with its U-Boot 2023.10: mmc-then-ethernet-then-usb attempt order Message-Id: <80BD6A0C-729F-46C1-B162-81AF5C0C4283@yahoo.com> Date: Wed, 20 Dec 2023 17:53:37 -0800 To: freebsd-arm X-Mailer: Apple Mail (2.3774.300.61.1.2) References: <80BD6A0C-729F-46C1-B162-81AF5C0C4283.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SwYPb3Qpwz4L9P X-Spamd-Bar: --- Example U-Boot output text based on: FreeBSD-14.0-STABLE-arm64-aarch64-RPI-20231216-2ef9079ece5a-266002.img dd'd to the USB3 SSD media: . . . U-Boot 2023.10 (Dec 16 2023 - 06:01:20 +0000) DRAM: 947 MiB (effective 7.9 GiB) RPI 4 Model B (0xd03115) Core: 210 devices, 16 uclasses, devicetree: board MMC: mmc@7e300000: 3, mmc@7e340000: 0 Loading Environment from FAT... ** Bad device specification mmc 1 ** In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_send_command: MMC: 3 busy timeout increasing to: 200 ms. sdhci_send_command: MMC: 3 busy timeout increasing to: 400 ms. sdhci_send_command: MMC: 3 busy timeout increasing to: 800 ms. sdhci_send_command: MMC: 3 busy timeout increasing to: 1600 ms. sdhci_send_command: MMC: 3 busy timeout increasing to: 3200 ms. sdhci_send_command: MMC: 3 busy timeout. sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_send_command: MMC: 3 busy timeout. sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_send_command: MMC: 3 busy timeout. sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_send_command: MMC: 3 busy timeout. Card did not respond to voltage select! : -110 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.160 (375 ms) *** ERROR: `serverip' not set Cannot autoload with TFTPGET missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-e4-5f-01-ac-e3-e6 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A801A0 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A801A *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A801 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A80 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A8 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0A *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C0 *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/C *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/default-arm-bcm283x *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/default-arm *** ERROR: `serverip' not set Retrieving file: pxelinux.cfg/default *** ERROR: `serverip' not set ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi . . . (So the RPi4B firmware found and used the USB3 SSD boot media to load the U-Boot.) The first boot had timeouts showing for each of each pxelinux.cfg/* and it took a lot longer to get to the "Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi". =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 21 11:59:14 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SwprG3LNsz54jkW for ; Thu, 21 Dec 2023 11:59:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwprG2pgyz3dVt for ; Thu, 21 Dec 2023 11:59:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703159966; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ZAaza805UxNC3OL5kO4ZQlqrFLp896c8Wr+mdgq0HQw=; b=Tl31TvAiYY4LOWD+IUiH9pTqK6mt514bRXEFUGuB0znbd2SYeG59HeFF0HVqxRDaaUJqZE jaUtI8IcH6BinDwjaZJozSVmOo8rpOtrEH9+iMfwFnVdKs517udswegvd7NRTW7iuQ8g0W fcKCYqqvPaS1PpsBUFwsw1QCY680wJXYwaIiSY4QAo/DCX/YIepqYO7Zyv1/UZTX5sHvZR Q4MCaED5OTEVGUSkDjQhjjxRDhNzXbwrHj0neflwvJoNMzsGYhdaUyoat+JqV5whDTT97+ m71YYLbB7i8waKzabO9DP3hTBte/MqSAXo9FgTsEDUVUPfdZyvKK7Ge5gl2QbQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703159966; a=rsa-sha256; cv=none; b=cwEKix2RYXIA9rz10D0+jYzl4Q+5MGvhDtCZ8BadW5ROko5EzLFdHtyDZY2eDc/wIpp7xL afqfHj0PB8of0Ey6z6pqeqH2makaau3AfpFqbE7o39bLbR9zhzzz1LrfVa8SLMwMSM1Sgo IkJxaeROlpJ8q1wJmbKXUWH4phuIib2wUxEfEL0/GcTvrz15Bn99UnfymGRrTdJpqgJaHH Xs9pVY21W7tTi7Snpcx47m46A5aZ5gjWXNq+a6KNAAa75PDlP+Sbbv8C4n6cjM4ivzk8M1 t39rpUZ6FBKMfybMN5vJNuhrd161q0TFACVVzWP4aA5e57A9zRc9YZys5ARqRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703159966; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ZAaza805UxNC3OL5kO4ZQlqrFLp896c8Wr+mdgq0HQw=; b=GzvOyPjLkV/OC0NZzy/Vpt0+niWsKkxAVOWElgfBRhl8XpknbnpoxSi6Uslpcd7boMWiqU BVYPVBvIAI9r3mF263MkxGQPq9N2J8cT/uJ71CjKr49tju0RXR8xsxMnk2PlhptMwOyrDU 1fvDgXZrySgjIccGFMJAnbXwCfzmlKtXHq7U2Vn2SlPsexAg/V91N5nKTYZFHiGq0LpeEh DcedRBiDjztVZCWJrlN2Oe42NuX9NLw9UyPHRXi0TMVodfLc1+zfV1a4BH2P6sDfv2Cu7H hN4yPogG1ZaqFEvYORV2FBNNo073+C793vdL+BXjn/7kzfnojnLWqY1pbBdKKg== Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SwprG1kvmz16K0 for ; Thu, 21 Dec 2023 11:59:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-dbd739853easo648830276.0 for ; Thu, 21 Dec 2023 03:59:26 -0800 (PST) X-Gm-Message-State: AOJu0Yx+8+UekQdrfckOymZSDRCFeX8Q/6d4nk4PdWdWjU2kFyuicEsT iop2arfMXUeVe1CYsf1jEDSsLv7FFnY0o4ood9U= X-Google-Smtp-Source: AGHT+IHrH4LTJcwEwh/LgDuXGZwQc2afc3VsWqgEWuIiEyf7HAUYmhkyezeo6rfeOJmXCiN8+CoTynOH+1qYbzuoRug= X-Received: by 2002:a25:dc50:0:b0:dbd:6741:1f97 with SMTP id y77-20020a25dc50000000b00dbd67411f97mr797725ybe.80.1703159965642; Thu, 21 Dec 2023 03:59:25 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Nuno Teixeira Date: Thu, 21 Dec 2023 11:59:14 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: rpi4 VideoCore VI graphics To: FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000bf7a5b060d03d45c" --000000000000bf7a5b060d03d45c Content-Type: text/plain; charset="UTF-8" Hello all! Is there any progression on rpi4 VideoCore VI graphics that I can follow? Any plans on FreeBSD support? Thanks, -- Nuno Teixeira FreeBSD Committer (ports) --000000000000bf7a5b060d03d45c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all!

Is there any prog= ression on rpi4 VideoCore VI graphics that I can follow?
Any plan= s on FreeBSD support?

Thanks,

--
Nuno Teixeira
FreeBSD Committer (po= rts)
--000000000000bf7a5b060d03d45c-- From nobody Fri Dec 22 12:20:14 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxRFs1FzVz558rN for ; Fri, 22 Dec 2023 12:20:17 +0000 (UTC) (envelope-from steve@copacetic.net) Received: from starlight.copacetic.net (starlight.copacetic.net [166.78.105.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxRFr4mszz4bV5 for ; Fri, 22 Dec 2023 12:20:16 +0000 (UTC) (envelope-from steve@copacetic.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of steve@copacetic.net designates 166.78.105.238 as permitted sender) smtp.mailfrom=steve@copacetic.net; dmarc=none Received: from [172.16.200.151] (c-73-149-127-197.hsd1.ma.comcast.net [73.149.127.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by starlight.copacetic.net (Postfix) with ESMTPSA id 7EDC84AC09 for ; Fri, 22 Dec 2023 12:20:15 +0000 (UTC) Message-ID: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> Date: Fri, 22 Dec 2023 07:20:14 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-arm@FreeBSD.org Content-Language: en-US From: Steve Bernacki Subject: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.71)[-0.714]; R_SPF_ALLOW(-0.20)[+ip4:166.78.105.238]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:19994, ipnet:166.78.64.0/18, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; ARC_NA(0.00)[]; DMARC_NA(0.00)[copacetic.net]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FREEFALL_USER(0.00)[steve]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SxRFr4mszz4bV5 X-Spamd-Bar: -- I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace my aging FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 on it, and both Ethernet devices (genet0 and ue0) were properly identified. However, network throughput on my gigabit network is pretty bad; iperf3 reports a maximum transfer speed of 291 Mbits/sec. Flashing OpenWRT on the same hardware using the same ethernet port, I'm able to achieve 923 Mbits/sec. Does anyone have any suggestions on how to improve throughput under FreeBSD? Thank you Steve From nobody Fri Dec 22 14:23:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxV050RT4z55HLs for ; Fri, 22 Dec 2023 14:23:33 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxV045kx7z3H5R for ; Fri, 22 Dec 2023 14:23:32 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BMENOoS065162; Fri, 22 Dec 2023 08:23:24 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703255005; bh=exqEm6Crde07DlNt0oI87DcbeVuSEZFZ+kVWNC2SG0Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=qvneSc3Ffa9GcGRZls/kO7SSyA+0XAk4t57vSjFivftMB3IIkiYTPaOqDPv6TL7p2 xStcCN8+0nnL+32x1KVAT6SqTSOw8mwlhJNjOdkx/Gb6gG2+XgsTK64E2cqLGkC2Os 0homkSZd8kzIz+oq0nf0gCWnU615fw4YIA+wGpZGRs0K4jeZJqzp1m0qKKpYTuoPDv Nhje892dRK1TCQcn4ZP3QRHFQEszBaMsfMhm2KMGrKo1Rz5feJqWU9wCwSDUJ6tSZq qhjw8hjHf38nZ8LVJs+hWiTzKE5d6Vdd1iiLRafvMwJAPBbsYsRgKJQ98LmVkBrHnR UyvSIRk/4BP8g== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id DJNBNNybhWWI/gAAs/W3XQ (envelope-from ); Fri, 22 Dec 2023 08:23:24 -0600 From: Mike Karels To: Steve Bernacki Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB Date: Fri, 22 Dec 2023 08:23:24 -0600 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxV045kx7z3H5R On 22 Dec 2023, at 6:20, Steve Bernacki wrote: > I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace my agi= ng FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 on it, = and both Ethernet devices (genet0 and ue0) were properly identified. Howe= ver, network throughput on my gigabit network is pretty bad; iperf3 repor= ts a maximum transfer speed of 291 Mbits/sec. Flashing OpenWRT on the sam= e hardware using the same ethernet port, I'm able to achieve 923 Mbits/se= c. > > Does anyone have any suggestions on how to improve throughput under Fre= eBSD? > > Thank you > Steve I just tested with an RPi4 (4 GB) and 14.0 using iperf3. It looks like I= 'm getting a rather variable number of retransmissions. On my first run (client on = RPi 4), I got 460 Mb/s with a lot of retransmissions, but the next couple of runs= , including one receiving, I got about 940 Mb even with some retransmissions. The pe= ers were fairly fast FreeBSD 13.2 and 15-current systems. Are you seeing retransm= issions? I'll try to look into this, but I'm not sure when I'll get to it. Mike From nobody Fri Dec 22 22:14:17 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxhRJ4g9Hz54Yfb for ; Fri, 22 Dec 2023 22:14:20 +0000 (UTC) (envelope-from steve@copacetic.net) Received: from starlight.copacetic.net (starlight.copacetic.net [166.78.105.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxhRJ2lXSz4XkL for ; Fri, 22 Dec 2023 22:14:20 +0000 (UTC) (envelope-from steve@copacetic.net) Authentication-Results: mx1.freebsd.org; none Received: from [172.16.200.151] (c-73-149-127-197.hsd1.ma.comcast.net [73.149.127.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by starlight.copacetic.net (Postfix) with ESMTPSA id 83A254AC32; Fri, 22 Dec 2023 22:14:18 +0000 (UTC) Message-ID: Date: Fri, 22 Dec 2023 17:14:17 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB Content-Language: en-US To: Mike Karels Cc: freebsd-arm@FreeBSD.org References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> From: Steve Bernacki In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19994, ipnet:166.78.64.0/18, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxhRJ2lXSz4XkL Hi Mike, Indeed, I'm getting a lot of retransmits: [  5] local 172.16.200.2 port 55551 connected to 172.16.200.182 port 5201 [ ID] Interval           Transfer     Bitrate         Retr  Cwnd [  5]   0.00-1.00   sec  36.2 MBytes   304 Mbits/sec   60   9.98 KBytes [  5]   1.00-2.00   sec  35.7 MBytes   300 Mbits/sec  143    111 KBytes [  5]   2.00-3.00   sec  34.9 MBytes   293 Mbits/sec  141   7.13 KBytes [  5]   3.00-4.00   sec  33.9 MBytes   284 Mbits/sec  198   99.5 KBytes [  5]   4.00-5.00   sec  34.9 MBytes   292 Mbits/sec  167   1.43 KBytes [  5]   5.00-6.00   sec  34.2 MBytes   287 Mbits/sec  221   2.85 KBytes [  5]   6.00-7.00   sec  34.1 MBytes   286 Mbits/sec  169    100 KBytes [  5]   7.00-8.00   sec  35.2 MBytes   295 Mbits/sec  159   7.13 KBytes [  5]   8.00-9.00   sec  34.3 MBytes   287 Mbits/sec  138   4.28 KBytes [  5]   9.00-10.00  sec  33.3 MBytes   279 Mbits/sec  182   2.85 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bitrate         Retr [  5]   0.00-10.00  sec   347 MBytes   291 Mbits/sec 1578             sender [  5]   0.00-10.00  sec   346 MBytes   291 Mbits/sec                  receiver Thanks, Steve On 12/22/2023 9:23 AM, Mike Karels wrote: > On 22 Dec 2023, at 6:20, Steve Bernacki wrote: > >> I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace my aging FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 on it, and both Ethernet devices (genet0 and ue0) were properly identified. However, network throughput on my gigabit network is pretty bad; iperf3 reports a maximum transfer speed of 291 Mbits/sec. Flashing OpenWRT on the same hardware using the same ethernet port, I'm able to achieve 923 Mbits/sec. >> >> Does anyone have any suggestions on how to improve throughput under FreeBSD? >> >> Thank you >> Steve > I just tested with an RPi4 (4 GB) and 14.0 using iperf3. It looks like I'm getting > a rather variable number of retransmissions. On my first run (client on RPi 4), > I got 460 Mb/s with a lot of retransmissions, but the next couple of runs, including > one receiving, I got about 940 Mb even with some retransmissions. The peers were > fairly fast FreeBSD 13.2 and 15-current systems. Are you seeing retransmissions? > > I'll try to look into this, but I'm not sure when I'll get to it. > > Mike > From nobody Fri Dec 22 22:48:57 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxjCJ6bbVz54bL0 for ; Fri, 22 Dec 2023 22:49:00 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxjCJ1XCNz4Zrr for ; Fri, 22 Dec 2023 22:49:00 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BMMmv53067840; Fri, 22 Dec 2023 16:48:58 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703285338; bh=hYigzKVjRbW28ga9/HaNGnVd5W2X7jAJpSOFL/YG34U=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=n/5SFumpoI/iurP5lUPanSYOfLCiqWylHuEYIJBM9HYX3K+nqYmrGPQhCbM7Lf0tE uycIMa59g6+LLoFvWcAenxMPJ6dKzUvsDnKo9fSBkSDmNc/esn7Y74GTZiVecRi86O hXfMT8Oz3cqE2LXbctn/d7xh5S5qOwNnAGwYJ97u5QiFWeS/uDohEh6Ah2INkKysHl FiawAW02sjhK7QwxPuKMikrhb5/0P8TswYAib6ngwYwH88HKMwB1JDhhxSf9SO2YHz 7jWwieinhZ2btr2QgFVzlOIDnb1/4ZNLl6OKa5pFyQS3cUSujJTNv3112QFT59rJmY VvYX9UN2tLSUQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id k3ctOlkShmX+CAEAs/W3XQ (envelope-from ); Fri, 22 Dec 2023 16:48:58 -0600 From: Mike Karels To: Steve Bernacki Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB Date: Fri, 22 Dec 2023 16:48:57 -0600 X-Mailer: MailMate (1.14r5964) Message-ID: <2E1B887B-EB3C-4F47-A6EE-8256149F7C84@karels.net> In-Reply-To: References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxjCJ1XCNz4Zrr T24gMjIgRGVjIDIwMjMsIGF0IDE2OjE0LCBTdGV2ZSBCZXJuYWNraSB3cm90ZToKCj4gSGkgTWlr ZSwKPgo+IEluZGVlZCwgSSdtIGdldHRpbmcgYSBsb3Qgb2YgcmV0cmFuc21pdHM6Cj4KPiBbwqAg NV0gbG9jYWwgMTcyLjE2LjIwMC4yIHBvcnQgNTU1NTEgY29ubmVjdGVkIHRvIDE3Mi4xNi4yMDAu MTgyIHBvcnQgNTIwMQo+IFsgSURdIEludGVydmFswqDCoMKgwqDCoMKgwqDCoMKgwqAgVHJhbnNm ZXLCoMKgwqDCoCBCaXRyYXRlwqDCoMKgwqDCoMKgwqDCoCBSZXRywqAgQ3duZAo+IFvCoCA1XcKg wqAgMC4wMC0xLjAwwqDCoCBzZWPCoCAzNi4yIE1CeXRlc8KgwqAgMzA0IE1iaXRzL3NlY8KgwqAg NjDCoMKgIDkuOTggS0J5dGVzCj4gW8KgIDVdwqDCoCAxLjAwLTIuMDDCoMKgIHNlY8KgIDM1Ljcg TUJ5dGVzwqDCoCAzMDAgTWJpdHMvc2VjwqAgMTQzwqDCoMKgIDExMSBLQnl0ZXMKPiBbwqAgNV3C oMKgIDIuMDAtMy4wMMKgwqAgc2VjwqAgMzQuOSBNQnl0ZXPCoMKgIDI5MyBNYml0cy9zZWPCoCAx NDHCoMKgIDcuMTMgS0J5dGVzCj4gW8KgIDVdwqDCoCAzLjAwLTQuMDDCoMKgIHNlY8KgIDMzLjkg TUJ5dGVzwqDCoCAyODQgTWJpdHMvc2VjwqAgMTk4wqDCoCA5OS41IEtCeXRlcwo+IFvCoCA1XcKg wqAgNC4wMC01LjAwwqDCoCBzZWPCoCAzNC45IE1CeXRlc8KgwqAgMjkyIE1iaXRzL3NlY8KgIDE2 N8KgwqAgMS40MyBLQnl0ZXMKPiBbwqAgNV3CoMKgIDUuMDAtNi4wMMKgwqAgc2VjwqAgMzQuMiBN Qnl0ZXPCoMKgIDI4NyBNYml0cy9zZWPCoCAyMjHCoMKgIDIuODUgS0J5dGVzCj4gW8KgIDVdwqDC oCA2LjAwLTcuMDDCoMKgIHNlY8KgIDM0LjEgTUJ5dGVzwqDCoCAyODYgTWJpdHMvc2VjwqAgMTY5 wqDCoMKgIDEwMCBLQnl0ZXMKPiBbwqAgNV3CoMKgIDcuMDAtOC4wMMKgwqAgc2VjwqAgMzUuMiBN Qnl0ZXPCoMKgIDI5NSBNYml0cy9zZWPCoCAxNTnCoMKgIDcuMTMgS0J5dGVzCj4gW8KgIDVdwqDC oCA4LjAwLTkuMDDCoMKgIHNlY8KgIDM0LjMgTUJ5dGVzwqDCoCAyODcgTWJpdHMvc2VjwqAgMTM4 wqDCoCA0LjI4IEtCeXRlcwo+IFvCoCA1XcKgwqAgOS4wMC0xMC4wMMKgIHNlY8KgIDMzLjMgTUJ5 dGVzwqDCoCAyNzkgTWJpdHMvc2VjwqAgMTgywqDCoCAyLjg1IEtCeXRlcwo+IC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0KPiBbIElEXSBJbnRlcnZhbMKg wqDCoMKgwqDCoMKgwqDCoMKgIFRyYW5zZmVywqDCoMKgwqAgQml0cmF0ZcKgwqDCoMKgwqDCoMKg wqAgUmV0cgo+IFvCoCA1XcKgwqAgMC4wMC0xMC4wMMKgIHNlY8KgwqAgMzQ3IE1CeXRlc8KgwqAg MjkxIE1iaXRzL3NlYyAxNTc4wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNlbmRlcgo+IFvCoCA1 XcKgwqAgMC4wMC0xMC4wMMKgIHNlY8KgwqAgMzQ2IE1CeXRlc8KgwqAgMjkxIE1iaXRzL3NlY8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVjZWl2ZXIKPgo+IFRoYW5rcywKPiBT dGV2ZQoKT25lIG90aGVyIHF1ZXN0aW9uOiBhcmUgeW91IHJ1bm5pbmcgcG93ZXJkPyAgSSBib290 ZWQgd2l0aG91dCBpdCwgYW5kIG15CnRocm91Z2hwdXQgZHJvcHBlZCB0byA2MDAtNjQwIE1iL3Mu ICBSZXBlYXRpbmcgdGhlIHRlc3QsIHJldHJhbnNtaXNzaW9ucwp3ZW50IGRvd24gYnV0IHRocm91 Z2hwdXQgd2FzIGFib3V0IHRoZSBzYW1lLiAgTm90ZSwgdGhlIFJQaSA0LCBhbmQgcHJvYmFibHkK dGhlIENNIDQsIGJvb3RzIGF0IGEgbG93ZXIgY2xvY2sgZnJlcXVlbmN5IGJ5IGRlZmF1bHQsIGFu ZCBwb3dlcmQgcmFpc2VzIGl0CnVuZGVyIGxvYWQuICBJJ20gcnVubmluZyBwb3dlcmQgd2l0aCAt TSAxODAwLCBvdmVyY2xvY2tpbmcgYSBsaXR0bGUuICBJSVJDCnRoZSBzdGFuZGFyZCBjbG9jayBp cyAxNTAwIGZvciB0aGUgUlBpIDQuICBCdXQgdGhlIHRocm91Z2hwdXQgaXMgYWJvdXQgdGhlCnNh bWUgdXNpbmcgdGhlIHN0YW5kYXJkIGNsb2NrIHdpdGggcG93ZXJkLgoKCQlNaWtlCgo+IE9uIDEy LzIyLzIwMjMgOToyMyBBTSwgTWlrZSBLYXJlbHMgd3JvdGU6Cj4+IE9uIDIyIERlYyAyMDIzLCBh dCA2OjIwLCBTdGV2ZSBCZXJuYWNraSB3cm90ZToKPj4KPj4+IEkgcmVjZW50bHkgcHVyY2hhc2Vk IGEgUlBJIENNNCB3aXRoIDRHQiBhbmQgMzJHQiBlTU1DIHRvIHJlcGxhY2UgbXkgYWdpbmcgRnJl ZUJTRCBmaXJld2FsbC4gSSBtYW5hZ2VkIHRvIGluc3RhbGwgRnJlZUJTRCAxNC4wLVJFTEVBU0Ut cDMgb24gaXQsIGFuZCBib3RoIEV0aGVybmV0IGRldmljZXMgKGdlbmV0MCBhbmQgdWUwKSB3ZXJl IHByb3Blcmx5IGlkZW50aWZpZWQuIEhvd2V2ZXIsIG5ldHdvcmsgdGhyb3VnaHB1dCBvbiBteSBn aWdhYml0IG5ldHdvcmsgaXMgcHJldHR5IGJhZDsgaXBlcmYzIHJlcG9ydHMgYSBtYXhpbXVtIHRy YW5zZmVyIHNwZWVkIG9mIDI5MSBNYml0cy9zZWMuIEZsYXNoaW5nIE9wZW5XUlQgb24gdGhlIHNh bWUgaGFyZHdhcmUgdXNpbmcgdGhlIHNhbWUgZXRoZXJuZXQgcG9ydCwgSSdtIGFibGUgdG8gYWNo aWV2ZSA5MjMgTWJpdHMvc2VjLgo+Pj4KPj4+IERvZXMgYW55b25lIGhhdmUgYW55IHN1Z2dlc3Rp b25zIG9uIGhvdyB0byBpbXByb3ZlIHRocm91Z2hwdXQgdW5kZXIgRnJlZUJTRD8KPj4+Cj4+PiBU aGFuayB5b3UKPj4+IFN0ZXZlCj4+IEkganVzdCB0ZXN0ZWQgd2l0aCBhbiBSUGk0ICg0IEdCKSBh bmQgMTQuMCB1c2luZyBpcGVyZjMuICBJdCBsb29rcyBsaWtlIEknbSBnZXR0aW5nCj4+IGEgcmF0 aGVyIHZhcmlhYmxlIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbnMuICBPbiBteSBmaXJzdCBydW4g KGNsaWVudCBvbiBSUGkgNCksCj4+IEkgZ290IDQ2MCBNYi9zIHdpdGggYSBsb3Qgb2YgcmV0cmFu c21pc3Npb25zLCBidXQgdGhlIG5leHQgY291cGxlIG9mIHJ1bnMsIGluY2x1ZGluZwo+PiBvbmUg cmVjZWl2aW5nLCBJIGdvdCBhYm91dCA5NDAgTWIgZXZlbiB3aXRoIHNvbWUgcmV0cmFuc21pc3Np b25zLiAgVGhlIHBlZXJzIHdlcmUKPj4gZmFpcmx5IGZhc3QgRnJlZUJTRCAxMy4yIGFuZCAxNS1j dXJyZW50IHN5c3RlbXMuICBBcmUgeW91IHNlZWluZyByZXRyYW5zbWlzc2lvbnM/Cj4+Cj4+IEkn bGwgdHJ5IHRvIGxvb2sgaW50byB0aGlzLCBidXQgSSdtIG5vdCBzdXJlIHdoZW4gSSdsbCBnZXQg dG8gaXQuCj4+Cj4+IAkJTWlrZQo+Pg== From nobody Sat Dec 23 01:28:04 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sxml65Qdpz54lRt for ; Sat, 23 Dec 2023 01:28:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sxml62VNvz4rml for ; Sat, 23 Dec 2023 01:28:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703294896; bh=q9u2pl7FTJEt4M2jFHz3xk0jPR/FRA7L2JG3GgOstvE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Hmv+TrF9bKn7gIoGv3tURgO7DCvNgLQa9fzjl/nLfwM43LUkz0mv/MonVx5vN6Hc+VZr13MC7BtrFXmXFV+ZRP5Lm3ljzedKNgc0dUbPuJRp1Fkkz76I5OPTl7ta2DqOtmIiBnUHxrdwVF7b+pDaQfgWenodK+rnPJeCY/50fcGd3hwlhp31iajaVP6lIxcePDKujoZdEdj+47wWXTsovTL+Majq/YUb1Kv5bjRR/sS1gOsX4uWL6FLD91kU02hzifWFkxau896Oc3Z4nHuyMlAH9Ghi9AcatCOJFPUbF/Lx+5OODG0ZWBd0+5ZsHwGhqOio00Wx8D2T08U3wh+LlA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703294896; bh=v/ppSP8oNMgM+cJRTXWFd5gPWF9uAB2KcbTXO0MV0ux=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=seUQrilvSi6cRZhz0XPmWOUNpTHgGZtDmL5aGyv7jJxW5WViC8qT1TgwOev4WijyOEqEgzEzdBxydFFiuoakmK9hic5zeBzWTkailByP81goEYIMSU3NiXx9yQi35WCDEUKWetDbKvg9f2M7z2+GFmRBV8aViqifRru3xoE86aivAL/508uG+hZxz+xKlzvL/hy0/GNpqd8J7ziQYxJ6pxa1sYHb5acVJKSefu72tD12azbiwjz5hRLmHRcaXy4wm4ggFIKr12KLQf0N+F+WRbNxCCVsXIaFjN4II0AhfNAVFzp9gqboh0h6GwH3Nd9lSr/ujGACrrvddI4i/+HuqQ== X-YMail-OSG: u.YJOXoVM1lj0eK9Wkh7M32.Jhd08UanT.ac.975_fF.NBOwDoOsuw7cDuFc9_w wCLHpb2GrgpDr_gPFFNryRy5HBItj9XotjXPS1JhrJ4q9u4pqD5.MSA71BV5IVi.fF21vw5VAfeI g3GJp10bFTJPvsDoKgS0Uzbl1dODZ1Wj6GGaD3wEjGb7tCb5BKqd1eE7MjbKz12dIGDDqzzDEEQP xf9Q1J0nSR0Po3iVSgpB.U1hzPFcsrPd6tlQrt4VdmmZQtmLaD_nYlssfHo2TV.i.Zx1n97zNA_4 9ccD._vhWmdpELbJAdymA3gVMBnNpVRkF1erpFueAzBAhARDRI5xMKFsFcFD_r6v_1P50dm7ytcB 0azpiw8UCh2pR6Z08fojor.VVgDs_Aw.DAP2j1VG9gchKNsle1l.wdfxIk9oILBb.VmJ1VrLcvwJ xuZDyBu3zMYSN09EWhPLLZ.r6s5NTv9jQYX87mL_26qRvxZkwjGrhqQF4CDy8DLi75Qd52.033MA kmsBm2XYHvUGzLucsqcqyD1Oyu.od1aJP.w3y7LiNuCgOslHzO5ACeH9kwm.wN1nCVya3h_hGBwr O_UlK4q4BrF628vyAg2.mgCGIL0TI7_z0MQq1EycTJksB3pWynsrOUt2t6jz2LI93YhvQLC1Uvaz FioUS0PmQHRqwqRAKVjXLfD9JsxfPhdl7JvGYsKH0hAaecmp82VnnDYF1sFghqMjhlqF2Iei41CD Vdfawhf9lLNt6FDnp7zzTtuVtjhu3leFCjWauIVIvTHHouPBbnd4E5ShWq3yx_4vg1myrimVIeIc ZORL7hOIn03bKxhJqXA55fWE42u_3MIZL_8OjUnjd7mRLUVHuLTbjVWB2bC91yRQV2IWow.yTLa2 udv198XynnyQtOzXXUn.z3R4RkszM5jRFMGGnG8xV4PhA3KefM9nm0nm1osPzVEiin3qcocsoyB5 hjWomVnjgF5PMwgyK6a5ZqviX_iEU_af4XG.n5nZpHs4BT8wl2MoX86u8dRZHDsgajmVLNaVny_e Yy.8IF5JMCroY6xsej7ivlN3jD4L61XgVx_dgsfuMxyhObXW5wGGI1_jY7awve4iDuxKfMql_2Yp tMI4mZQUQSEBzUzfibvlTwY78NFEqN_C0CWykf2aTuq51enVb.Hc23TRe1B8cD8f602k_ScPEBJk llxrk7PPjFbhvWpO2KAfYaHeo3LUPe.AeWArmWMYIzBRj6gxCxlB_zdBsFnupwCwRZZ5p63ZpbMI MSEsi3Sp6WqmdcnzGEQUitd0U65CeizlLGmrwqLuDj0QnmVmcYUZqLUk8wsCiDm4wmenLr4ssZQd 3WWGLUV43mVMCHrU1V06N2n.UnLObHU47aDG3mz.DloDiE9TePLhygj05G6dEPRUmd3mIPDmojfx 1Hp7DjnAdafY5Wi5NoYpyVGnJt1sWFdNqabyC7gf_CTY8E7LnBb6pPXMIxJ7F0MeT6tBGX0qtYkc rsF0F88XsSMWnic4QE9KFL.kyiaK9__QwuJlM01SlrfSu_Rc2OXmrbJ85EQHi.Fn1DKvusCj5AHk PmeVCG5fU_u4oc6tzYocHvXA3bm8XCJp8lUOC76ldh_XvT.KhkiqKXV_4Ts4NEmkXB3JFUDiMadZ X3t8xw_gP1TgQ7MknTdEajE5EcB.4HH9rJ597NmVwCsaPM23KaER6aDhWfy235tWQ_XAUUuRmnuX FKcctT0rcDUYnrJfzdCDJZBsLNMGuqGZ5ZyNLQiskOPi3_sjbCYiARtwf9OBuK_OMHy3FE3R6vbI nvhtA83LoRr5GML8mpdxzdWCq87SG_dza9Npy1HqIMkwghiCAknjWOdfujYT.ozf2e40zbPrlmNz 7WytHyfk3bwohCaeuSsyRxstLFuFima3FbMruQCgEXwqEXMTNlTZ93Vb.VFA6oNF3eG7R_DVNqsW pych.ROKeoaJBae7y6RJN9Zza_HtJIQz0n3xzaARNqsptF0gI09Zws0FizQUyzTfDGXgXP9Q8lvv Sn3FvP9lcfGcPZCQ4Dwc6X2OA378MUDs9Q7z3Q6icmyOjR9OG.QCGCyKSLmAkcD11RPLqXzm3EnC KPComfBtFKyC7FefVGI5v3ikcAP5Q4JkYfVgIA9bjtawcLK4GYL7_yCa4hZXke9iaILkQ3crykNK yhx4Xlm0Uxm.CgxZzCe_UMq98BJuPLPKQXIgQLy94gIsa1dZ7LboSGC5IltyDrmZ.YF9WZWr6Opl ThmFuzdlVWAaKOjgoXfQ90OvPBtczPql1Mjgx3OUHC6iUbraNsquE6JdPFMfFFvOmakjl7EEvOb. h X-Sonic-MF: X-Sonic-ID: 248504ce-7509-4f5a-a592-67c23e9d22be Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Dec 2023 01:28:16 +0000 Received: by hermes--production-gq1-6949d6d8f9-k52jv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 26a369e05ba9cb26f9c6b47ac4976467; Sat, 23 Dec 2023 01:28:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB From: Mark Millard In-Reply-To: <2E1B887B-EB3C-4F47-A6EE-8256149F7C84@karels.net> Date: Fri, 22 Dec 2023 17:28:04 -0800 Cc: Steve Bernacki , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> <2E1B887B-EB3C-4F47-A6EE-8256149F7C84@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sxml62VNvz4rml On Dec 22, 2023, at 14:48, Mike Karels wrote: On 22 Dec 2023, at 16:14, Steve Bernacki wrote: >=20 >> Hi Mike, >>=20 >> Indeed, I'm getting a lot of retransmits: >>=20 >> [ 5] local 172.16.200.2 port 55551 connected to 172.16.200.182 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 36.2 MBytes 304 Mbits/sec 60 9.98 = KBytes >> [ 5] 1.00-2.00 sec 35.7 MBytes 300 Mbits/sec 143 111 = KBytes >> [ 5] 2.00-3.00 sec 34.9 MBytes 293 Mbits/sec 141 7.13 = KBytes >> [ 5] 3.00-4.00 sec 33.9 MBytes 284 Mbits/sec 198 99.5 = KBytes >> [ 5] 4.00-5.00 sec 34.9 MBytes 292 Mbits/sec 167 1.43 = KBytes >> [ 5] 5.00-6.00 sec 34.2 MBytes 287 Mbits/sec 221 2.85 = KBytes >> [ 5] 6.00-7.00 sec 34.1 MBytes 286 Mbits/sec 169 100 = KBytes >> [ 5] 7.00-8.00 sec 35.2 MBytes 295 Mbits/sec 159 7.13 = KBytes >> [ 5] 8.00-9.00 sec 34.3 MBytes 287 Mbits/sec 138 4.28 = KBytes >> [ 5] 9.00-10.00 sec 33.3 MBytes 279 Mbits/sec 182 2.85 = KBytes >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 347 MBytes 291 Mbits/sec 1578 = sender >> [ 5] 0.00-10.00 sec 346 MBytes 291 Mbits/sec = receiver >>=20 >> Thanks, >> Steve >=20 > One other question: are you running powerd? I booted without it, and = my > throughput dropped to 600-640 Mb/s. Repeating the test, = retransmissions > went down but throughput was about the same. Note, the RPi 4, and = probably > the CM 4, boots at a lower clock frequency by default, and powerd = raises it > under load. I'm running powerd with -M 1800, overclocking a little. I explore here fixed frequencies: 2000 MHz, 600 MHz, 1500 MHz, 1800 MHz (no powerd use) Based on: # uname -apKU FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch6 # more /boot/efi/config.txt=20 [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # over_voltage=3D6 sdram_freq_min=3D3200 arm_freq_min=3D2000 force_turbo=3D1 # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 dev.cpu.0.freq_levels: 2000/-1 dev.cpu.0.freq: 2000 # iperf3 -c 192.168.1.157 Connecting to host 192.168.1.157, port 5201 [ 5] local 192.168.1.159 port 52424 connected to 192.168.1.157 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 243 328 KBytes [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 18.5 KBytes [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 149 173 KBytes [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 150 456 KBytes [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 159 456 KBytes [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 160 538 KBytes [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 143 1.43 KBytes [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 215 167 KBytes [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 194 580 KBytes [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 157 552 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 1720 = sender [ 5] 0.00-10.01 sec 1.10 GBytes 941 Mbits/sec = receiver iperf Done. Note: The amd64 system running main [so: 15] and the RPi4B are on the same ethernet switch. With the 4 overclocking lines in config.txt commented out : # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1 dev.cpu.0.freq_levels: 1500/-1 600/-1 dev.cpu.0.freq: 600 Note: the default context lacks 1800 (based on the RPi* firmware vintage in the snapshot). Later I show having 1800 instead of 1500. # iperf3 -c 192.168.1.157 Connecting to host 192.168.1.157, port 5201 [ 5] local 192.168.1.159 port 42060 connected to 192.168.1.157 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 70.8 MBytes 594 Mbits/sec 18 195 KBytes = =20 [ 5] 1.00-2.00 sec 73.8 MBytes 619 Mbits/sec 8 293 KBytes = =20 [ 5] 2.00-3.00 sec 73.6 MBytes 618 Mbits/sec 19 250 KBytes = =20 [ 5] 3.00-4.00 sec 73.6 MBytes 618 Mbits/sec 9 366 KBytes = =20 [ 5] 4.00-5.00 sec 73.3 MBytes 615 Mbits/sec 9 447 KBytes = =20 [ 5] 5.00-6.00 sec 73.3 MBytes 615 Mbits/sec 16 303 KBytes = =20 [ 5] 6.00-7.00 sec 73.2 MBytes 614 Mbits/sec 0 455 KBytes = =20 [ 5] 7.00-8.00 sec 73.6 MBytes 618 Mbits/sec 1 328 KBytes = =20 [ 5] 8.00-9.00 sec 73.5 MBytes 616 Mbits/sec 16 246 KBytes = =20 [ 5] 9.00-10.00 sec 73.3 MBytes 615 Mbits/sec 0 435 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 732 MBytes 614 Mbits/sec 96 = sender [ 5] 0.00-10.01 sec 732 MBytes 613 Mbits/sec = receiver iperf Done. Assigning 1500: # sysctl dev.cpu.0.freq=3D1500 dev.cpu.0.freq: 600 -> 1500 # sysctl dev.cpu.0.freq=3D1500 dev.cpu.0.freq: 600 -> 1500 root@generic:~ # iperf3 -c 192.168.1.157 Connecting to host 192.168.1.157, port 5201 [ 5] local 192.168.1.159 port 28904 connected to 192.168.1.157 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 4 472 KBytes = =20 [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 6 464 KBytes = =20 [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 5 452 KBytes = =20 [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 3 443 KBytes = =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 4 421 KBytes = =20 [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 4 397 KBytes = =20 [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 3 378 KBytes = =20 [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 5 355 KBytes = =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 2 476 KBytes = =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 5 446 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 41 = sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver Adding arm_boost=3D1 to config.txt in order to have 1800 instead of 1500 (needed due to the RPi* firmware vintage in FreeBSD snapshots): # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq dev.bcm2835_cpufreq.0.freq_settings: 1800/-1 600/-1 dev.cpu.0.freq_levels: 1800/-1 600/-1 dev.cpu.0.freq: 600 # sysctl dev.cpu.0.freq=3D1800 dev.cpu.0.freq: 600 -> 1800 # iperf3 -c 192.168.1.157 Connecting to host 192.168.1.157, port 5201 [ 5] local 192.168.1.159 port 27499 connected to 192.168.1.157 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 169 104 KBytes = =20 [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 320 KBytes = =20 [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 157 52.8 KBytes = =20 [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 143 87.0 KBytes = =20 [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 143 121 KBytes = =20 [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 159 104 KBytes = =20 [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 138 238 KBytes = =20 [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 152 276 KBytes = =20 [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 145 115 KBytes = =20 [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 162 283 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 1518 = sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver iperf Done. =46rom this it appears that the Retr counts do not seem to make much of a difference to the Bitrate's achieved. But the arm frequency does if 600 is involved. My understanding is that arm_boost=3D1 was later made the default in later vintages of the rpi* firmware. arm_boots only causes 1800 for Rev 1.4+ . Pi 400's have 1800 available by default, at least for modern enough RPi* firmware. https://www.raspberrypi.com/documentation/computers/config_txt.html is not necessarily accurate for the older RPi* firmware that FreeBSD uses in its snapshots/releases. > IIRC > the standard clock is 1500 for the RPi 4. But the throughput is about = the > same using the standard clock with powerd. >=20 > Mike >=20 >> On 12/22/2023 9:23 AM, Mike Karels wrote: >>> On 22 Dec 2023, at 6:20, Steve Bernacki wrote: >>>=20 >>>> I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace my = aging FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 on = it, and both Ethernet devices (genet0 and ue0) were properly identified. = However, network throughput on my gigabit network is pretty bad; iperf3 = reports a maximum transfer speed of 291 Mbits/sec. Flashing OpenWRT on = the same hardware using the same ethernet port, I'm able to achieve 923 = Mbits/sec. >>>>=20 >>>> Does anyone have any suggestions on how to improve throughput under = FreeBSD? >>>>=20 >>>> Thank you >>>> Steve >>> I just tested with an RPi4 (4 GB) and 14.0 using iperf3. It looks = like I'm getting >>> a rather variable number of retransmissions. On my first run = (client on RPi 4), >>> I got 460 Mb/s with a lot of retransmissions, but the next couple of = runs, including >>> one receiving, I got about 940 Mb even with some retransmissions. = The peers were >>> fairly fast FreeBSD 13.2 and 15-current systems. Are you seeing = retransmissions? >>>=20 >>> I'll try to look into this, but I'm not sure when I'll get to it. >>>=20 >>> Mike >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 23 04:26:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxrjT3XGHz54wXt for ; Sat, 23 Dec 2023 04:27:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxrjS1dQlz3QMp for ; Sat, 23 Dec 2023 04:27:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TkRpaWl2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703305626; bh=NpzCkbfVnUdXMYT250EYo8pPnWmULxM8DtMBeqRRnCU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TkRpaWl2fwEAsbBVb86zUj+3lpvWJ3mf4A5D6yOsIuoZCgWgIGj33iZbZAVZVGrCecEXt5MOWilI78iEa8U/SQdx2RZ4eyneG97ziy7hDVRn8y3/kuuOwrIXR7KwukOtYpRHAmy3vs6OJJjNsE0GovLrLhzFOUNQ/uOYXsv5C43I2MXcDuZUu+e2TJEFDKUGYhfRT/cTenCevqtMoJCuzicxkdD78/19hE31LgOpmWuXNBzr1hl/gI16u3vNByDrIkAenVIFlrDEsuHEDBPwwD8Hqm6Dmyfrwb5tpeV4J7l1RpY1Jim2eOsKlpj/yjCCRQkns6tjbln0LmNRoSClMA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703305626; bh=Qu867JrRscY+9bUgBCA1kZkeZScdvr1/OQb2NFNaNOa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lL5wgvr/ZJqQzcatoz+Q6Kg7375ZBxj72azRWXF66kDwYxJ4tkWPDIy7ZvDtzxNjaYaD556FsWP+OHYmIRZrm0eMRA8JRo3ImyAXzBg8gpm3tNbAwqOC1ZVSm7Ew+8HRNmuyNWxZCoIDOKpLSEyjf3NrolWv6Kp6P8HC++GXG+VmrPBBVCDkP0GlRYmWZrhVm+G3sB1lbUVLAMWBpv/W51us2b/IM7cojZ7CoxakIDb1OvCCXYT0At2pY78gYAFtns/j1xxgdannaN/+q6ld2cZ6ZVso9iVPdamyExtQqbBXgzwAuKjL1P7wKrF6cSODyCB7Pe737a6CJGZeQ07k2w== X-YMail-OSG: flqwsRQVM1nECub_TbZyCA6kQR6Q3JlTH0oJHx7995_TnR7GaNwycDK0R1yHh94 FLLzJ_nFuNPfWhVPQxIJRMXOKhGDbSOdEmW9FrFeABovmZhiOMrj0jfBo4vF6gJCRtVcOSA21aPf FjknnUy2FZCrTLV6bE_ZhX7wFEVVyY_RTyrLTGt0R.YDiNcYHbxlSab6_GR6eKkaFICWrIdtYehd j4rSUauF2S0whxRN3INHnB6_O5gT2xOKwf71sNR78jGe28DJNpB39SQN_iw2881CgBziZQyAYBfB skMdg2V1gVcpWGifCiAp2L6uLixx0mJyTQsulAh051BZLOO4HPfBwZXmsWQZcZm5Gs7qfMAvRfNG cI25p7BrrNdDifsdaaMLHqXCGFam2vVkUocoobDMMKMzk0eC3ynVgKndLb6xDvPjEPNIgKz7olyL t00yJ.v.qmDfKt.EBNjSYZupZckIc3kGaZu8PwAHkMUUIawSudMArdbyjLAEIY7BhwICywqBzO4x eUue169vXXfk_KRB9z2eV0MrgA._VNjPasOFMYGdjE8jSSkFml65bPgzG6SohpOoZsHXIsZSnAHI n.Mjt5deeo6O9Es8uiw8sGp7ylUnFEqcZt.zxI4aSvk1EFjhNL9UMLB3RIVeajU9WP0FL8WU.01k BGjUjURSiaBKR.diNO5F1TlmPk5GOzErEEmSYr_oy5ZRDqDpABxsq75V4g5YriEOIIb7aUa7eBad SsNtv5ww.9tTaawcs.zsLgBfgU5lv4Gc.tvUh5iEN1cYFR_udCuGBxO5kFFEI4fRx3uXQb4xoE6d QCqt_nrIjX12yBh.H3Lg_MURJ.vITJjPdO5n_xat5beAJHQ5b0dWG_nB4subG12qRxMq7zy5nbaX N_2gh683Uaahb1cm5r3t2boSjQURn.v9l9sje6IKghEIxRfLNaoYBvKBd_cx.VAZT1jxJDdcgtEt sq6aPrdUEpwQfMoDHihXhZTBQKWhSe4gRJe5fP_UfAWdb8kbGz0ZtriV8ENlbZw8YJQgLcPrV0cA _T8vz.vdA50qA.iyHZuECLp5nNyNmXY_3V7ftfBSm9.Ou0KG5WRZjhBhVbzJb0CNUVEJ521Xnbr_ ei6ewFwRtcfBpikscz4ree0ENhchVasGF_tvaDrYJvTmV4y3E6SWaZrgs_wvJnTwBeZzNLmvacQ6 z8rn6WjQjCgqGdT7BXPiOtLT6lWr2sDz3RZTl9m88LNB7AdUZXoLle468UimZc3qZ1HurBPcN40L LsWzgogfEEuc6UHWrvkwQj6oBqRXpW4RuhjpY_zfyKgSjgaSHnuWHCHDtCfS35Aomts.ULYHHqjs 4IboSToK7vaBXNCPzd11awlkTWIUss4Vhveg0NLTJ5PiIVE7VgxK3C96uhE1IwFzFEet_rOVpoC_ LhGxblvi2HcI7klHxGM7tRHi2WIeSkm_3HQjFhxQeV_W3urLCvCNLR.jB1LNej_g6h5uydwA1GCl PKN3.eHWk9ib1rRJfbU4preN48eltpNFS.DjqRmOklmciivCvgwgBr8sm..GZC9X6V4JRpFI_FLf VXRm8Ctt1m0.so0VD7FWPojxxNs.ya3NjRSwI51.Mp2efPARuR5TFcG4Da7VF1.SkYt6S7q_pe4j xTbqz.BpXIYv1E6fVgu9KB5TxGTX23vEKss5WxHZrG2DeQDLsPuoBvEUj1KK4PAGBt8dM6zHMHZm yCmFa0aMZ71DepbaMU9_FwG3W1e5wp0Uf84hEeJ6OMCKvd6LW1eeS9lQIFRaniR1_LUDuC586rYg sy1UDADGSajzvWz2FcCndNts2zrViH8VvZcj2LMqgqmg2vfKguWCCdZR05TzbeUz2x4XFdUdKgr2 0SpeQTKwLTjfqd5I1n2HifI3GsBme..J8DNffkX6dTL3s5hWCmiwFFE0ZwJ9s55.n3VOQ4sXMyOY 6azRWjWLXMLj54Dqz9sElvbU9oy_GzZc41QvMsqUnhCnmDj.vTa9XVb5F.6Ucnw_Hx8_EmCRXmPQ kpPw37sFH0gWsHmMGRIG3PPumFNiMJz1daly.EsEsfajTqBUF1Os1mcYgiGH_ETjC89rJ8IfLRIt c7EVadl0ISkU6nvp2rYGmdfo1HAN7XVEyQw5kl.4lcX5zjvMMsHowPOrDMAEwEZ9oT0009nZgncA 0KnfaAx7OXTY6Y_eimUphTdYYnwf9PGjQEGKKJWMLwnxw35GPmZbl.MwBScMOCFMpWsPN3lqb3Zg Xcz.WBbSMUhS.WGLNaFHjFuhrAEwHZgYmKdtwkPOHgorimnmte2So8RtIvizXNeLU8uORZudbuOT P6tw- X-Sonic-MF: X-Sonic-ID: 659d400e-3655-4e49-a42c-fefd03eff840 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Dec 2023 04:27:06 +0000 Received: by hermes--production-gq1-6949d6d8f9-x28h5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 011c176309ef27a4607b821aa4e0f163; Sat, 23 Dec 2023 04:27:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard In-Reply-To: Date: Fri, 22 Dec 2023 20:26:51 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SxrjS1dQlz3QMp X-Spamd-Bar: --- On Dec 17, 2023, at 23:34, Alex Samorukov wrote: > On 2023/12/18 01:41, Mark Millard wrote: >=20 >> I'll note that I've never done such "armv6-only processor" testing. >> I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts >> until after something like 2024-Jan-01. > I also checked llvm compilation logs: >=20 > -- LLVM host triple: armv6-portbld-freebsd13.2-gnueabihf > -- LLVM default target triple: armv6-portbld-freebsd13.2-gnueabihf >=20 > So I would expect it will not use armv7 instructions based on the = "host" (jail) EABI. >=20 > Also, I see that rust is failing to build: >=20 > rust-1.74.1.log:=3D>> Ignoring lang/rust: is only for aarch64 amd64 = armv7 i386 powerpc powerpc64 powerpc64le riscv64, while you are running = armv6 (reason: requires prebuilt bootstrap compiler) >=20 > Not sure if it's done due to qemu problem or not, maybe will try to = remove ignore later and rebuild I got access to one of the RPi4B's, so looking for myself . . . I used = FreeBSD-14.0-STABLE-arm64-aarch64-RPI-20231216-2ef9079ece5a-266002.img dd'd to media in order to boot: # uname -apKU FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400501 1400501 I downloaded = FreeBSD-13.2-STABLE-arm-armv6-RPI-B-20231216-9986fd59d855-256898.img and dd'd it to media as well. # mount -onoatime /dev/da1s2a /mnt # file /mnt/bin/sh /mnt/bin/sh: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for = FreeBSD 13.2 (1302509), stripped # chroot /mnt/ # uname -apKU FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm armv7 1400501 1302509 Note the "arm armv7". An aarch64 kernel can be built and booted that makes that "arm armv6" so that more things work. # uname -p armv7 # make -V MACHINE_ARCH armv6 That contradicts what man uname reports relative to "uname -p" and = "MACHINE_ARCH": -p Write the type of the machine processor architecture to = standard output. (make(1) uses it to set the MACHINE_ARCH = variable.) # c++ -v FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) Target: armv6-unknown-freebsd13.2-gnueabihf Thread model: posix InstalledDir: /usr/bin So, without the adjusted kernel, an odd mix of armv6 and armv7. As for rust vs. armv6: the lang/rust/Makefile has: ONLY_FOR_ARCHS?=3D aarch64 amd64 armv7 i386 powerpc64 powerpc64le = powerpc \ ONLY_FOR_ARCHS_REASON?=3D requires prebuilt bootstrap compiler =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 23 07:08:27 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SxwHt6pNQz546b2 for ; Sat, 23 Dec 2023 07:08:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxwHs3G4Xz3f8T for ; Sat, 23 Dec 2023 07:08:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EJtLveym; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703315319; bh=X28/1zi5xflVj4rnP5n2NCzraui24MwyrbxZesCDnHM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EJtLveymIc1LPoRl3kQYuP5+YxnxmCSR4NpufMGihIQtddnI2j3oNEygeemnzi8nujIUtmztEzY3jXyas4ct22XIs4CBqGt5hKbBsPjzvH5cFqh8bBXuw2GiPNpmDbaSkpl/RR2hRXX+w0s6fhl96JqHeyT2W8Z6Eby1iLRg5UR/5q/YmXLvam0Avw0ro0mFcSZKeDPWGSNwC+V4diP/p8zkHun/Mwi6A5qU61J6AKto1KZHAgA7QE1hpFMzxbA20cZD5hIHKvyCQ7gPgwFisVj4JIB7lQlz28aL/n5NGM5Yrh39AmZP3UM1SFck0ic6tuqNytQCYIsmGfg+qg4+Tg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703315319; bh=w+vpmHGKiz1R9PXMSYWN+DLCrupP8uqlbWvwm1oCalD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XU+cHjRJnihcmxfmmwxt9GmQRT19uMdicf56+80TCIPM6aUXjC517OSkA//6XGDfSRsvAQ8WqvGvOuZv4fzxcW6g0UMcPac0zcfkIqZwWAdfZB8hi/sBMj3N2TlrmZQnyIaRVMUS4SoT874ElaoPLhT14IH6APYjjI2hSIEmBTVH4rishSWGqPUQbYaWQxkQ2FeSn7feMY/eBLsQhbGZl92oAWDdMoxx4rQhi8CDAbGUKkathJXfGAkzRfuqP/A6aDV5pQeT8zy1gHp9VbWrgWIKPFI/Daip0e+64lbf4DrAzZvue6pkdGK+dNCnIOSZjiQZg49QdnsChIw0OS5vGA== X-YMail-OSG: _dXEsEkVM1nG8VMvOnVaiUbgS_uBOk6HvwlUyaDgzbFMv6EOE_XwjLZ9JUdSC7R C5m5_neJydTXcOaZ92w7M4O5aFNYDoA5KTNrdqYxuwhHzPQx4le0he8V0AL_IWCOZSUgZGAv0OXu VcoF43XVXnnLBxTx3.u4fD.7pnA.wqbwTcaIj_s551k5T55Z5UbdcZqaRbUaoKGdkQdb23Pobvk8 kmqEfjhtFQC7rx1.rv66SIpWIKaM3RqGQ4OXWDa0TumOXkeInxkStDFSQgWH3I7gzzilvIFwBjBI hGTwjkkTd73gBCiL0_UPNhXqwp4OGtWdkAyjjQsACgJaGpn.3JQGIX9vG_xtFz_wl1u.UhP7qQQA 7cK14YwafbKs6IdIi.8G6Lep8rCpFrHArtAuGjiLLhI.v3xgUGEnqCDGAfH_N9P4C13luZBihudF juhV7oQ9.MIBNVl7im9X0jpmfsK.G.KLFDRNM9B57F7W0RDPyyx9TEA19IpcPNAusdSNRdEaxfa0 fT4A3EgWtE3t314uzxEm7vvZrie86sZoU0SLqvdU7UMeFfa_ryEiMB9d0PyxjjgXsPa9Jpj_Idv8 PIC5WKHc16oRLu4HlDQ.Npl1zHvn2cv0UYWL5QYnNGiUJKJIk8bF8A7P8HDDgaQyWIK8r.D3Jqq3 QNM8owzHHUoSvEMnbev70v3MULfilXD5lXGr3ImuWPppZcvbOdre2w.5AuJR8pDAz_W1rFc4Qryf VL5xRwfcdPxtaOqfhxTO7uQ49S1EgipUz7Bo.CvDymYvN6kF_byhquse4QsTVZsy9EweOKmOecaF C61mxZrxocu64NKEqWju72dkNndBdwBJBs5vBaIHoCPWiRDtKAS67z7q4A735GS9GBDYXTK7P5nQ 6DHL9m9q_P7xzzsEtN2_dr6jvUzhiKdwHgEW7wunkeYcfIlt2byyLyNLbPXKW6zgN8Yy8r5wwfN0 Zl3THjC4ShlwX_5_3.uUz2O5yX9cYLibWV0rLrHXdhrtSkQL9Mb12aOSB3G8YjisT4eWhCFoKF.B xN6Cv.jsq.mzXH3jk5xt5JDtN4rgHIhrPC4WtDisDy.FwMIfKjmmaQNK6RByixMyxRRaNSAQu456 sMQvh7jBgSUqDcvfYtS6tPTKNKOnIU9WZAE35zvbAFJcZKeQ7KEk0tVyuD7U4nxcizoY4YwStNPv 52lPqSFpCNiLhp1HXZUX9QbyYVxjBmD_SM1fGKXWe2EsqR94jWxvrNdlzQaJkvIVlDsj2WQ2jr9I l4ak1VKE1hKb89hyzxQLOr47Ap_Mfb7vcCO7AXy0grlAgm8gTIOax1vpfP9dOvxPYGlgHSJA414e aEp5AkcMHI2v62ffnSB95oDLW01azdHrW6MZ.oX1c9sLf8YkANdvxQQq00L7.6cI_ynKdpWGb4_P _r_6j3i1sdn80y10V4b9_RYEUN1EgfYKUWSfkktHHKWL8n0IWr8KjCfSJ2.nfOctP60DYvYnv3Na Cp2w.9FYS59qlPPPfUn4QPD4NJV.OopHGhDBl.xfSNHRfWvY0Fa.r3v.ugFpQdTXPtCfKLfQdlT4 GhwfdeUueq3n9S4TAiDOT_mMR7pFau5MUh8oDSmfEoT4kzxv6Wml.7nIGFtq.N3F4F86mYUgeyTH 3P33U9HSvSQhjOwqXMeGF0Yg_a3pJFCbXYCHys2ONqjH2OnzK.jKByT8n5CwDx6qqNfnovm6M2TV y5DDe1_48EjOLgzymhsz63qZ6gpCsbog9kMmntiBb3DHHe00c6ozr6GZP8EH18r_RI6KCwpKgnCz drI1QH7YSafcokP6dg0O2IxG8psnelRXADztBhiN6fe4Ku6jlOyEI3tz8TuCfDOJzMa8QDihw4Hw OtBQ88VC2ZHMHPMhpS4MDk1Pw8ncuNIjhhOd2JMURGqUzWNZ9lt8gMgAO6eNM4qXhz24nZClMzAF 8XLkC.2VGzc16Z7orvjEfXVO1_JPbSqlzHCwNtaN985BUEJUBIyTnGKC1UPj.JnfiO8C4496i7c6 NTukJ79musrLu0cbEI8PByZpJR31TnzuYNnC6rDIppjHu3hqUoLLvw2bPcc7grh50jxAfV8Rv24P C3AoQItrXUVb7nKcacIl8UBKQojzfSlubynzMdnwjoQvzpujyMc0vhrjjwUCq5K7PmcuzFlcIykC XV7yWn1A7feOaa587oN57a3BUCHlLKG2Yx.tCPNM1yqBGs2_n5Xp1Z.rSiuIYTUVk00VWknAZmKY ynNkAUaCjCYP5NWsExc3SXU62jDk2To_BLpFO8Lt9HSoxfc3TCa.Op9cmceFU4IiRqjW77U1t8cC fKmg- X-Sonic-MF: X-Sonic-ID: 41ed62ce-4e68-408d-9ad1-4ba491b52ddf Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Dec 2023 07:08:39 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID be08d56132730ad4fa61112f8f7ce81c; Sat, 23 Dec 2023 07:08:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) From: Mark Millard In-Reply-To: Date: Fri, 22 Dec 2023 23:08:27 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <90C9262D-E681-45C1-89F0-18B36A105F78@yahoo.com> References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> To: Alex Samorukov X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.30:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SxwHs3G4Xz3f8T X-Spamd-Bar: --- On Dec 22, 2023, at 20:26, Mark Millard wrote: > On Dec 17, 2023, at 23:34, Alex Samorukov wrote: >=20 >> On 2023/12/18 01:41, Mark Millard wrote: >>=20 >>> I'll note that I've never done such "armv6-only processor" testing. >>> I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts >>> until after something like 2024-Jan-01. >> I also checked llvm compilation logs: >>=20 >> -- LLVM host triple: armv6-portbld-freebsd13.2-gnueabihf >> -- LLVM default target triple: armv6-portbld-freebsd13.2-gnueabihf >>=20 >> So I would expect it will not use armv7 instructions based on the = "host" (jail) EABI. >>=20 >> Also, I see that rust is failing to build: >>=20 >> rust-1.74.1.log:=3D>> Ignoring lang/rust: is only for aarch64 amd64 = armv7 i386 powerpc powerpc64 powerpc64le riscv64, while you are running = armv6 (reason: requires prebuilt bootstrap compiler) >>=20 >> Not sure if it's done due to qemu problem or not, maybe will try to = remove ignore later and rebuild >=20 > I got access to one of the RPi4B's, so looking for myself . . . >=20 > I used = FreeBSD-14.0-STABLE-arm64-aarch64-RPI-20231216-2ef9079ece5a-266002.img > dd'd to media in order to boot: >=20 > # uname -apKU > FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400501 1400501 >=20 > I downloaded = FreeBSD-13.2-STABLE-arm-armv6-RPI-B-20231216-9986fd59d855-256898.img > and dd'd it to media as well. >=20 > # mount -onoatime /dev/da1s2a /mnt >=20 > # file /mnt/bin/sh > /mnt/bin/sh: ELF 32-bit LSB executable, ARM, EABI5 version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 13.2 (1302509), stripped >=20 > # chroot /mnt/ >=20 > # uname -apKU > FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm armv7 1400501 1302509 >=20 > Note the "arm armv7". An aarch64 kernel can be built and booted > that makes that "arm armv6" so that more things work. >=20 > # uname -p > armv7 FYI: # env UNAME_p=3Darmv6 chroot /mnt/ # uname -p armv6 > # make -V MACHINE_ARCH > armv6 >=20 > That contradicts what man uname reports relative to "uname -p" and = "MACHINE_ARCH": >=20 > -p Write the type of the machine processor architecture to = standard > output. (make(1) uses it to set the MACHINE_ARCH = variable.) >=20 > # c++ -v > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) > Target: armv6-unknown-freebsd13.2-gnueabihf > Thread model: posix > InstalledDir: /usr/bin >=20 > So, without the adjusted kernel, an odd mix of armv6 and armv7. >=20 >=20 >=20 > As for rust vs. armv6: the lang/rust/Makefile has: >=20 > ONLY_FOR_ARCHS?=3D aarch64 amd64 armv7 i386 powerpc64 powerpc64le = powerpc \ > ONLY_FOR_ARCHS_REASON?=3D requires prebuilt bootstrap compiler =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 23 18:36:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyCYh4yZSz54r6Z for ; Sat, 23 Dec 2023 18:36:40 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyCYg49pTz3ZhD for ; Sat, 23 Dec 2023 18:36:39 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZtBZKUM2; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a2358a75b69so493000766b.1 for ; Sat, 23 Dec 2023 10:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703356597; x=1703961397; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FqpCMx4QSojY+kaProtvCG8Dq0PnJILwro7IB2Uj6BY=; b=ZtBZKUM2ILtDk9O+7fvTIU8UO4To4IPSs+jb3bWE1vAnWzD4jsTd19nE6a1q/RZY9F ILO08LpWCqs5h+PHfKR8l2o1WXAb6Et0FugNBhEL6r/Q0QJIgPRuvUmxJRqBLbJEcyBb RXrraMFn3rrwd4KWQc8VNlNzYP0UUcm5NLWahHMqB4ZLqgAVTfkcEfRSDziKnlaa26zV p0lYjaLY9CIvmb985yH6BFQJPxGCeAsktScfMq+jEJOFlqWJMa09raWgfy5O6xJkQy8J /KFydUlbsSPUmQh/D5Wac4GpWHszE6xEuGoW19/yWK0B9iDnL0FXvKRvBKoKG5fFReen +mug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703356597; x=1703961397; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FqpCMx4QSojY+kaProtvCG8Dq0PnJILwro7IB2Uj6BY=; b=E4EGleb7LwUzal5AkJ6qP2IzMXHAr/mCXQXDf2/IAqYiK/j4g4eFJzhnmJj6jMCApo 1DiUApZUPJTB+20kVK7/5+ifsi4FJYMkDEOP1MiZg0mQ6I/TyY+ziKs2NDp5Ou2hgE6r SWG4bLcYoAxH0SdJG/zi6lWt90ZmPVKI3zXFvknctD6ESxXixJSe3RMkxdtjfv+ncLAs kZMlDJmiXZzyJRzoGvGLFCAGPzhKr1eW26uo23vmF5BPUsJt3i+OjpX3ZOanFDJjO69V UFWtLXwXQKE824jOOsZHBrj/QaPScZ+61hWR3kidK7ETt1qxhRMei74mypM0S1vBnPA+ ImQQ== X-Gm-Message-State: AOJu0Yz8EKhv/XWXnAtuDEiszdtFk1qvfkBMDsiS/jKgs+B44oGocbBD eWGoHJcW4MFva0+xLKAx8t7KXAHNekHaIhAk0dc= X-Google-Smtp-Source: AGHT+IHroPD3G4W725RRFMPg/QAhEVZFjFgEwJigJcLGv4y2dnS7VVo8TJpx7BjR6P1Z3ym75DTBwvgiv1kmz7tIuFc= X-Received: by 2002:a17:906:18e:b0:a1c:8c7a:1b95 with SMTP id 14-20020a170906018e00b00a1c8c7a1b95mr2655554ejb.12.1703356596772; Sat, 23 Dec 2023 10:36:36 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Sat, 23 Dec 2023 19:36:00 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Warner Losh Cc: Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: multipart/alternative; boundary="000000000000e06319060d319c29" X-Spamd-Result: default: False [-1.91 / 15.00]; PHISHING(2.00)[arm.com->developerarm.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.91)[-0.910]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4SyCYg49pTz3ZhD X-Spamd-Bar: - --000000000000e06319060d319c29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've added this parameter to bootxen.source : guest_loglvl=3Dall bootxen.source : mmc dev 1 ext2load mmc 1:3 0x42000000 zImage-5.4.261-iommu-dma-on-xen ext2load mmc 1:3 0x51000000 xen-4.17-armhf-armmp-0x51004000.ub ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb fdt addr 0x5ffec000 fdt resize 1024 fdt set /chosen \#address-cells <0x2> fdt set /chosen \#size-cells <0x2> fdt set /chosen xen,xen-bootargs "console=3Ddtuart dtuart=3Dserial0 dom0_mem=3D1152M dom0_max_vcpus=3D2 bootscrub=3D0 vwfi=3Dnative guest_loglv= l=3Dall" fdt mknod /chosen dom0 fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module" "multiboot,module" fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x49F9A8 > fdt set /chosen xen,dom0-bootargs "console=3Dtty1 root=3D/dev/mmcblk1p4 rw rootwait clk_ignore_unused --no-log" bootm 0x51000000 - 0x5ffec000 but when I try to boot FreeBSD I don't get more informations than usual : root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen# ./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 1:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-existent domain libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable to destroy guest libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction of domain failed freebsd is an invalid domain identifier (rc=3D-6) Are you aware about a new parameter that I can use to have more detailed debug information ? On Wed, Dec 20, 2023 at 5:52=E2=80=AFAM Warner Losh wrote: > I'd think you'd need the right virtualization loader. I'm not entirely > sure the u-boot.bin you've been creating is for a dom-u.. > If I misunderstood, then the below isn't good advice. Chain booting the > u-boot, the first u-boot initializes things so you want > to start with stage after the SPL. But the different error messages > suggest that it's trying to reboot with kexec, which > isn't supported on armv7 at the moment. > > If you could boot in kvm, I think that the following would work.... > Though I'm not entirely sure how to > specify the two .fd files in your setup. The use of qemu is to have an > easy env to debug things... I don't > have a chromebook to try... > > My first instinct would be to try qemu on x86 (this is the first step of > many to get to your destination). > > If you could boot the GENERIC_SD image that we produce using qemu + > edk2-arm-code.fd that would > be a huge first step. This will give you the boot loader, I believe, to > boot in the VM that you need better > than going via the u-boot route. Since you are booting in a virtualized > environment, I think it wouldn't > matter which one :). > > So, I did the following to boot the virtualized armv7 FreeBSD environment= , > following a post on the forums I found and knew to have the right recipe: > > https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qe= mu.80765/ > > 1. pkg install qemu > 2. mkdir qemu-armv7-env > 3. cd qemu-armv7-env > 4. fetch > https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-1= 4.0-RELEASE-arm-armv7-GENERICSD.img.xz > 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv= =3Dnotrunc > 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv= =3Dnotrunc > 10. cat > start-freebsd-arm.sh > #!/bin/sh > qemu-system-arm \ > -M virt \ > -m 1024 \ > -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > -nographic \ > -serial mon:stdio > ^D > 11. chmod +x start-freebsd-arm.sh > 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD > > But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.= 0: > > Starting devd. > Starting dhclient. > DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xc4b36a60 > FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c > r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c > r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 > r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 > > panic: Fatal abort > cpuid =3D 0 > time =3D 1680843057 > KDB: stack backtrace: > #0 0xc035786c at kdb_backtrace+0x48 > #1 0xc02fdd20 at vpanic+0x140 > #2 0xc02fdbe0 at vpanic+0 > #3 0xc06304ac at abort_align+0 > #4 0xc063052c at abort_align+0x80 > #5 0xc063017c at abort_handler+0x480 > #6 0xc060f480 at exception_exit+0 > #7 0xc04a9750 at udp_input+0x288 > #8 0xc0473f54 at ip_input+0x1e0 > #9 0xc04447c0 at netisr_dispatch_src+0xf8 > #10 0xc043bf2c at ether_demux+0x1a4 > #11 0xc043d5e4 at ether_nh_input+0x480 > #12 0xc04447c0 at netisr_dispatch_src+0xf8 > #13 0xc043c404 at ether_input+0x50 > #14 0xc01c0838 at vtnet_rx_vq_process+0x880 > #15 0xc01b70d0 at vtpci_intx_intr+0xac > #16 0xc02b87f0 at ithread_loop+0x2ec > #17 0xc02b465c at fork_exit+0xc0 > Uptime: 19s > > I don't know if this is a problem with qemu or FreeBSD's kernel... > > Warner > > On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto > wrote: > >> I've asked some help on the channel #arm on Reddit and someone replied : >> >> >> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_ar= m32_bit_as_domu_with/ >> >> Maybe his answer can be useful to understand why it does not work. >> >> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini < >> sstabellini@kernel.org> wrote: >> >>> +Michal >>> >>> Hi Mario, >>> >>> I am not sure about booting FreeBSD, but I am certain that u-boot works >>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>> file: >>> >>> name=3D"test" >>> kernel=3D"u-boot.bin" >>> extra =3D "console=3Dhvc0" >>> memory=3D256 >>> vcpus=3D1 >>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> >>> I don't know for sure if you can boot FreeBSD but you should definitely >>> be able to see the u-boot command line prompt. The fact that you are >>> getting this message: >>> >>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader >>> found: Invalid kernel >>> >>> Means that something is not right in the u-boot configuration or u-boot >>> build. Michal and Artem (CCed) might know more. From what I recall, >>> there was nothing special required to get u-boot.bin to boot as domU >>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>> >>> Cheers, >>> >>> Stefano >>> >>> >>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>> > ....I see that some other interesting files have been produced by >>> u-boot when I have compiled it : >>> > >>> > u-boot >>> > u-boot.lds >>> > u-boot.bin >>> > u-boot.map >>> > u-boot-nodtb.bin >>> > u-boot.dtb >>> > u-boot.srec >>> > u-boot-dtb.bin >>> > u-boot.sym >>> > >>> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >>> > >>> > >>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto >>> wrote: >>> > Hello to everyone. >>> > >>> > I have compiled the needed u-boot.bin from scratch using this >>> procedure : >>> > >>> > # git clone https://github.com/u-boot/u-boot.git >>> > # cd u-boot >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig= : >>> this line generates the file .config >>> > # nano .config and I've added these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > the uboot-bin file is generated with this command : >>> > >>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>> > >>> > At this point,I took a look inside the .config file and I saw that th= e >>> parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>> > some reason,it is not accepted and this could be a problem.... >>> > >>> > These are the xen config files that I've used : >>> > >>> > nano freebsd.cfg >>> > >>> > name=3D"test" >>> > kernel=3D"u-boot.bin" >>> > extra =3D "console=3Dhvc0" >>> > memory=3D256 >>> > vcpus=3D1 >>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>> > >>> > nano start-freebsd >>> > >>> > xl create freebsd.cfg >>> > xl console freebsd >>> > >>> > This is what happens when I launch the vm : >>> > >>> > # ./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 >>> 1:cannot (re-)build domain: -3 >>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain >>> 1:Non-existent domain >>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain >>> 1:Unable to destroy guest >>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain >>> 1:Destruction of domain failed >>> > freebsd is an invalid domain identifier (rc=3D-6) >>> > >>> > >>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > So,ok,I should have said "the second u-boot" ; since the first >>> u-boot binary is the "u-boot binary located in the RO >>> > memory" of the Chromebook". Sorry for the confusion. >>> > >>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto < >>> marietto2008@gmail.com> wrote: >>> > ---> There are no specific options in u-boot devoted to FreeBSD >>> > >>> > This is an important factor. So,what about if,instead of compiling a >>> new version of u-boot on the partition 2,I will >>> > recompile the u-boot customized version created by the virtual open >>> system in 2014,that should be installed on the first >>> > partition ? It could work if there are no differences between the >>> u-boot that should boot Linux and the u-boot that >>> > should boot FreeBSD. >>> > >>> > Can you give a look at the u-boot source code created by virtual open >>> systems ? You can find it on my google drive : >>> > >>> > >>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?= usp=3Dsharing >>> > >>> > I need to understand if I can recompile it without problem so that it >>> can satisfy my needs (the ability of the file >>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano >>> Stabellini,the xen developer that suggested to me >>> > what I could do to have FreeBSD virtualized under Xen on my Arm >>> Chromebook) ; otherwise the risk is to find later >>> > problems that will make me troubles and that I will not able to fix. >>> > >>> > I gave a look at the virtual open system u-boot and I didn't see any >>> arndale_defconfig inside. So,If I have understood >>> > correctly,I should put that file inside the root of the u-boot source >>> code,let's say here : >>> > >>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>> > >>> > .checkpatch.conf README doc >>> net >>> > .git api drivers >>> onenand_ipl >>> > .gitignore arch dts >>> post >>> > COPYING board examples >>> rules.mk >>> > CREDITS boards.cfg fs >>> scripts >>> > MAINTAINERS common include >>> snapshot.commit >>> > MAKEALL config.mk lib >>> spl >>> > Makefile cros mkconfig >>> test >>> > PRESUBMIT.cfg disk nand_spl >>> tools >>> > >>> > and I should do : make and make install ? and the file I >>> need,u-boot.bin will be generated ? >>> > >>> > I didn't find any pre made configuration file inside : >>> > >>> > u-boot-vos # find . -type f -name "exynos*" >>> > >>> > ./include/exynos-fb.h >>> > ./include/configs/exynos5-common.h >>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>> > ./drivers/power/exynos-tmu.c >>> > ./drivers/power/exynos-cpufreq.c >>> > ./drivers/video/exynos-fb.c >>> > ./drivers/spi/exynos_spi.c >>> > ./board/samsung/dts/exynos5250-spring.dts >>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>> > ./board/samsung/dts/exynos5250-snow.dts >>> > ./board/samsung/dts/exynos5250-daisy.dts >>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>> > ./arch/arm/dts/exynos5250.dtsi >>> > ./arch/arm/dts/exynos-periph-id.dtsi >>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>> > >>> > u-boot-vos # find . -type f -name "arndale*" >>> > >>> > For sure I can't use a newer version of u-boot because otherwise the >>> patches needed to bypass the bootloader protections >>> > of the Arm Chromebook (such as a lot of different patches needed to >>> boot correctly Linux) will be broken ; anyway,since >>> > it works,I don't need to use an updated version of u-boot. >>> > >>> > ----> As per my experience, you have to respect these two options, >>> compiling u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > It says that I should use these parameters : >>> > >>> > CONFIG_ARMV7_NONSEC=3Dn >>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>> > >>> > These are the parameters used to configure a Linux kernel. I don't >>> understand what's the relation between the compilation >>> > of a linux kernel and u-boot. In the past I tried to recompile >>> u-boot,but I didn't have the need to set up those >>> > parameters,so I don't know how to do it (but I know how to recompile = a >>> Linux kernel). >>> > >>> > ---> I'm not sure that I'm getting you right, as I don't understand >>> what you mean under "the first u-boot". >>> > >>> > >>> > I'm talking about first u-boot because the whole procedure to boot >>> Linux on the ARM Chromebook,that's explained here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= / >>> > >>> > >>> > at some point they say : >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be booted i= n >>> hypervisor mode. Because of this relatively recent >>> > requirement (due to the introduction of the virtualization >>> extensions), up until now all booting methods would boot the >>> > kernel in the standard Supervisor mode. >>> > >>> > For the ARM Chromebook the default boot procedure doesn't allow us to >>> boot in hypervisor mode. Although the laptop's boot >>> > mechanism is based on the frequently used u-boot, the binary is >>> located in RO memory. Fortunately, a chained u-boot >>> > mechanism can be used (i.e. starting another u-boot after the >>> original). We can then enter hypervisor mode from our >>> > custom iteration of u-boot and subsequently load our kernel and >>> userspace. >>> > >>> > So,the first u-boot is the u-boot provided by virtual open >>> systems,that's able to chainload the "u-boot binary located in >>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We don'= t >>> need it if we want to boot Linux with kvm or xen >>> > enabled. >>> > >>> > >>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > I'm not an expert in the topic, I only know, that ARM has >>> divided hardware into two worlds - Secure and >>> > Not-So, strictly limiting any software, running in non-secure >>> world with access to functions and >>> > resources. >>> https://developer.arm.com/documentation/den0013/d/Security/TrustZone-ha= rdware-architecture?lang=3Den >>> >>> > >>> > I'm not sure, that I'm getting you right, as I don't understand what >>> you mean under "the first u-boot". >>> > >>> > As I understand, virtualization (HYP) is running in non-secure world( >>> https://developer.arm.com/documentation/ddi0406/c/System-Level-Architec= ture/The-System-Level-Programmers--Model/The-Virtualization-Extens >>> > ions), so my guess (only guess!!!), virtualization software has to >>> prepare (configure) HW platform in the way, >>> > that FreeBSD kernel will not lack any resources, required to configur= e >>> MPU, VA, etc. >>> > So, if you lucky to boot virtualizer, which is aware of target OS, >>> that maybe you can boot the kernel. Although, I >>> > doubt, that you need to boot 'second' u-boot to boot the kernel - >>> there is simply ubldr, which you can hook somehow >>> > from virtualizer.... >>> > >>> > Stan >>> > >>> > >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > ---> As I understand, it makes sure that u-boot keeps in secure >>> mode during boot and passes control to >>> > ubldr, which boots FreeBSD kernel, in that mode. >>> > >>> > Can you elaborate your sentence more ? I know that the bootloader >>> secure mode is bypassed by the virtual open >>> > systems u-boot. Are you saying that when the control passes to the >>> second u-boot,it will happen in secure >>> > mode,so that the bypass that happened loading the first u-boot,is >>> annulled ? If this is true,maybe can I boot >>> > FreeBSD using the virtual-open-system custom u-boot ? Is this >>> compatible with FreeBSD ? Where can I find the >>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>> > >>> > >>> > >>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki < >>> stanislav.silnicki@mailgate.us> wrote: >>> > Hi Mario, >>> > >>> > U-Boot beast is hiding in this den: >>> https://source.denx.de/u-boot/u-boot.git >>> > I took a brief look at your post and it seems to me, that >>> option CONFIG_CMO_BY_VA_ONLY is irrelevant to >>> > your target armv7 32 bit >>> > platform: >>> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/K= config?ref_type=3Dheads#L3 >>> > >>> > As for compiling the u-boot, it is a doable task, given that you >>> understand what you are doing. There >>> > are no specific options in u-boot devoted to FreeBSD. It is a boot >>> loader, whose mission to make basic >>> > hardware initialization, read you kernel file from some media into RA= M >>> and then pass it control. >>> > >>> > Basically, you can grab some defconfig, prepared for any other >>> Exynos5250 based board (say, this one: >>> > >>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defc= onfig?ref_type=3Dheads) >>> and adopt >>> > it somehow. >>> > >>> > As per my experience, you have to respect these two options, compilin= g >>> u-boot for >>> > FreeBSD: >>> https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot-mast= er/files/FreeBSD_Fragment >>> > >>> > As I understand, it makes sure, that u-boot keeps in secure mode >>> during boot and passes control to >>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lo= t >>> of surprises you may realize. >>> > >>> > Hope, this will help to progress you tasks >>> > Stan >>> > >>> > Mario Marietto wrote: >>> > >>> > >>> > Hello. >>> > >>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM >>> Chromebook. Basically there are >>> > two ways to accomplish this task : >>> > >>> > 1) to write a patch that allows the FreeBSD kernel to boot as a >>> zImage file. This could be >>> > accomplished applying this patch to a specific file that's on >>> the source code of FreeBSD : >>> > >>> > >>> > >>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139147271703= 5f986c979edef0c9 >>> > >>> > >>> > This patch was written by Julien Grall a lot of time ago and no= w >>> it does not work anymore. >>> > This is the reason : >>> > >>> > >>> > 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. >>> And I'm not able to fix it. >>> > >>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer= : >>> > >>> > >>> > I was trying to explain why and how Julien's patch works so tha= t >>> you could be the one >>> > to re-do something similar or fix the patch on the FreeBSD >>> kernel that you are >>> > working with. I am happy to help review and write patches but I >>> don't work with the >>> > FreeBSD kernel so I wouldn't be able to help you quickly. >>> However, I might have a >>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? >>> Because U-Boot >>> > definitely boots as Xen on ARM guest firmware/bootloader. You >>> should be able to build >>> > U-Boot and use the U-Boot binary as Xen guest kernel, then >>> U-Boot could load FreeBSD >>> > from disk or network and start it. For instance as domU config >>> file: >>> > >>> > kernel=3D"/home/petalinux/u-boot.bin" >>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>> > >>> > I know it is important to build u-boot with the following confi= g >>> to make it work on >>> > Xen. >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > >>> > This option seems more doable to me according to my knowledge. But I >>> need to understand how to do >>> > it. >>> > >>> > Well,let's say that on the ARM Chromebook I'm forced to use and >>> install a customized version of >>> > u-boot,created by virtual open systems,because it is the only one tha= t >>> allows bypassing its >>> > bootloader protection. You can find more information here : >>> > >>> > >>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook= /?vos=3Dtech >>> > >>> > This is the relevant section to read : >>> > >>> > >>> > Bootloader : >>> > >>> > If you wish to skip this chapter you can download a pre-compile= d >>> binary of the >>> > bootloader: >>> > >>> > >>> > $ wget >>> > >>> http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv= _u-boot-snow.kpart >>> > >>> > >>> > To be able to run KVM on ARM platforms, the kernel has to be >>> booted in hypervisor >>> > mode. Because of this relatively recent requirement (due to the >>> introduction of the >>> > virtualization extensions), up until now all booting methods >>> would boot the kernel in >>> > the standard Supervisor mode. For the ARM Chromebook the defaul= t >>> boot procedure >>> > doesn't allow us to boot in hypervisor mode. Although the >>> laptop's boot mechanism is >>> > based on the frequently used u-boot, the binary is located in R= O >>> memory. Fortunately, >>> > a chained u-boot mechanism can be used (i.e. starting another >>> u-boot after the >>> > original). We can then enter hypervisor mode from our custom >>> iteration of u-boot and >>> > subsequently load our kernel and userspace. >>> > >>> > Checkout the needed u-boot code : >>> > >>> > >>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd >>> u-boot$ >>> > ./scripts/build.sh >>> > >>> > >>> > If successful, a message about how to copy the bootloader on th= e >>> USB flash disk or SD >>> > card will appear. We will use it later when preparing the boot >>> medium to start our >>> > system. If you have followed the Setting up the boot medium >>> chapter and you have a >>> > prepared boot device, then you can update u-boot by running : >>> > >>> > >>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>> > >>> > >>> > >>> > so,the needed u-boot that we must use should be installed on the firs= t >>> partition of the sd card. >>> > >>> > There is another relevant section to read : >>> > >>> > >>> > Setting up the boot medium >>> > >>> > Now it is time to copy all the relevant files that we created i= n >>> the previous >>> > chapters,and use them to boot Chromebook with a different kerne= l >>> and OS. In all these >>> > examples the device /dev/sdX is used. Take extra care to change >>> the examples to the >>> > device that you have attached. Insert the boot medium on your >>> workstation and >>> > carefully execute the following step. First we need to properly >>> format the boot >>> > medium. >>> > >>> > In the uboot source directory : >>> > >>> > >>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>> > >>> > >>> > This will erase all data and create 4 partitions in the medium, >>> along with copying >>> > the u-boot binary to the first partition: >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > With u-boot being copied, next is the kernel image and DTB file= . >>> From the kernel >>> > source execute : >>> > >>> > >>> > $ mkdir ../mnt/ >>> > $ sudo mount /dev/sdX3 ../mnt/ >>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>> > $ sudo umount /dev/sdX3 >>> > >>> > >>> > Finally, we have to copy the Ubuntu userspace filesystem that w= e >>> created earlier: >>> > >>> > >>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo >>> umount /dev/sdX4 >>> > >>> > >>> > >>> > Now,my idea is to chainload the already chain loaded u-boot created b= y >>> V.O.S to the new u-boot >>> > that we need for booting FreeBSD and that can be installed in the >>> partition n.2,as shown in this >>> > scheme,because it is not used : >>> > >>> > >>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32 >>> bit,compatible with FreeBSD on >>> > this partition) >>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and >>> exynos5250-snow.dtb) >>> > Partition 4 =3D EXT4 partition for userspace files >>> > >>> > >>> > Take in consideration that default boot string is hardcoded here,in >>> the snow.h file of the custom >>> > u-boot created by VOS : >>> > >>> > >>> > >>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs= /snow.h#L101 >>> > >>> > >>> > and it needs to be recompiled because it should point to the partitio= n >>> n.2,where I will install >>> > the u-boot files as explained here : >>> > >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > >>> > I have some questions to ask before I start working on this. >>> > >>> > 1) The xen developer said : >>> > >>> > >>> > You should be able to build U-Boot and use the U-Boot binary as >>> Xen guest kernel... >>> > >>> > >>> > >>> > where is the u-boot binary,according to this document ? >>> > >>> > https://wiki.freebsd.org/arm/Chromebook >>> > >>> > I don't see it. >>> > >>> > >>> > 2) where is the source code of the file that I can get here : >>> > >>> > >>> http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/= nv_uboot-snow-simplefb.kpart.bz2 >>> > >>> > I need the source code if I want to recompile u-boot so that it can >>> point to the partition 4. >>> > >>> > Maybe it can be found on this link : >>> > >>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>> > >>> > but it can't be opened.... >>> > >>> > >>> > 3) in this specific scenario the source code of u-boot should run on >>> arm 32 bit,not on arm >>> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that's >>> powered by a Samsung Exynos >>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>> > >>> > >>> > 4) I'm not sure if I can chainload the customized u-boot created by >>> V.O.S that should be >>> > installed on the first partition with the u-boot tailored for booting >>> FreeBSD that should be >>> > installed on the partition 2.... >>> > >>> > >>> > 5) the xen developer said that u-boot should be compiled enabling thi= s >>> option : >>> > >>> > >>> > Code: >>> > >>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>> > >>> > >>> > Well,can you provide some good source that can help me to understand >>> how I can recompile u-boot >>> > for FreeBSD ? thanks. >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >>> > >>> > -- >>> > Mario. >>> > >>> > >> >> >> >> -- >> Mario. >> > --=20 Mario. --000000000000e06319060d319c29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've added = this parameter to bootxen.source :

= guest_loglvl=3Dall
<= br>
bootxen.source :=

mmc dev 1
ext2load mmc 1:3 0x42000000 zImage-5.4.261-iommu-dma-on-xen
ext2load mmc 1:3 0x51000000 xen-4.17-armhf-armmp-0x51004000.ub
ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb
fdt addr 0x5ffec000
fdt resize 1024
fdt set /chosen \#address-cells <0x2>
fdt set /chosen \#size-cells <0x2>
fdt set /chosen xen,xen-bootargs "console=3Ddtuart dtuart=3Dserial= 0 dom0_mem=3D1152M dom0_max_vcpus=3D2 bootscrub=3D0 vwfi=3Dnative guest_log= lvl=3Dall"
fdt mknod /chosen dom0
fdt set /chosen/dom0 compatible =C2=A0"xen,linux-zimage" &quo= t;xen,multiboot-module" "multiboot,module"
fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x49F9A8 >
fdt set /chosen xen,dom0-bootargs "console=3Dtty1 root=3D/dev/mmcb= lk1p4 rw rootwait clk_ignore_unused --no-log"
bootm 0x51000000 - 0x5ffec000


but when I try to boot FreeBSD I don&#= 39;t get more informations than usual :

root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen= # ./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 fail= ed
libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:cann= ot (re-)build domain: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-ex= istent domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Una= ble to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destructi= on of domain failed
freebsd is an invalid= domain identifier (rc=3D-6)

Are you aware about a new= parameter that I can use to have more detailed debug information ?

On Wed, Dec 20, 2023 at 5:52=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
I&#= 39;d think you'd need the right virtualization loader. I'm not enti= rely sure the u-boot.bin you've been creating is for a dom-u..=C2=A0
If I misunderstood, then the below isn't good advice. Chain boo= ting the u-boot, the first u-boot initializes things so you want
= to start with stage after the SPL. But the different error messages suggest= that it's trying to reboot with kexec, which
isn't suppo= rted on armv7 at the moment.

If you could boot= in kvm, I think that the following would work....=C2=A0 Though I'm not= entirely sure how to
specify the two .fd files in your setup. Th= e use of qemu is to have an easy env to debug things... I don't
have a chromebook to try...

My first instin= ct would be to try qemu on x86 (this is the first step of many to get to yo= ur destination).

If you could boot the GENERIC_SD = image that we produce using qemu + edk2-arm-code.fd that would
be= a huge first step. This will give you the boot loader, I believe, to boot = in the VM that you need better
than going via the u-boot route. S= ince you are booting in a virtualized environment, I think it wouldn't<= /div>
matter which one :).

So, I did the follo= wing to boot the virtualized armv7 FreeBSD environment, following a post on= the forums I found and knew to have the right recipe:

1. pkg ins= tall qemu
2. mkdir qemu-armv7-env
3. cd qemu-armv7-env<= /div>
5. xz -d -T = 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz
6. dd if=3D/dev= /zero of=3Dpflash0.img bs=3D1m count=3D64
7. dd if=3D/dev/zero of=3Dpfla= sh1.img bs=3D1m count=3D64
8. dd if=3D/usr/local/share/qemu/edk2-arm-cod= e.fd of=3Dpflash0.img conv=3Dnotrunc
9. dd if=3D/usr/local/share/qemu/ed= k2-arm-vars.fd of=3Dpflash1.img conv=3Dnotrunc
10. cat > start= -freebsd-arm.sh
#!/bin/sh
qemu-system-arm \
=C2=A0 -M virt = \
=C2=A0 -m 1024 \
=C2=A0 -drive file=3Dpflash0.img,format=3Draw,if= =3Dpflash,readonly=3Don \
=C2=A0 -drive file=3Dpflash1.img,format=3Draw,= if=3Dpflash \
=C2=A0 -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrou= gh \
=C2=A0 -nographic \
=C2=A0 -serial mon:stdio
^D
<= div>11. chmod +x start-freebsd-arm.sh
12. ./start-freebsd-arm.sh = FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD

But I hi= t a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14.0:

Starting devd.
Starting dhclient.
DHCPDISCOVER on v= tnet0 to 255.255.255.255 port 67 interval 7
Fatal kernel mode data abort= : 'Alignment Fault' on read
trapframe: 0xc4b36a60
FSR=3D00000= 001, FAR=3Ddd96701a, spsr=3D20000013
r0 =3D00000000, r1 =3D00000001, r2 = =3D00000001, r3 =3Dc4b36b4c
r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd9670= 2e, r7 =3D0000022c
r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11= =3Dc4b36b90
r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a97= 50

panic: Fatal abort
cpuid =3D 0
time =3D 1680843057
KDB: = stack backtrace:
#0 0xc035786c at kdb_backtrace+0x48
#1 0xc02fdd20 at= vpanic+0x140
#2 0xc02fdbe0 at vpanic+0
#3 0xc06304ac at abort_align+= 0
#4 0xc063052c at abort_align+0x80
#5 0xc063017c at abort_handler+0x= 480
#6 0xc060f480 at exception_exit+0
#7 0xc04a9750 at udp_input+0x28= 8
#8 0xc0473f54 at ip_input+0x1e0
#9 0xc04447c0 at netisr_dispatch_sr= c+0xf8
#10 0xc043bf2c at ether_demux+0x1a4
#11 0xc043d5e4 at ether_nh= _input+0x480
#12 0xc04447c0 at netisr_dispatch_src+0xf8
#13 0xc043c40= 4 at ether_input+0x50
#14 0xc01c0838 at vtnet_rx_vq_process+0x880
#15= 0xc01b70d0 at vtpci_intx_intr+0xac
#16 0xc02b87f0 at ithread_loop+0x2ec=
#17 0xc02b465c at fork_exit+0xc0
Uptime: 19s

I don't know if this is a problem with qemu or FreeBSD's kernel..= .

Warner

On Tue, Dec 19, 2023 at 3:25=E2= =80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
I've asked som= e help on the channel #arm on Reddit and someone replied :


Maybe his answer can be useful to understand= why it does not work.

On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM St= efano Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

I am not sure about booting FreeBSD, but I am certain that u-boot works
fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config
file:

name=3D"test"
kernel=3D"u-boot.bin"
extra =3D "console=3Dhvc0"
memory=3D256
vcpus=3D1
disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]

I don't know for sure if you can boot FreeBSD but you should definitely=
be able to see the u-boot command line prompt. The fact that you are
getting this message:

xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: I= nvalid kernel

Means that something is not right in the u-boot configuration or u-boot
build. Michal and Artem (CCed) might know more. From what I recall,
there was nothing special required to get u-boot.bin to boot as domU
kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.

Cheers,

Stefano


On Tue, 19 Dec 2023, Mario Marietto wrote:
> ....I see that some other interesting files have been produced by u-bo= ot when I have compiled it :
>
> u-boot
> u-boot.lds
> u-boot.bin
> u-boot.map
> u-boot-nodtb.bin
> u-boot.dtb
> u-boot.srec
> u-boot-dtb.bin
> u-boot.sym
>
> So,maybe I should use a different u-boot* file for booting FreeBSD ? >
>
> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello to everyone.
>
> I have compiled the needed u-boot.bin from scratch using this procedur= e :
>
> # git clone https://github.com/u-boot/u-boot.git
> # cd u-boot
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfig = : this line generates the file .config
> # nano .config and I've added these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> the uboot-bin file is generated with this command :
>
> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make
>
> At this point,I took a look inside the .config file and I saw that the= parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for
> some reason,it is not accepted and this could be a problem....
>
> These are the xen config files that I've used :
>
> nano freebsd.cfg
>
> name=3D"test"
> kernel=3D"u-boot.bin"
> extra =3D "console=3Dhvc0"
> memory=3D256
> vcpus=3D1
> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]
>
> nano start-freebsd
>
> xl create freebsd.cfg
> xl console freebsd
>
> This is what happens when I launch the vm :
>
> # ./start-freebsd
> =C2=A0
> Parsing config from freebsd.cfg
> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel
> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led
> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3
> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain
> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest
> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed
> freebsd is an invalid domain identifier (rc=3D-6)
>
>
> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So,ok,I should have said "the second u-= boot" ; since the first u-boot binary is the "u-boot binary locat= ed in the RO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0memory" of the Chromebook". Sorry = for the confusion.
>
> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> There are no specific options in u-b= oot devoted to FreeBSD
>
> This is an important factor. So,what about if,instead of compiling a n= ew version of u-boot on the partition 2,I will
> recompile the u-boot customized version created by the virtual open sy= stem in 2014,that should be installed on the first
> partition ? It could work if there are no differences between the u-bo= ot that should boot Linux and the u-boot that
> should boot FreeBSD.
>
> Can you give a look at the u-boot source code created by virtual open = systems ? You can find it on my google drive :
>
> https://dri= ve.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?usp=3Dsharing
>
> I need to understand if I can recompile it without problem so that it = can satisfy my needs (the ability of the file
> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano S= tabellini,the xen developer that suggested to me
> what I could do to have FreeBSD virtualized under Xen on my Arm Chrome= book) ; otherwise the risk is to find later
> problems that will make me troubles and that I will not able to fix. >
> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood
> correctly,I should put that file inside the root of the u-boot source = code,let's say here :
>
> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls > =C2=A0
> .checkpatch.conf =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0README =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0doc =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= net
> .git =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0api =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0drivers =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0onenand_ipl
> .gitignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0arch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dts =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0post
> COPYING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0board =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= examples =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0rules.mk
> CREDITS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0boards.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fs =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0scripts
> MAINTAINERS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0common =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0snapshot.commit
> MAKEALL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0config.mk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0spl
> Makefile =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cros =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= mkconfig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0test
> PRESUBMIT.cfg =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0disk =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nand_spl =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= tools
>
> and I should do : make and make install ? and the file I need,u-boot.b= in will be generated ?=C2=A0
>
> I didn't find any pre made configuration file inside :
>
> u-boot-vos # find . -type f -name "exynos*"=C2=A0
>
> ./include/exynos-fb.h
> ./include/configs/exynos5-common.h
> ./doc/device-tree-bindings/spi/exynos-spi.txt
> ./doc/device-tree-bindings/usb/exynos-usb.txt
> ./drivers/power/exynos-tmu.c
> ./drivers/power/exynos-cpufreq.c
> ./drivers/video/exynos-fb.c
> ./drivers/spi/exynos_spi.c
> ./board/samsung/dts/exynos5250-spring.dts
> ./board/samsung/dts/exynos5250-smdk5250.dts
> ./board/samsung/dts/exynos5250-snow.dts
> ./board/samsung/dts/exynos5250-daisy.dts
> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h
> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h
> ./arch/arm/dts/exynos5250.dtsi
> ./arch/arm/dts/exynos-periph-id.dtsi
> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c=C2=A0
>
> u-boot-vos # find . -type f -name "arndale*"
>
> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections
> of the Arm Chromebook (such as a lot of different patches needed to bo= ot correctly Linux) will be broken ; anyway,since
> it works,I don't need to use an updated version of u-boot.
>
> ----> As per my experience, you have to respect these two options, = compiling u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> It says that I should use these parameters :
>
> CONFIG_ARMV7_NONSEC=3Dn
> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy
>
> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation
> of a linux kernel and u-boot. In the past I tried to recompile u-boot,= but I didn't have the need to set up those
> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel).
>
> ---> I'm not sure that I'm getting you right, as I don'= t understand what you mean under "the first u-boot".
>
>
> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here :
>
> http://www.virtualopens= ystems.com/en/solutions/guides/kvm-on-chromebook/
>
>
> at some point they say :
>
>
> To be able to run KVM on ARM platforms, the kernel has to be booted in= hypervisor mode. Because of this relatively recent
> requirement (due to the introduction of the virtualization extensions)= , up until now all booting methods would boot the
> kernel in the standard Supervisor mode.
>
> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot
> mechanism is based on the frequently used u-boot, the binary is locate= d in RO memory. Fortunately, a chained u-boot
> mechanism can be used (i.e. starting another u-boot after the original= ). We can then enter hypervisor mode from our
> custom iteration of u-boot and subsequently load our kernel and usersp= ace.
>
> So,the first u-boot is the u-boot provided by virtual open systems,tha= t's able to chainload the "u-boot binary located in
> RO memory" , that does not boot Chrome OS in hypervisor mode. We = don't need it if we want to boot Linux with kvm or xen
> enabled.
>
>
> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <stanislav.siln= icki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not an expert in the topic, I only k= now, that ARM has divided hardware into two worlds - Secure and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not-So, strictly limiting any software, runn= ing in non-secure world with access to functions and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0resources.=C2=A0https://developer.arm.com/doc= umentation/den0013/d/Security/TrustZone-hardware-architecture?lang=3Den=
>
> I'm not sure, that I'm getting you right, as I don't under= stand what you mean under "the first u-boot".
>
> As I understand, virtualization (HYP) is running in non-secure world(<= a href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Ar= chitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" r= el=3D"noreferrer" target=3D"_blank">https://developer.arm.com/documentation= /ddi0406/c/System-Level-Architecture/The-System-Level-Programmers--Model/Th= e-Virtualization-Extens
> ions), so my guess (only guess!!!), virtualization software has to pre= pare (configure) HW platform in the way,
> that FreeBSD kernel will not lack any resources, required to configure= MPU, VA, etc.
> So, if you lucky to boot virtualizer, which is aware of target OS, tha= t maybe you can boot the kernel. Although, I
> doubt, that you need to boot 'second' u-boot to boot the kerne= l - there is simply ubldr, which you can hook somehow
> from virtualizer....
>
> Stan
>
>
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0---> As I understand, it makes sure that = u-boot keeps in secure mode during boot and passes control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ubldr, which boots FreeBSD kernel, in that m= ode.
>
> Can you elaborate your sentence more ? I know that the bootloader secu= re mode is bypassed by the virtual open
> systems u-boot. Are you saying that when the control passes to the sec= ond u-boot,it will happen in secure
> mode,so that the bypass that happened loading the first u-boot,is annu= lled ? If this is true,maybe can I boot
> FreeBSD using the virtual-open-system custom u-boot ? Is this compatib= le with FreeBSD ? Where can I find the
> u-boot.bin that the xen developer talked about ? thanks bro'.
>
>
>
> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <stanislav.sil= nicki@mailgate.us> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Mario,
>
> U-Boot=C2=A0 beast is hiding in this den: https://sourc= e.denx.de/u-boot/u-boot.git
> I took a brief look at your post and it seems to me, that option=C2=A0= CONFIG_CMO_BY_VA_ONLY=C2=A0is irrelevant to
> your target armv7 32 bit
> platform:=C2=A0https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3
>
> As for compiling the u-boot, it is a doable task, given that you under= stand what you are doing. There
> are no specific options in u-boot devoted to FreeBSD. It is a boot loa= der, whose mission to make basic
> hardware initialization, read you kernel file from some media into RAM= and then pass it control.
>
> Basically, you can grab some defconfig, prepared for any other Exynos5= 250 based board=C2=A0 (say, this one:
> ht= tps://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defconfig?= ref_type=3Dheads) and adopt
> it somehow.
>
> As per my experience, you have to respect these two options, compiling= u-boot for
> FreeBSD:=C2=A0https://github.com/freebsd/freebsd-ports/blob/main/sysutils/= u-boot-master/files/FreeBSD_Fragment
>
> As I understand, it makes sure, that u-boot keeps in secure mode durin= g boot and passes control to
> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a lot= of surprises you may realize.
>
> Hope, this will help to progress you tasks
> Stan
>
> Mario Marietto wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm trying to boot FreeBSD for arm32 bit= as DomU on my ARM Chromebook. Basically there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two ways to accomplish this task :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01) to write a patch that allows the FreeBSD = kernel to boot as a zImage file. This could be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accomplished applying this patch to a specif= ic file that's on the source code of FreeBSD :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98= cc1391472717035f986c979edef0c9
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This patch was written by Julien Grall a lot= of time ago and now it does not work anymore.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is the reason :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It appears FreeBSD-CURR= ENT removed the last step converting the kernel file to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kernel.bin. The patch c= an be readily rebased, but without kernel.bin that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't do too much=
>
>
>
> So,without a rebase of that patch the first option is not applicable. = And I'm not able to fix it.
>
> 2) booting FreeBSD using U-Boot,as explained to me by a xen developer = :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I was trying to explain why and how Julien&#= 39;s patch works so that you could be the one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to re-do something similar or fix the patch = on the FreeBSD kernel that you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0working with. I am happy to help review and = write patches but I don't work with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggestion. Do you know if FreeBSD can be bo= oted by U-Boot ? Because U-Boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitely boots as Xen on ARM guest firmwar= e/bootloader. You should be able to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0U-Boot and use the U-Boot binary as Xen gues= t kernel, then U-Boot could load FreeBSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from disk or network and start it. For insta= nce as domU config file:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0kernel=3D"/home/petalinux/u-boot.bin&qu= ot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0disk =3D [ '/home/petalinux/test.img,raw= ,xvda' ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I know it is important to build u-boot with = the following config to make it work on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Xen.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
>
> This option seems more doable to me according to my knowledge. But I n= eed to understand how to do
> it.
>
> Well,let's say that on the ARM Chromebook I'm forced to use an= d install a customized version of
> u-boot,created by virtual open systems,because it is the only one that= allows bypassing its
> bootloader protection. You can find more information here :
>
> http://www.v= irtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?vos=3Dtech=
>
> This is the relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Bootloader :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you wish to skip this chapter you can dow= nload a pre-compiled binary of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bootloader:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ wget
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.virtualopensystems.com/downloads/guides/kvm_= on_chromebook/nv_u-boot-snow.kpart
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be able to run KVM on ARM platforms, the = kernel has to be booted in hypervisor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mode. Because of this relatively recent requ= irement (due to the introduction of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtualization extensions), up until now all= booting methods would boot the kernel in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standard Supervisor mode. For the ARM Ch= romebook the default boot procedure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't allow us to boot in hypervisor m= ode. Although the laptop's boot mechanism is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the frequently used u-boot, the bin= ary is located in RO memory. Fortunately,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a chained u-boot mechanism can be used (i.e.= starting another u-boot after the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0original). We can then enter hypervisor mode= from our custom iteration of u-boot and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently load our kernel and userspace.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Checkout the needed u-boot code :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ git clone git://git= hub.com/virtualopensystems/u-boot.git$ cd u-boot$
>=C2=A0 =C2=A0 =C2=A0 =C2=A0./scripts/build.sh
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If successful, a message about how to copy t= he bootloader on the USB flash disk or SD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0card will appear. We will use it later when = preparing the boot medium to start our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system. If you have followed the Setting up = the boot medium chapter and you have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0prepared boot device, then you can update u-= boot by running :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev= /sdX1
>
>
>
> so,the needed u-boot that we must use should be installed on the first= partition of the sd card.
>
> There is another relevant section to read :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Setting up the boot medium
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Now it is time to copy all the relevant file= s that we created in the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0chapters,and use them to boot Chromebook wit= h a different kernel and OS. In all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0examples the device /dev/sdX is used. Take e= xtra care to change the examples to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that you have attached. Insert the bo= ot medium on your workstation and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0carefully execute the following step. First = we need to properly format the boot
>=C2=A0 =C2=A0 =C2=A0 =C2=A0medium.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the uboot source directory :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo ./scripts/sdcard.sh /dev/sdX
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This will erase all data and create 4 partit= ions in the medium, along with copying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the u-boot binary to the first partition: >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 1 =3D ChromeOS signed binary (V.O.= S chained u-boot)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 2 =3D not used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 3 =3D EXT2 partition for u-boot fi= les (uImage and exynos5250-snow.dtb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Partition 4 =3D EXT4 partition for userspace= files
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0With u-boot being copied, next is the kernel= image and DTB file. From the kernel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0source execute :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ mkdir ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX3 ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/uImage ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo cp arch/arm/boot/dts/exynos5250-snow.= dtb ../mnt/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo umount /dev/sdX3
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, we have to copy the Ubuntu userspac= e filesystem that we created earlier:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0$ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./pr= ecise/* mnt/$ sudo umount /dev/sdX4
>
>
>
> Now,my idea is to chainload the already chain loaded u-boot created by= V.O.S to the new u-boot
> that we need for booting FreeBSD and that can be installed in the part= ition n.2,as shown in this
> scheme,because it is not used :
>
>
> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)
> Partition 2 =3D not used (maybe we can install the u-boot for arm 32 b= it,compatible with FreeBSD on
> this partition)
> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos5250= -snow.dtb)
> Partition 4 =3D EXT4 partition for userspace files
>
>
> Take in consideration that default boot string is hardcoded here,in th= e snow.h file of the custom
> u-boot created by VOS :
>
>
> https://gith= ub.com/virtualopensyste...18a39b6c177dff58a/include/configs/snow.h#L101=
>
>
> and it needs to be recompiled because it should point to the partition= n.2,where I will install
> the u-boot files as explained here :
>
>
> https://wiki.freebsd.org/arm/Chromebook
>
>
> I have some questions to ask before I start working on this.
>
> 1) The xen developer said :
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You should be able to build U-Boot and use t= he U-Boot binary as Xen guest kernel...
>
>
>
> where is the u-boot binary,according to this document ?
>
> https://wiki.freebsd.org/arm/Chromebook
>
> I don't see it.
>
>
> 2) where is the source code of the file that I can get here :
>
> http://commondatastorage.googleapis.com/chromeos-localmirror/distfi= les/nv_uboot-snow-simplefb.kpart.bz2
>
> I need the source code if I want to recompile u-boot so that it can po= int to the partition 4.
>
> Maybe it can be found on this link :
>
> http://linux-exynos.org/dist/chromebook/nv_ubo= ot/
>
> but it can't be opened....
>
>
> 3) in this specific scenario the source code of u-boot should run on a= rm 32 bit,not on arm
> 64,because I have the Samsung Chromebook "SNOW" model XE303C= 12,that's powered by a Samsung Exynos
> 5250 (ARMv7 32 bit Cortex A15) Soc.
>
>
> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be
> installed on the first partition with the u-boot tailored for booting = FreeBSD that should be
> installed on the partition 2....
>
>
> 5) the xen developer said that u-boot should be compiled enabling this= option :
>
>
> Code:
>
> CONFIG_CMO_BY_VA_ONLY=3Dy
>
>
> Well,can you provide some good source that can help me to understand h= ow I can recompile u-boot
> for FreeBSD ? thanks.
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>
>
> --
> Mario.
>
>


--
Mario.


--
Mario.
--000000000000e06319060d319c29-- From nobody Sat Dec 23 23:27:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyL284rddz558WL for ; Sat, 23 Dec 2023 23:28:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyL274dDhz3CbT for ; Sat, 23 Dec 2023 23:28:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SOUwfCl9; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703374093; bh=VI2JFgjxZpzWgeuuLZFLAZDRD24fNHoRG4rvwyFAuBY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SOUwfCl9+K8NIoigc4v5nAE9lAKNsEhOhS0MuygHTJfySCvIAUYmVfla1FrZBRi1MFCjAHxhog84o9m5Tfp9b0jSKSWmZe+1GGTaBXeDFXsLPXUvFMosjuLNG9A+ZEo847osCJXcyGOwlAzmtUeynVsO9VRLztdLhvZdbaBGDIEx9gsB48Z0CpiqaUxGz+Fi/oMiJcqmNQOVFQXyy3aqMe1R7WJgzua7Yvf6tIk0cGXP9myFqwWiBiWSoZmsfKwPPYy4wD+Li0RqZp5cEB4Uxpcqrb2/F+FiptQK4E8aRmmfEeqDN92xQhQ9ABNzzQR7pp5+xJKfLYmMIodyfuzfCA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703374093; bh=SsJKK3xUs7cz4pKMIjypl/2qHQiBRRgRNQIlqJ33l9b=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cSz9w/oHjnDQ89O36AvfBRAIKu4QeQtj/Tf+Yv3AJUbj4BR0H6SebNzjLmWBvzaxh26QoJczHzugXjRacar5Do/s9ZZGTPlqdMSExXaPRMFNMp1FZFrhASSqbbjd54heTuCsmuKfg854xEq8Y9rHoAgVsmr3xANK4PqzlUcICzFr6sNkRrkSCS+bNyW3XIZ24TQ9/ep4fR6okh65ItGxEC9vmzotWJBgYMDHHiEtD2lg41DtLbJbEnJPV+TmTf+IT+5m/5itsgIvp7V6UtpHi8Ax2+0PpI9qUHpMaKLhg7NTEOm+up+B3x5UDzx1h1R2QULGMh2sY8CRQAl2e+3fGA== X-YMail-OSG: 093yTdsVM1kOhcRVDqpyx5nr2cka4uvDqgUFV_epbrvU7EEhI9F2Xmc_vJnXhIj B.vO.G7k6EdlYVNd1LDp9avuXWHXIY9QsbTl26f5fOR8hRUSjKlyAnZmnA3Ow_b91ykax8L9EK1G 14sW_wYMHKfNKZsBuPR_VMrd_mD.qEY52ow.E0Rfal2nZ5c1TRES_ydwnHDmTC9lFpBnI_vuhFCE ZAGbNjgJen7qOJ9Pj01P72vOX52alD8r8wcc5bPkiny0xl.aMl7V7Nw96bpmHrNSdC3OGbp6iBck c3nSD03ggSRBZv930uKuXJIJ9XJNaluJha1Ayevce7Op8A7WEo9DJLK2uSByu1HLnRzWUbVrdx7N BctI9Nfrf0E_sqdsSaY_KdseFeav5TkudjgO0EeuCQwZEiP7iNwSTZBsA1NDeTDq1A6Rmx_FmN52 qZ4KnmgY2yGRwKo2jJENyGw6.D.Xobd1XxD8XQHF5r7lPu.K1f2yVf7O5PJ_M1osF8TkozqQCLKS JHk0KrE35V96UVb_AkyL0UuTpJ.7ljQhL3d9HzVMBazgjgWynVHLEicl1Mgymmt.m15sFUwqOqhR _t8cJRNrTFZhyPzW56NRx.cUaJ5jYPufE9Wk5VPN89gb3LtxS5SNvUHqgJZmINoCptZS1b2oHzqA a8jEDRLMJeBRvi89LeBUIKWPReHY8IXYMgdtb2XR06bJ8kobOgh2DfGkpKqTcCs4jE4Mk7JZjhgR dyhSMo5JQfXY9UGVCsM.AYfbwTtcZl04vTQaMuGet7QNYWVAiVMkUchBPKs5gcmRQPmWeF_yrtPx wCokASJO2JzOnWVuV3XlkypIJ4Jb_c5w3pR7Kh9dVRRjpU5sXuevPtT4EUXMaH1DQ_Dnn37V1Dco p.NXQ9aXee9YZv4evxaDRJk7dUg.6kVbFa39r6i7D0wIgwnq6suGXyhPK3qDwUQvHjLEuHtsGJ2M j_asVVCWGsK3eiJXhkP2w7e99LucuodBckzDHRcYvOuM8o6i3Az0LKBFsUXFltUOeS.4gCOP3mrW 9EvLAc60ssJZP2zuJNSiOSgZKhuHBrI9n5t41Fp5KZSbesLYjcrGc20LXiFzl97gtraZPNfEUUeH wtx1PMJZfsf985uREEaYRfX_5rNbeFum_cj6yAqSeM696iFscEjJEDO4xrnSJpDmbqRIYRSUKIHE h5_R7Lea9WJsA3UcEnVcSF9fWDYscJF4hXHN5U4uV8M8umyPgb97iY97bXg49jwLWuFyY0DP6P4d P3pXVTfjCqhoTOk4d.x6xkSfqwgOqxu0vyqmYygqdXrC22zISXz1unBSzFWZlZzQCMxa9UhAciaY A6kYrxH0n0dhLZen4MrWs4kD5dFv6ub2uMC.pJcXct1JYBdt_0A7p9r81fjR2GSHamuNCfZgGI2R jwsyfgEfDQrs1uxtyw7T4EIn3QNrjurqQWBV_LGdZUCqkpL.D3RFenaliJnTY92X7H7QRCpEICRI MlYSzYpMOZE1R_I16IaULbPt1QD9CgblOt2SWMz123wVoceW5hUNxdG91ODAfIE3JZRb4JpQy2zy M8VkWqRK0VAO.hRzz9m.LIaeB_iuxHiUdKbKwnmdDGWo_ehxfhUpyMtBsQNrCte2QMFMFBTdfpxB X9jzj3fXWPj9m_gdwHlDSxIchgQw2WRGwWUJTSzjN5mE1p5y0v6iVeDP_nHNTj_ro3hXDP6cgqiN 8tdUW5VkG.wDjZXuQ.W0RDCS1KdNwjwnsY3LWu.q4WE8XIlqIzdwB14mLs2.DcSOLby_o9ehevxx Kt6_KCwPmOudgGGXfmcXJtpxFOwFFsiNq_IAjckI1LoUyYkM3ndwpb4BkaT8oycwE8JWsb4RpCCy TX_zTw0AdR0UAz6qpJD9IucVOZ9isgHPg.SE8fwS7deTOOL2w8FY0ljbZ52KfN8KvzjUWA7H8KfB DUtHPka9HN0dwVNk21TBIDENLKnML99jiq4gelq_.F8vcxgDHEobS5q3k1c7N.94w3LF_g0Ys8GI .p3hw4B0w9.oky38fjTH_xcTi0WMmVRw6UWBeYERGOhXHez4Hbs6_bPGOQwbFH.STaYp.dHzVhTx 3QNI7IXdWx01wD34DOUNqqavkm18bqu6TtirR72bEXmK.YffzMnMSmURQHc1ohVfnDyVFL8t1Qgm 8uFfPpmOIxe2jhS6Rl_iFYEcuyHt7MpIDSuzCpb9k3uEWzX5Oir804I4SKc_I2L3guulhxoCnMk0 mbhtmQaFKI0c_yn9a4.X9aDzjd12UGhvcXY1oaUso_q8W3XHPxNmA6.s5O.Dll9usvsZtXQqsnlS 5 X-Sonic-MF: X-Sonic-ID: 36a94a90-67d1-4fd3-b9d4-15df5213e230 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Dec 2023 23:28:13 +0000 Received: by hermes--production-gq1-6949d6d8f9-7dnvp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eff594264e6ab2729fc70351e78985eb; Sat, 23 Dec 2023 23:28:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB From: Mark Millard In-Reply-To: Date: Sat, 23 Dec 2023 15:27:59 -0800 Cc: Steve Bernacki , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8CBB5E92-942E-43FA-B188-8288480B8D95@yahoo.com> References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> <2E1B887B-EB3C-4F47-A6EE-8256149F7C84@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SyL274dDhz3CbT X-Spamd-Bar: --- On Dec 22, 2023, at 17:28, Mark Millard wrote: > On Dec 22, 2023, at 14:48, Mike Karels wrote: >=20 > On 22 Dec 2023, at 16:14, Steve Bernacki wrote: >>=20 >>> Hi Mike, >>>=20 >>> Indeed, I'm getting a lot of retransmits: >>>=20 >>> [ 5] local 172.16.200.2 port 55551 connected to 172.16.200.182 port = 5201 >>> [ ID] Interval Transfer Bitrate Retr Cwnd >>> [ 5] 0.00-1.00 sec 36.2 MBytes 304 Mbits/sec 60 9.98 = KBytes >>> [ 5] 1.00-2.00 sec 35.7 MBytes 300 Mbits/sec 143 111 = KBytes >>> [ 5] 2.00-3.00 sec 34.9 MBytes 293 Mbits/sec 141 7.13 = KBytes >>> [ 5] 3.00-4.00 sec 33.9 MBytes 284 Mbits/sec 198 99.5 = KBytes >>> [ 5] 4.00-5.00 sec 34.9 MBytes 292 Mbits/sec 167 1.43 = KBytes >>> [ 5] 5.00-6.00 sec 34.2 MBytes 287 Mbits/sec 221 2.85 = KBytes >>> [ 5] 6.00-7.00 sec 34.1 MBytes 286 Mbits/sec 169 100 = KBytes >>> [ 5] 7.00-8.00 sec 35.2 MBytes 295 Mbits/sec 159 7.13 = KBytes >>> [ 5] 8.00-9.00 sec 34.3 MBytes 287 Mbits/sec 138 4.28 = KBytes >>> [ 5] 9.00-10.00 sec 33.3 MBytes 279 Mbits/sec 182 2.85 = KBytes >>> - - - - - - - - - - - - - - - - - - - - - - - - - >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.00 sec 347 MBytes 291 Mbits/sec 1578 = sender >>> [ 5] 0.00-10.00 sec 346 MBytes 291 Mbits/sec = receiver >>>=20 >>> Thanks, >>> Steve >>=20 >> One other question: are you running powerd? I booted without it, and = my >> throughput dropped to 600-640 Mb/s. Repeating the test, = retransmissions >> went down but throughput was about the same. Note, the RPi 4, and = probably >> the CM 4, boots at a lower clock frequency by default, and powerd = raises it >> under load. I'm running powerd with -M 1800, overclocking a little. >=20 > I explore here fixed frequencies: 2000 MHz, 600 MHz, 1500 MHz, 1800 = MHz > (no powerd use) Well, my later assumption about the likes of the = hw.cpufreq.sdram_freq_min being due to RPi* firmware looks to be wrong. The RPi* documentation changed from 400 MHz to 3200 MHz for RPi4B sdram_freq_min at: Before (400), Jun 8, 2021: = https://github.com/raspberrypi/documentation/blob/974995fabb184a2435a98e68= c1e728b346112f89/configuration/config-txt/overclocking.md After (3200), Jun 9, 2021: = https://github.com/raspberrypi/documentation/blob/920ff905995541f7ef1c6048= 2924a392143e9192/configuration/config-txt/overclocking.md The RPi* firmware should be setting things up to have 3200 MHz. Since that is not what FreeBSD ends up with in modern snapshots with the FreeBSD supplied config.txt , Likely FreeBSD has taken control of such. This might just be one example parameter that is overridden. FYI: the 2023-Dec-16 stable/14 snapshot that I'm using has: # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 10:50:39 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Mar 17 2023 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) Far more recent than 2021. > Based on: >=20 > # uname -apKU > FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch6 >=20 > # more /boot/efi/config.txt=20 > [all] > arm_64bit=3D1 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Ddisable-bt > device_tree_address=3D0x4000 > kernel=3Du-boot.bin >=20 > [pi4] > hdmi_safe=3D1 > armstub=3Darmstub8-gic.bin > # > over_voltage=3D6 > sdram_freq_min=3D3200 > arm_freq_min=3D2000 > force_turbo=3D1 >=20 > # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq > dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 > dev.cpu.0.freq_levels: 2000/-1 > dev.cpu.0.freq: 2000 >=20 >=20 > # iperf3 -c 192.168.1.157 > Connecting to host 192.168.1.157, port 5201 > [ 5] local 192.168.1.159 port 52424 connected to 192.168.1.157 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 243 328 = KBytes > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 18.5 = KBytes > [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 149 173 = KBytes > [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 150 456 = KBytes > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 159 456 = KBytes > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 160 538 = KBytes > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 143 1.43 = KBytes > [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 215 167 = KBytes > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 194 580 = KBytes > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 157 552 = KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 1720 = sender > [ 5] 0.00-10.01 sec 1.10 GBytes 941 Mbits/sec = receiver >=20 > iperf Done. >=20 >=20 > Note: The amd64 system running main [so: 15] and the RPi4B are > on the same ethernet switch. >=20 >=20 > With the 4 overclocking lines in config.txt commented out : >=20 > # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq > dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1 > dev.cpu.0.freq_levels: 1500/-1 600/-1 > dev.cpu.0.freq: 600 >=20 > Note: the default context lacks 1800 (based on the RPi* firmware = vintage > in the snapshot). Later I show having 1800 instead of 1500. >=20 > # iperf3 -c 192.168.1.157 > Connecting to host 192.168.1.157, port 5201 > [ 5] local 192.168.1.159 port 42060 connected to 192.168.1.157 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 70.8 MBytes 594 Mbits/sec 18 195 = KBytes =20 > [ 5] 1.00-2.00 sec 73.8 MBytes 619 Mbits/sec 8 293 = KBytes =20 > [ 5] 2.00-3.00 sec 73.6 MBytes 618 Mbits/sec 19 250 = KBytes =20 > [ 5] 3.00-4.00 sec 73.6 MBytes 618 Mbits/sec 9 366 = KBytes =20 > [ 5] 4.00-5.00 sec 73.3 MBytes 615 Mbits/sec 9 447 = KBytes =20 > [ 5] 5.00-6.00 sec 73.3 MBytes 615 Mbits/sec 16 303 = KBytes =20 > [ 5] 6.00-7.00 sec 73.2 MBytes 614 Mbits/sec 0 455 = KBytes =20 > [ 5] 7.00-8.00 sec 73.6 MBytes 618 Mbits/sec 1 328 = KBytes =20 > [ 5] 8.00-9.00 sec 73.5 MBytes 616 Mbits/sec 16 246 = KBytes =20 > [ 5] 9.00-10.00 sec 73.3 MBytes 615 Mbits/sec 0 435 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 732 MBytes 614 Mbits/sec 96 = sender > [ 5] 0.00-10.01 sec 732 MBytes 613 Mbits/sec = receiver >=20 > iperf Done. >=20 > Assigning 1500: >=20 > # sysctl dev.cpu.0.freq=3D1500 > dev.cpu.0.freq: 600 -> 1500 >=20 > # sysctl dev.cpu.0.freq=3D1500 > dev.cpu.0.freq: 600 -> 1500 > root@generic:~ # iperf3 -c 192.168.1.157 > Connecting to host 192.168.1.157, port 5201 > [ 5] local 192.168.1.159 port 28904 connected to 192.168.1.157 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 4 472 = KBytes =20 > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 6 464 = KBytes =20 > [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 5 452 = KBytes =20 > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 3 443 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 4 421 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 4 397 = KBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 3 378 = KBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 5 355 = KBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 2 476 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 5 446 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 41 = sender > [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver >=20 >=20 >=20 > Adding arm_boost=3D1 to config.txt in order to have 1800 instead of = 1500 > (needed due to the RPi* firmware vintage in FreeBSD snapshots): >=20 > # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq > dev.bcm2835_cpufreq.0.freq_settings: 1800/-1 600/-1 > dev.cpu.0.freq_levels: 1800/-1 600/-1 > dev.cpu.0.freq: 600 >=20 > # sysctl dev.cpu.0.freq=3D1800 > dev.cpu.0.freq: 600 -> 1800 >=20 > # iperf3 -c 192.168.1.157 > Connecting to host 192.168.1.157, port 5201 > [ 5] local 192.168.1.159 port 27499 connected to 192.168.1.157 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 169 104 = KBytes =20 > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 320 = KBytes =20 > [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 157 52.8 = KBytes =20 > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 143 87.0 = KBytes =20 > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 143 121 = KBytes =20 > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 159 104 = KBytes =20 > [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 138 238 = KBytes =20 > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 152 276 = KBytes =20 > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 145 115 = KBytes =20 > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 162 283 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 1518 = sender > [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver >=20 > iperf Done. >=20 >=20 >=20 > =46rom this it appears that the Retr counts do not seem to make > much of a difference to the Bitrate's achieved. But the arm > frequency does if 600 is involved. >=20 >=20 > My understanding is that arm_boost=3D1 was later made the default > in later vintages of the rpi* firmware. arm_boots only causes > 1800 for Rev 1.4+ . Pi 400's have 1800 available by default, at > least for modern enough RPi* firmware. >=20 > https://www.raspberrypi.com/documentation/computers/config_txt.html > is not necessarily accurate for the older RPi* firmware that FreeBSD > uses in its snapshots/releases. >=20 >> IIRC >> the standard clock is 1500 for the RPi 4. But the throughput is = about the >> same using the standard clock with powerd. >>=20 >> Mike >>=20 >>> On 12/22/2023 9:23 AM, Mike Karels wrote: >>>> On 22 Dec 2023, at 6:20, Steve Bernacki wrote: >>>>=20 >>>>> I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace = my aging FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 = on it, and both Ethernet devices (genet0 and ue0) were properly = identified. However, network throughput on my gigabit network is pretty = bad; iperf3 reports a maximum transfer speed of 291 Mbits/sec. Flashing = OpenWRT on the same hardware using the same ethernet port, I'm able to = achieve 923 Mbits/sec. >>>>>=20 >>>>> Does anyone have any suggestions on how to improve throughput = under FreeBSD? >>>>>=20 >>>>> Thank you >>>>> Steve >>>> I just tested with an RPi4 (4 GB) and 14.0 using iperf3. It looks = like I'm getting >>>> a rather variable number of retransmissions. On my first run = (client on RPi 4), >>>> I got 460 Mb/s with a lot of retransmissions, but the next couple = of runs, including >>>> one receiving, I got about 940 Mb even with some retransmissions. = The peers were >>>> fairly fast FreeBSD 13.2 and 15-current systems. Are you seeing = retransmissions? >>>>=20 >>>> I'll try to look into this, but I'm not sure when I'll get to it. >>>>=20 >>>> Mike =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 23 23:32:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyL6q5BsTz558x9 for ; Sat, 23 Dec 2023 23:32:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyL6p4yFmz3Dc0 for ; Sat, 23 Dec 2023 23:32:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="V/2ymu17"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703374337; bh=YEvkR6eJbDkcVI5Z8CxkzLUAdrJu8AsRN1uCJt/J224=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=V/2ymu172ilG+RlPaxjAUmgXuJ4b55urxsplAaBYwEQg7VXqJZzQpFL61DjipwH4MRJEZ+PvyCTXNW7b8G1ZSiScVDtblBSj+TUfHSJX7aMVfVbNNwcoJrAM6HOTxvqygpAzzpkKH8UDu65GrYpmOPLNk1eVnVKV9qi7n9RJ2bkQDgTWnJXjslV8aIYpOGCSrQOaZSS40s9TTBkqOITe/w4XOUl5xVfRkhmWDZLEn0eMp4pQtYNVM0sZw6+Mxu2xiAf5eklSUZfYH2xAgAywKsJJ5tpVpzEae2KBgDAPKn6sf8YvksN8m/1YZyJBEIbn/5jlOX7srI9yya5RqIbidQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703374337; bh=FHd302nttU/bb8U0wMKtd5QyYmr3s0gdSLzzr3gnmS/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rwviXasMvbBFm+pt0v1W1zuNX63YLzR3tZSP+HkRY3MJ7+Fs4GXlfWNAwIJLvarhoRefwufGYpNVSLD/iKKs9DkCHDAK8sHEQeDqr0bd8gsBk3UF3IaCgxhwa1MC5CMIHs3NqboTENAKgCtnNG60eAsSZZgctOdXc05UagNC7l7teJqKXYJRlQ2/Lxb67fiBdPiF5uz8p8xVcwAFfEaptaqfjut4CifyyksIPBCKYrbye7oezwPl8Wikb+xTWwMu/wgHWd8H0YEBxMFeP8y5Z/1kbEtgvWK5Mc4JKRh+z/3Fs25tHqHQ2X1HUBoXII0PUpXzFIUsurNCb4clKH82Xg== X-YMail-OSG: ehz2_QMVM1nBWwrG5yw6ynhn.H99nbEslTJCTfhpJn4ELijDjvRKvM3YrAcsyAh y8b15nCjv2taoRMTv06qmErjabi.ZfVJB7mGlMgowLCtDWAH3qwxaY98YM3eN3iD774OlhIkV75b H.Gsh7kdLxVkzZv.f891jzpZpuO2rVxvW6FInIfRUXA2DgOl5Rx1bKQK8.IzxWt5FUALr_YgqREH nZO7F5cit5DxtejsX1EYFn3xKeEA20.cQpGpeKeFoknfSUkmafk_lE5hG3D2Olg23cboaR93ah8G AitKRGxQy8GndFopawc_n8YRCE6j0FDJ5WaBh5HU2i_bUw33QdQs3PiMq5ZimGyeIfY0ZjXY5Fwe Zzw_aUvDTmQAE_nsj.EZn0bKYV80nSEBBsw8gLneZhcezjAvF1i4p5HptZe.dAiL9MUdrkUMJqDR yuQ.GW5TBvB4CSlHq9RCo5DTI3XIpFaDWy39n7lygg8Jl.tDpUIBlMGhziDEEGC3IX6qJ5.bjlSp 9pkcXPZVo88qPEcWlSCaQjSpBpwnlvHXn_ngTUhOYO0fyWqoWMLK611RCS42191wETP14Kn.1OLP nhV3PmwEu75JOlWaOPz0zMRPVICWYR4y7IyyGhpSriLwtxU6VyEQem2SF2Uago8t4Xiw7mbNRIvN v6ADUwy8hoRx_9xOHxsLzFQUOPb83v65MiiyEP8X5axO9LLEV1tWU6h7eAhIWGE1jwKZB5Zv31_f dgcIviFysYIZIVlUj0SWyBjySzvlRTPK6OpaZzHo6W0TopQe73Uf8NwOlwsK7fkvtC2iIeVgcnYa SNxYnKlkz7keKerpLcG.W6dNB.pwhjCE49B__kQlHfXHFTBwy2gdin25MJCuJepvVwVkmbCxAYZZ abpvOA8Hrxpv1Jq8ok9qB.KULGg7GKOffPMiNhmnklbUSgym85hy6QcQRhSceAGw7klbW040cSdi ED2XRfS59zBXlRytoHhI3E9g85YBdgvfDDThmxDyyWvARs2djMhIOIW4mTm47CBgN549o_zIJCPa q7Q3rUk8CuEh7CvRrZj5e9XRRP0tPpZwLisFgTBAW_NFIld9Fyx16eau2oEtSQgAIAl0dmcvvgln cDXstpuiAy4neh_41rvRQq0w8WPRLYOpYBQyACq1OCZ0TCaV2_xwpyzGr3ZV0jO8wqV4gVMKRBFe QgXxWEm1s690zKh2icSbQOktyxACRVp32uuh.BTEMDvUIn3zofPr4mAUtRPo9QkJ2XQP2Gplup7v gMrQgyUFTX3hMZO1KzTECGLL_QFV.nr.yUhChxfTknlNhlP0o0C2u_TCmf.q67EjqR6levsJec6i uvc4QKdxi9EVWWO_DK.6U_3p46bujKF5e_spxcLSKXOUDWhOz1CX2HCMEGVxyh4rktPMXIDuNqYO Vz2nM_cG275r5mvW9wdtlQCvW_h0QEbMXlREzd4Y7KGbWz.PJGQtHR0G39u0rd0QV4DJlnmex.nO SooYTFlrmHr_JB3St5vVabPY8aRSJLVtPs11V3UTN6z8iBK0PptTMLfahN14zlYNRJ2wQGmvMxsK 2RZwSRxCWTpQb2Yno6Dysf6QLm_2ZiEdYvGUQZafOznB0RuqKn3NoT0ajS3Vm8s7z3B5OpkXgiFj PNXHgQa9vGl_OCF1Mg2iNvE_fQa33n.sofw_RmLsJhnY47mo_QVH1vDtaX6VQxd450JZA4DZifcC osJ5kXBKBDADdjNLm8JwepOpFTBev79sGhhTCL0L5eho.R7IhzsUaUl5vwTCN0A3HJQT7T0QH1e6 Md8W5pi2xqwlQtnSqeIwjYEuC5tvyvo0fVWWjvvJ_IV.ZH.4vhH0wNHK9bY4E5bdfW1qO2lun9SM MEW_DnLeGbdVUIH067jP.A9vIySet0C1aKvAEIsht8X0u9JalkYeL5HyQeIermwZi5UrwHqU6vtz ddUvtMGGhT.q_Ej5Ddvi3wd0sdTJg.i2rC9A4JYqt3Xt8RRAx2nHA1yoPJX_jd4kPXILtV2NlsRW 1gv6Y7.VRLXY1MLdcNh4B5XLjej4I6R.RZGu.UmTIaeoYg_ZW6LSq.lYQ.2uj51Vqjjbh7qMd.LM BEtAiNBWwWzMHNC7lBXnwRFKXCAC1avaUwLygiZpizPcYukTy17DDu671xmlY0bJ7kRnWw0vG_Ve HF0nXhyufvgyj787j1pIfjo9ENuL1fd9WrptaP9eOeepERTTbV2oJMnaVDpCXv3CH4mQc2yqBY8P .7ZygJCePJrcely.s0IP3xkSqXEpcLfU7FWjkwGTwNofsfy_HlXcksZqw8lh3gfmxemBPtat11JW LJ7Pi X-Sonic-MF: X-Sonic-ID: f755bc14-b9c7-4215-8914-e4c58293a275 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Dec 2023 23:32:17 +0000 Received: by hermes--production-gq1-6949d6d8f9-bvfr7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45dcbf7e53af0d1e046434cc394e7c97; Sat, 23 Dec 2023 23:32:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: FreeBSD 14.0-RELEASE and Raspberry Pi CM4 4GB From: Mark Millard In-Reply-To: <8CBB5E92-942E-43FA-B188-8288480B8D95@yahoo.com> Date: Sat, 23 Dec 2023 15:32:01 -0800 Cc: Steve Bernacki , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <445940f7-e8f1-4dbc-87be-99bfd705141d@copacetic.net> <2E1B887B-EB3C-4F47-A6EE-8256149F7C84@karels.net> <8CBB5E92-942E-43FA-B188-8288480B8D95@yahoo.com> To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SyL6p4yFmz3Dc0 X-Spamd-Bar: --- On Dec 23, 2023, at 15:27, Mark Millard wrote: > On Dec 22, 2023, at 17:28, Mark Millard wrote: >=20 >> On Dec 22, 2023, at 14:48, Mike Karels wrote: >>=20 >> On 22 Dec 2023, at 16:14, Steve Bernacki wrote: >>>=20 >>>> Hi Mike, >>>>=20 >>>> Indeed, I'm getting a lot of retransmits: >>>>=20 >>>> [ 5] local 172.16.200.2 port 55551 connected to 172.16.200.182 = port 5201 >>>> [ ID] Interval Transfer Bitrate Retr Cwnd >>>> [ 5] 0.00-1.00 sec 36.2 MBytes 304 Mbits/sec 60 9.98 = KBytes >>>> [ 5] 1.00-2.00 sec 35.7 MBytes 300 Mbits/sec 143 111 = KBytes >>>> [ 5] 2.00-3.00 sec 34.9 MBytes 293 Mbits/sec 141 7.13 = KBytes >>>> [ 5] 3.00-4.00 sec 33.9 MBytes 284 Mbits/sec 198 99.5 = KBytes >>>> [ 5] 4.00-5.00 sec 34.9 MBytes 292 Mbits/sec 167 1.43 = KBytes >>>> [ 5] 5.00-6.00 sec 34.2 MBytes 287 Mbits/sec 221 2.85 = KBytes >>>> [ 5] 6.00-7.00 sec 34.1 MBytes 286 Mbits/sec 169 100 = KBytes >>>> [ 5] 7.00-8.00 sec 35.2 MBytes 295 Mbits/sec 159 7.13 = KBytes >>>> [ 5] 8.00-9.00 sec 34.3 MBytes 287 Mbits/sec 138 4.28 = KBytes >>>> [ 5] 9.00-10.00 sec 33.3 MBytes 279 Mbits/sec 182 2.85 = KBytes >>>> - - - - - - - - - - - - - - - - - - - - - - - - - >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.00 sec 347 MBytes 291 Mbits/sec 1578 = sender >>>> [ 5] 0.00-10.00 sec 346 MBytes 291 Mbits/sec = receiver >>>>=20 >>>> Thanks, >>>> Steve >>>=20 >>> One other question: are you running powerd? I booted without it, = and my >>> throughput dropped to 600-640 Mb/s. Repeating the test, = retransmissions >>> went down but throughput was about the same. Note, the RPi 4, and = probably >>> the CM 4, boots at a lower clock frequency by default, and powerd = raises it >>> under load. I'm running powerd with -M 1800, overclocking a little. >>=20 >> I explore here fixed frequencies: 2000 MHz, 600 MHz, 1500 MHz, 1800 = MHz >> (no powerd use) >=20 > Well, my later assumption about the likes of the = hw.cpufreq.sdram_freq_min Sorry: (RPi* config.txt notation) sdram_freq_min (since 400 is observed = to occur) (FreeBSD does not expose a hw.cpufreq.sdram_freq_min .) > being due to RPi* firmware looks to be wrong. The RPi* documentation > changed from 400 MHz to 3200 MHz for RPi4B sdram_freq_min at: >=20 > Before (400), Jun 8, 2021: > = https://github.com/raspberrypi/documentation/blob/974995fabb184a2435a98e68= c1e728b346112f89/configuration/config-txt/overclocking.md >=20 > After (3200), Jun 9, 2021: > = https://github.com/raspberrypi/documentation/blob/920ff905995541f7ef1c6048= 2924a392143e9192/configuration/config-txt/overclocking.md >=20 > The RPi* firmware should be setting things up to have 3200 MHz. Since > that is not what FreeBSD ends up with in modern snapshots with the > FreeBSD supplied config.txt , Likely FreeBSD has taken control of > such. >=20 > This might just be one example parameter that is overridden. >=20 > FYI: the 2023-Dec-16 stable/14 snapshot that I'm using > has: >=20 > # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 10:50:39 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Mar 17 2023 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) >=20 > Far more recent than 2021. >=20 >> Based on: >>=20 >> # uname -apKU >> FreeBSD generic 14.0-STABLE FreeBSD 14.0-STABLE #0 = stable/14-n266002-2ef9079ece5a: Sat Dec 16 08:49:23 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch6 >>=20 >> # more /boot/efi/config.txt=20 >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> [pi4] >> hdmi_safe=3D1 >> armstub=3Darmstub8-gic.bin >> # >> over_voltage=3D6 >> sdram_freq_min=3D3200 >> arm_freq_min=3D2000 >> force_turbo=3D1 >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 >> dev.cpu.0.freq_levels: 2000/-1 >> dev.cpu.0.freq: 2000 >>=20 >>=20 >> # iperf3 -c 192.168.1.157 >> Connecting to host 192.168.1.157, port 5201 >> [ 5] local 192.168.1.159 port 52424 connected to 192.168.1.157 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 243 328 = KBytes >> [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 18.5 = KBytes >> [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 149 173 = KBytes >> [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 150 456 = KBytes >> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 159 456 = KBytes >> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 160 538 = KBytes >> [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 143 1.43 = KBytes >> [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 215 167 = KBytes >> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 194 580 = KBytes >> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 157 552 = KBytes >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 1720 = sender >> [ 5] 0.00-10.01 sec 1.10 GBytes 941 Mbits/sec = receiver >>=20 >> iperf Done. >>=20 >>=20 >> Note: The amd64 system running main [so: 15] and the RPi4B are >> on the same ethernet switch. >>=20 >>=20 >> With the 4 overclocking lines in config.txt commented out : >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1 >> dev.cpu.0.freq_levels: 1500/-1 600/-1 >> dev.cpu.0.freq: 600 >>=20 >> Note: the default context lacks 1800 (based on the RPi* firmware = vintage >> in the snapshot). Later I show having 1800 instead of 1500. >>=20 >> # iperf3 -c 192.168.1.157 >> Connecting to host 192.168.1.157, port 5201 >> [ 5] local 192.168.1.159 port 42060 connected to 192.168.1.157 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 70.8 MBytes 594 Mbits/sec 18 195 = KBytes =20 >> [ 5] 1.00-2.00 sec 73.8 MBytes 619 Mbits/sec 8 293 = KBytes =20 >> [ 5] 2.00-3.00 sec 73.6 MBytes 618 Mbits/sec 19 250 = KBytes =20 >> [ 5] 3.00-4.00 sec 73.6 MBytes 618 Mbits/sec 9 366 = KBytes =20 >> [ 5] 4.00-5.00 sec 73.3 MBytes 615 Mbits/sec 9 447 = KBytes =20 >> [ 5] 5.00-6.00 sec 73.3 MBytes 615 Mbits/sec 16 303 = KBytes =20 >> [ 5] 6.00-7.00 sec 73.2 MBytes 614 Mbits/sec 0 455 = KBytes =20 >> [ 5] 7.00-8.00 sec 73.6 MBytes 618 Mbits/sec 1 328 = KBytes =20 >> [ 5] 8.00-9.00 sec 73.5 MBytes 616 Mbits/sec 16 246 = KBytes =20 >> [ 5] 9.00-10.00 sec 73.3 MBytes 615 Mbits/sec 0 435 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 732 MBytes 614 Mbits/sec 96 = sender >> [ 5] 0.00-10.01 sec 732 MBytes 613 Mbits/sec = receiver >>=20 >> iperf Done. >>=20 >> Assigning 1500: >>=20 >> # sysctl dev.cpu.0.freq=3D1500 >> dev.cpu.0.freq: 600 -> 1500 >>=20 >> # sysctl dev.cpu.0.freq=3D1500 >> dev.cpu.0.freq: 600 -> 1500 >> root@generic:~ # iperf3 -c 192.168.1.157 >> Connecting to host 192.168.1.157, port 5201 >> [ 5] local 192.168.1.159 port 28904 connected to 192.168.1.157 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 4 472 = KBytes =20 >> [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 6 464 = KBytes =20 >> [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 5 452 = KBytes =20 >> [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 3 443 = KBytes =20 >> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 4 421 = KBytes =20 >> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 4 397 = KBytes =20 >> [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 3 378 = KBytes =20 >> [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 5 355 = KBytes =20 >> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 2 476 = KBytes =20 >> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 5 446 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 41 = sender >> [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver >>=20 >>=20 >>=20 >> Adding arm_boost=3D1 to config.txt in order to have 1800 instead of = 1500 >> (needed due to the RPi* firmware vintage in FreeBSD snapshots): >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 1800/-1 600/-1 >> dev.cpu.0.freq_levels: 1800/-1 600/-1 >> dev.cpu.0.freq: 600 >>=20 >> # sysctl dev.cpu.0.freq=3D1800 >> dev.cpu.0.freq: 600 -> 1800 >>=20 >> # iperf3 -c 192.168.1.157 >> Connecting to host 192.168.1.157, port 5201 >> [ 5] local 192.168.1.159 port 27499 connected to 192.168.1.157 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 169 104 = KBytes =20 >> [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 150 320 = KBytes =20 >> [ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 157 52.8 = KBytes =20 >> [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 143 87.0 = KBytes =20 >> [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 143 121 = KBytes =20 >> [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 159 104 = KBytes =20 >> [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 138 238 = KBytes =20 >> [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 152 276 = KBytes =20 >> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 145 115 = KBytes =20 >> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 162 283 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 1518 = sender >> [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec = receiver >>=20 >> iperf Done. >>=20 >>=20 >>=20 >> =46rom this it appears that the Retr counts do not seem to make >> much of a difference to the Bitrate's achieved. But the arm >> frequency does if 600 is involved. >>=20 >>=20 >> My understanding is that arm_boost=3D1 was later made the default >> in later vintages of the rpi* firmware. arm_boots only causes >> 1800 for Rev 1.4+ . Pi 400's have 1800 available by default, at >> least for modern enough RPi* firmware. >>=20 >> https://www.raspberrypi.com/documentation/computers/config_txt.html >> is not necessarily accurate for the older RPi* firmware that FreeBSD >> uses in its snapshots/releases. >>=20 >>> IIRC >>> the standard clock is 1500 for the RPi 4. But the throughput is = about the >>> same using the standard clock with powerd. >>>=20 >>> Mike >>>=20 >>>> On 12/22/2023 9:23 AM, Mike Karels wrote: >>>>> On 22 Dec 2023, at 6:20, Steve Bernacki wrote: >>>>>=20 >>>>>> I recently purchased a RPI CM4 with 4GB and 32GB eMMC to replace = my aging FreeBSD firewall. I managed to install FreeBSD 14.0-RELEASE-p3 = on it, and both Ethernet devices (genet0 and ue0) were properly = identified. However, network throughput on my gigabit network is pretty = bad; iperf3 reports a maximum transfer speed of 291 Mbits/sec. Flashing = OpenWRT on the same hardware using the same ethernet port, I'm able to = achieve 923 Mbits/sec. >>>>>>=20 >>>>>> Does anyone have any suggestions on how to improve throughput = under FreeBSD? >>>>>>=20 >>>>>> Thank you >>>>>> Steve >>>>> I just tested with an RPi4 (4 GB) and 14.0 using iperf3. It looks = like I'm getting >>>>> a rather variable number of retransmissions. On my first run = (client on RPi 4), >>>>> I got 460 Mb/s with a lot of retransmissions, but the next couple = of runs, including >>>>> one receiving, I got about 940 Mb even with some retransmissions. = The peers were >>>>> fairly fast FreeBSD 13.2 and 15-current systems. Are you seeing = retransmissions? >>>>>=20 >>>>> I'll try to look into this, but I'm not sure when I'll get to it. >>>>>=20 >>>>> Mike >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com