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