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