Date: Wed, 20 Dec 2023 09:25:15 +0200 From: titus <titus@edc.ro> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook Message-ID: <54C44649-91A1-4A41-B2BA-FFCCACD0099D@edc.ro> In-Reply-To: <CANCZdfpRJxJw2_ma0cCcoGGmAat4KVj5sOfdnGMR9w%2BOQCYxaQ@mail.gmail.com> References: <CA%2B1FSiit5NJ_W7f5mssivkGGLevXh_XmSB7ZxZbQe1dgev0_Pg@mail.gmail.com> <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <CA%2B1FSiheSwrO7Tz3F3Nmu4vcC2E=ONRX8nF3bhQGV0UDOFTrww@mail.gmail.com> <da024d1687f3a.2f0c601bba502@mailgate.us> <CA%2B1FSih7C0HEun99LHEwvyYRiH0PaLwwgnoQLHB69TWz2ykDZg@mail.gmail.com> <CA%2B1FSijoPkRZRaU6tujaMJZeFd3CSyUN%2Bh4y0_NrrB5VWLgwpA@mail.gmail.com> <CA%2B1FSiib3uu9Ky8N5rSSt%2BH1nfzUnChKhGs2ERWmsbp2T4=2uA@mail.gmail.com> <CA%2B1FSihtb3%2Bbm-pSqa7JGBjy3JUXYD6i0c6J2KHy%2BEO8rmZ5PA@mail.gmail.com> <alpine.DEB.2.22.394.2312191131290.3175268@ubuntu-linux-20-04-desktop> <CA%2B1FSigh=fc07o-RSMZ%2Bhf9-YBUudAwnGcN9k8bP1RnPBP7tRA@mail.gmail.com> <CANCZdfpRJxJw2_ma0cCcoGGmAat4KVj5sOfdnGMR9w%2BOQCYxaQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288>; = https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/ = <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 <imp@bsdimp.com> 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/ = <https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-qe= mu.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 = <https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/FreeBSD-1= 4.0-RELEASE-arm-armv7-GENERICSD.img.xz> > 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img = conv=3Dnotrunc > 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img = conv=3Dnotrunc > 10. cat > start-freebsd-arm.sh > #!/bin/sh > qemu-system-arm \ > -M virt \ > -m 1024 \ > -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > -nographic \ > -serial mon:stdio > ^D > 11. chmod +x start-freebsd-arm.sh > 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD >=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 = <marietto2008@gmail.com <mailto:marietto2008@gmail.com>> 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/ = <https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_arm= 32_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 = <sstabellini@kernel.org <mailto:sstabellini@kernel.org>> 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 = <marietto2008@gmail.com <mailto:marietto2008@gmail.com>> 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 = <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 = <marietto2008@gmail.com <mailto: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. > >=20 > > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto = <marietto2008@gmail.com <mailto:marietto2008@gmail.com>> wrote: > > ---> There are no specific options in u-boot devoted to = FreeBSD > >=20 > > This is an important factor. So,what about if,instead of compiling a = new version of u-boot on the partition 2,I will > > recompile the u-boot 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 = <https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/view?us= p=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 <http://rules.mk/>; > > CREDITS boards.cfg fs = scripts > > MAINTAINERS common include = snapshot.commit > > MAKEALL config.mk <http://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 = <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/ = <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 = <stanislav.silnicki@mailgate.us <mailto:stanislav.silnicki@mailgate.us>> = wrote: > > I'm not an expert in the topic, I only know, that ARM has = divided hardware into two worlds - Secure and > > Not-So, strictly limiting any software, running in non-secure = world with access to functions and > > resources. = https://developer.arm.com/documentation/den0013/d/Security/TrustZone-hardw= are-architecture?lang=3Den = <https://developerarm.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 = <https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectu= re/The-System-Level-Programmers--Model/The-Virtualization-Extens> > > ions), so my guess (only guess!!!), virtualization software has to = prepare (configure) HW platform in the way, > > that FreeBSD kernel will not lack any resources, required to = configure MPU, VA, etc. > > So, if you lucky to boot virtualizer, which is aware of target OS, = that maybe you can boot the kernel. Although, I > > doubt, that you need to boot 'second' u-boot to boot the kernel - = there is simply ubldr, which you can hook somehow > > from virtualizer.... > >=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 = <stanislav.silnicki@mailgate.us <mailto:stanislav.silnicki@mailgate.us>> = wrote: > > Hi Mario, > >=20 > > U-Boot beast is hiding in this den: = https://source.denx.de/u-boot/u-boot.git = <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 = <https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/Kco= nfig?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 = <https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_defcon= fig?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 = <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 = <https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f= 986c979edef0c9> > >=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 = <http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/?= vos=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 = <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$ = <http://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 = <https://github.com/virtualopensyste...18a39b6c177dff58a/include/configs/s= now.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 = <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 = <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 = <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/ = <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 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">for = the panic @ dhcp see <div class=3D""><a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288" = class=3D"">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271288</a><= /div><div class=3D""><a = href=3D"https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu= .89016/" = class=3D"">https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-q= emu.89016/</a></div><div class=3D""><br class=3D""></div><div = class=3D"">its a problem with virtio net driver (was fixed by forum user = _martin but never went in the main tree)</div><div class=3D"">if you = emulate another nic type will work</div><div class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Dec 20, 2023, at 6:52 AM, Warner Losh <<a = href=3D"mailto:imp@bsdimp.com" class=3D"">imp@bsdimp.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">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.. </div><div = class=3D"">If I misunderstood, then the below isn't good advice. Chain = booting the u-boot, the first u-boot initializes things so you = want</div><div class=3D"">to start with stage after the SPL But the = different error messages suggest that it's trying to reboot with kexec, = which</div><div class=3D"">isn't supported on armv7 at the moment.<br = class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">If = you could boot in kvm, I think that the following would work.... = Though I'm not entirely sure how to</div><div class=3D"">specify the two = .fd files in your setup. The use of qemu is to have an easy env to debug = things... I don't</div><div class=3D"">have a chromebook to try...<br = class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">My = first instinct would be to try qemu on x86 (this is the first step of = many to get to your destination).</div><div class=3D""><br = class=3D""></div><div class=3D"">If you could boot the GENERIC_SD image = that we produce using qemu + edk2-arm-code.fd that would</div><div = class=3D"">be a huge first step. This will give you the boot loader, I = believe, to boot in the VM that you need better</div><div class=3D"">than = going via the u-boot route. Since you are booting in a virtualized = environment, I think it wouldn't</div><div class=3D"">matter which one = :).</div><div class=3D""><br class=3D""></div><div class=3D"">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:</div><div class=3D""><a = href=3D"https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-imag= e-in-qemu.80765/" = class=3D"">https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-i= mage-in-qemu.80765/</a></div><div class=3D""><br class=3D""></div><div = class=3D"">1. pkg install qemu</div><div class=3D"">2. mkdir = qemu-armv7-env</div><div class=3D"">3. cd qemu-armv7-env</div><div = class=3D"">4. fetch <a = href=3D"https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0/Fr= eeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz" = class=3D"">https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0= /FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz</a></div><div = class=3D"">5. xz -d -T 0 = FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz</div><div class=3D"">6. = dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64<br class=3D"">7. = dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64<br class=3D"">8. = dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img = conv=3Dnotrunc<br class=3D"">9. dd = if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img = conv=3Dnotrunc</div><div class=3D"">10. cat > = start-freebsd-arm.sh</div><div class=3D"">#!/bin/sh<br = class=3D"">qemu-system-arm \<br class=3D""> -M virt \<br = class=3D""> -m 1024 \<br class=3D""> -drive = file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \<br = class=3D""> -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash = \<br class=3D""> -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrou= gh \<br class=3D""> -nographic \<br class=3D""> -serial = mon:stdio</div><div class=3D"">^D</div><div class=3D"">11. chmod +x = start-freebsd-arm.sh</div><div class=3D"">12. ./start-freebsd-arm.sh = FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD</div><div class=3D""><br = class=3D""></div><div class=3D"">But I hit a snag with this on qemu = 8.1.2 and 8.1.3 with both 13.2 and 14.0:</div><div class=3D""><br = class=3D""></div><div class=3D"">Starting devd.<br class=3D"">Starting = dhclient.<br class=3D"">DHCPDISCOVER on vtnet0 to 255.255.255.255 port = 67 interval 7<br class=3D"">Fatal kernel mode data abort: 'Alignment = Fault' on read<br class=3D"">trapframe: 0xc4b36a60<br = class=3D"">FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013<br = class=3D"">r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 = =3Dc4b36b4c<br class=3D"">r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, = r7 =3D0000022c<br class=3D"">r8 =3D00000000, r9 =3D0000022c, = r10=3Ddd96701a, r11=3Dc4b36b90<br class=3D"">r12=3D4300ffff, = ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750<br class=3D""><br = class=3D"">panic: Fatal abort<br class=3D"">cpuid =3D 0<br class=3D"">time= =3D 1680843057<br class=3D"">KDB: stack backtrace:<br class=3D"">#0 = 0xc035786c at kdb_backtrace+0x48<br class=3D"">#1 0xc02fdd20 at = vpanic+0x140<br class=3D"">#2 0xc02fdbe0 at vpanic+0<br class=3D"">#3 = 0xc06304ac at abort_align+0<br class=3D"">#4 0xc063052c at = abort_align+0x80<br class=3D"">#5 0xc063017c at abort_handler+0x480<br = class=3D"">#6 0xc060f480 at exception_exit+0<br class=3D"">#7 0xc04a9750 = at udp_input+0x288<br class=3D"">#8 0xc0473f54 at ip_input+0x1e0<br = class=3D"">#9 0xc04447c0 at netisr_dispatch_src+0xf8<br class=3D"">#10 = 0xc043bf2c at ether_demux+0x1a4<br class=3D"">#11 0xc043d5e4 at = ether_nh_input+0x480<br class=3D"">#12 0xc04447c0 at = netisr_dispatch_src+0xf8<br class=3D"">#13 0xc043c404 at = ether_input+0x50<br class=3D"">#14 0xc01c0838 at = vtnet_rx_vq_process+0x880<br class=3D"">#15 0xc01b70d0 at = vtpci_intx_intr+0xac<br class=3D"">#16 0xc02b87f0 at = ithread_loop+0x2ec<br class=3D"">#17 0xc02b465c at fork_exit+0xc0<br = class=3D"">Uptime: 19s</div><div class=3D""><br class=3D""></div><div = class=3D"">I don't know if this is a problem with qemu or FreeBSD's = kernel...</div><div class=3D""><br class=3D""></div><div = class=3D"">Warner<br class=3D""></div></div><br class=3D""><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec = 19, 2023 at 3:25=E2=80=AFPM Mario Marietto <<a = href=3D"mailto:marietto2008@gmail.com" target=3D"_blank" = class=3D"">marietto2008@gmail.com</a>> wrote:<br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr" class=3D""><div = class=3D"">I've asked some help on the channel #arm on Reddit and = someone replied :</div><div class=3D""><br class=3D""></div><div = class=3D""><a = href=3D"https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_= for_arm32_bit_as_domu_with/" target=3D"_blank" = class=3D"">https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freeb= sd_for_arm32_bit_as_domu_with/</a></div><div class=3D""><br = class=3D""></div><div class=3D"">Maybe his answer can be useful to = understand why it does not work. <br class=3D""></div></div><br = class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano = Stabellini <<a href=3D"mailto:sstabellini@kernel.org" target=3D"_blank"= class=3D"">sstabellini@kernel.org</a>> wrote:<br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">+Michal<br class=3D""> <br class=3D""> Hi Mario,<br class=3D""> <br class=3D""> I am not sure about booting FreeBSD, but I am certain that u-boot = works<br class=3D""> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config<br = class=3D""> file:<br class=3D""> <br class=3D""> name=3D"test"<br class=3D""> kernel=3D"u-boot.bin"<br class=3D""> extra =3D "console=3Dhvc0"<br class=3D""> memory=3D256<br class=3D""> vcpus=3D1<br class=3D""> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]<br class=3D""> <br class=3D""> I don't know for sure if you can boot FreeBSD but you should = definitely<br class=3D""> be able to see the u-boot command line prompt. The fact that you are<br = class=3D""> getting this message:<br class=3D""> <br class=3D""> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader = found: Invalid kernel<br class=3D""> <br class=3D""> Means that something is not right in the u-boot configuration or = u-boot<br class=3D""> build. Michal and Artem (CCed) might know more. =46rom what I recall,<br = class=3D""> there was nothing special required to get u-boot.bin to boot as domU<br = class=3D""> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue.<br class=3D""> <br class=3D""> Cheers,<br class=3D""> <br class=3D""> Stefano<br class=3D""> <br class=3D""> <br class=3D""> On Tue, 19 Dec 2023, Mario Marietto wrote:<br class=3D""> > ....I see that some other interesting files have been produced by = u-boot when I have compiled it :<br class=3D""> > <br class=3D""> > u-boot<br class=3D""> > u-boot.lds<br class=3D""> > u-boot.bin<br class=3D""> > u-boot.map<br class=3D""> > u-boot-nodtb.bin<br class=3D""> > u-boot.dtb<br class=3D""> > u-boot.srec<br class=3D""> > u-boot-dtb.bin<br class=3D""> > u-boot.sym<br class=3D""> > <br class=3D""> > So,maybe I should use a different u-boot* file for booting FreeBSD = ?<br class=3D""> > <br class=3D""> > <br class=3D""> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto <<a = href=3D"mailto:marietto2008@gmail.com" target=3D"_blank" = class=3D"">marietto2008@gmail.com</a>> wrote:<br class=3D""> > Hello to everyone.<br class=3D""> > <br class=3D""> > I have compiled the needed u-boot.bin from scratch using this = procedure :<br class=3D""> > <br class=3D""> > # git clone <a href=3D"https://github.com/u-boot/u-boot.git" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://github.com/u-boot/u-boot.git</a><br class=3D""> > # cd u-boot<br class=3D""> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make = snow_defconfig : this line generates the file .config<br class=3D""> > # nano .config and I've added these parameters :<br class=3D""> > <br class=3D""> > CONFIG_ARMV7_NONSEC=3Dn<br class=3D""> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy<br class=3D""> > <br class=3D""> > the uboot-bin file is generated with this command :<br class=3D""> > <br class=3D""> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make<br class=3D"">= > <br class=3D""> > 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<br = class=3D""> > some reason,it is not accepted and this could be a problem....<br = class=3D""> > <br class=3D""> > These are the xen config files that I've used :<br class=3D""> > <br class=3D""> > nano freebsd.cfg<br class=3D""> > <br class=3D""> > name=3D"test"<br class=3D""> > kernel=3D"u-boot.bin"<br class=3D""> > extra =3D "console=3Dhvc0"<br class=3D""> > memory=3D256<br class=3D""> > vcpus=3D1<br class=3D""> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ]<br class=3D"">= > <br class=3D""> > nano start-freebsd<br class=3D""> > <br class=3D""> > xl create freebsd.cfg<br class=3D""> > xl console freebsd<br class=3D""> > <br class=3D""> > This is what happens when I launch the vm :<br class=3D""> > <br class=3D""> > # ./start-freebsd<br class=3D""> > <br class=3D""> > Parsing config from freebsd.cfg<br class=3D""> > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader = found: Invalid kernel<br class=3D""> > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image = failed<br class=3D""> > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain = 1:cannot (re-)build domain: -3<br class=3D""> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain = 1:Non-existent domain<br class=3D""> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain = 1:Unable to destroy guest<br class=3D""> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain = 1:Destruction of domain failed<br class=3D""> > freebsd is an invalid domain identifier (rc=3D-6)<br class=3D""> > <br class=3D""> > <br class=3D""> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto <<a = href=3D"mailto:marietto2008@gmail.com" target=3D"_blank" = class=3D"">marietto2008@gmail.com</a>> wrote:<br class=3D""> > 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<br class=3D""> > memory" of the Chromebook". Sorry for the = confusion.<br class=3D""> > <br class=3D""> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto <<a = href=3D"mailto:marietto2008@gmail.com" target=3D"_blank" = class=3D"">marietto2008@gmail.com</a>> wrote:<br class=3D""> > ---> There are no specific options in = u-boot devoted to FreeBSD<br class=3D""> > <br class=3D""> > This is an important factor. So,what about if,instead of compiling = a new version of u-boot on the partition 2,I will<br class=3D""> > recompile the u-boot customized version created by the virtual open = system in 2014,that should be installed on the first<br class=3D""> > partition ? It could work if there are no differences between the = u-boot that should boot Linux and the u-boot that<br class=3D""> > should boot FreeBSD.<br class=3D""> > <br class=3D""> > Can you give a look at the u-boot source code created by virtual = open systems ? You can find it on my google drive :<br class=3D""> > <br class=3D""> > <a = href=3D"https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/= view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09B= Rm/view?usp=3Dsharing</a><br class=3D""> > <br class=3D""> > I need to understand if I can recompile it without problem so that = it can satisfy my needs (the ability of the file<br class=3D""> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by = Stefano Stabellini,the xen developer that suggested to me<br class=3D""> > what I could do to have FreeBSD virtualized under Xen on my Arm = Chromebook) ; otherwise the risk is to find later<br class=3D""> > problems that will make me troubles and that I will not able to = fix.<br class=3D""> > <br class=3D""> > 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<br class=3D""> > correctly,I should put that file inside the root of the u-boot = source code,let's say here :<br class=3D""> > <br class=3D""> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # = ls<br class=3D""> > <br class=3D""> > .checkpatch.conf README = &n= bsp; doc = &n= bsp; net<br class=3D""> > .git = &n= bsp; api = &n= bsp; drivers = &n= bsp; onenand_ipl<br class=3D""> > .gitignore = &n= bsp;arch = &n= bsp; dts = &n= bsp; post<br class=3D""> > COPYING = &n= bsp; board = &n= bsp; examples = &n= bsp; <a href=3D"http://rules.mk/" rel=3D"noreferrer" = target=3D"_blank" class=3D"">rules.mk</a><br class=3D""> > CREDITS = &n= bsp; boards.cfg = &n= bsp;fs = &n= bsp; scripts<br class=3D"">= > MAINTAINERS = co= mmon = &n= bsp; include = &n= bsp; snapshot.commit<br class=3D""> > MAKEALL = &n= bsp; <a href=3D"http://config.mk/" rel=3D"noreferrer" = target=3D"_blank" class=3D"">config.mk</a> = &n= bsp; lib = &n= bsp; spl<br class=3D""> > Makefile = &n= bsp; cros = &n= bsp; mkconfig = &n= bsp; test<br class=3D""> > PRESUBMIT.cfg = disk = &n= bsp; nand_spl = &n= bsp; tools<br class=3D""> > <br class=3D""> > and I should do : make and make install ? and the file I = need,u-boot.bin will be generated ? <br class=3D""> > <br class=3D""> > I didn't find any pre made configuration file inside :<br class=3D"">= > <br class=3D""> > u-boot-vos # find . -type f -name "exynos*" <br class=3D""> > <br class=3D""> > ./include/exynos-fb.h<br class=3D""> > ./include/configs/exynos5-common.h<br class=3D""> > ./doc/device-tree-bindings/spi/exynos-spi.txt<br class=3D""> > ./doc/device-tree-bindings/usb/exynos-usb.txt<br class=3D""> > ./drivers/power/exynos-tmu.c<br class=3D""> > ./drivers/power/exynos-cpufreq.c<br class=3D""> > ./drivers/video/exynos-fb.c<br class=3D""> > ./drivers/spi/exynos_spi.c<br class=3D""> > ./board/samsung/dts/exynos5250-spring.dts<br class=3D""> > ./board/samsung/dts/exynos5250-smdk5250.dts<br class=3D""> > ./board/samsung/dts/exynos5250-snow.dts<br class=3D""> > ./board/samsung/dts/exynos5250-daisy.dts<br class=3D""> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h<br class=3D""> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h<br class=3D""> > ./arch/arm/dts/exynos5250.dtsi<br class=3D""> > ./arch/arm/dts/exynos-periph-id.dtsi<br class=3D""> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c <br class=3D""> > <br class=3D""> > u-boot-vos # find . -type f -name "arndale*"<br class=3D""> > <br class=3D""> > For sure I can't use a newer version of u-boot because otherwise = the patches needed to bypass the bootloader protections<br class=3D""> > of the Arm Chromebook (such as a lot of different patches needed to = boot correctly Linux) will be broken ; anyway,since<br class=3D""> > it works,I don't need to use an updated version of u-boot.<br = class=3D""> > <br class=3D""> > ----> As per my experience, you have to respect these two = options, compiling u-boot for<br class=3D""> > FreeBSD: <a = href=3D"https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot= -master/files/FreeBSD_Fragment" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-b= oot-master/files/FreeBSD_Fragment</a><br class=3D""> > <br class=3D""> > It says that I should use these parameters :<br class=3D""> > <br class=3D""> > CONFIG_ARMV7_NONSEC=3Dn<br class=3D""> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy<br class=3D""> > <br class=3D""> > These are the parameters used to configure a Linux kernel. I don't = understand what's the relation between the compilation<br class=3D""> > 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<br class=3D""> > parameters,so I don't know how to do it (but I know how to = recompile a Linux kernel).<br class=3D""> > <br class=3D""> > ---> I'm not sure that I'm getting you right, as I don't = understand what you mean under "the first u-boot".<br class=3D""> > <br class=3D""> > <br class=3D""> > I'm talking about first u-boot because the whole procedure to boot = Linux on the ARM Chromebook,that's explained here :<br class=3D""> > <br class=3D""> > <a = href=3D"http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chrom= ebook/" rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://www.virtualopensystems.com/en/solutions/guides/kvm-on-ch= romebook/</a><br class=3D""> > <br class=3D""> > <br class=3D""> > at some point they say :<br class=3D""> > <br class=3D""> > <br class=3D""> > To be able to run KVM on ARM platforms, the kernel has to be booted = in hypervisor mode. Because of this relatively recent<br class=3D""> > requirement (due to the introduction of the virtualization = extensions), up until now all booting methods would boot the<br = class=3D""> > kernel in the standard Supervisor mode.<br class=3D""> > <br class=3D""> > For the ARM Chromebook the default boot procedure doesn't allow us = to boot in hypervisor mode. Although the laptop's boot<br class=3D""> > mechanism is based on the frequently used u-boot, the binary is = located in RO memory. Fortunately, a chained u-boot<br class=3D""> > mechanism can be used (i.e. starting another u-boot after the = original). We can then enter hypervisor mode from our<br class=3D""> > custom iteration of u-boot and subsequently load our kernel and = userspace.<br class=3D""> > <br class=3D""> > 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<br = class=3D""> > 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<br class=3D""> > enabled.<br class=3D""> > <br class=3D""> > <br class=3D""> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki <<a = href=3D"mailto:stanislav.silnicki@mailgate.us" target=3D"_blank" = class=3D"">stanislav.silnicki@mailgate.us</a>> wrote:<br class=3D""> > I'm not an expert in the topic, I only = know, that ARM has divided hardware into two worlds - Secure and<br = class=3D""> > Not-So, strictly limiting any software, = running in non-secure world with access to functions and<br class=3D""> > resources. <a = href=3D"https://developerarm.com/documentation/den0013/d/Security/TrustZon= e-hardware-architecture?lang=3Den" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://developer.arm.com/documentation/den0013/d/Security/Trus= tZone-hardware-architecture?lang=3Den</a><br class=3D""> > <br class=3D""> > I'm not sure, that I'm getting you right, as I don't understand = what you mean under "the first u-boot".<br class=3D""> > <br class=3D""> > As I understand, virtualization (HYP) is running in non-secure = world(<a = href=3D"https://developer.arm.com/documentation/ddi0406/c/System-Level-Arc= hitecture/The-System-Level-Programmers--Model/The-Virtualization-Extens" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://developer.arm.com/documentation/ddi0406/c/System-Level-= Architecture/The-System-Level-Programmers--Model/The-Virtualization-Extens= </a><br class=3D""> > ions), so my guess (only guess!!!), virtualization software has to = prepare (configure) HW platform in the way,<br class=3D""> > that FreeBSD kernel will not lack any resources, required to = configure MPU, VA, etc.<br class=3D""> > So, if you lucky to boot virtualizer, which is aware of target OS, = that maybe you can boot the kernel. Although, I<br class=3D""> > doubt, that you need to boot 'second' u-boot to boot the kernel - = there is simply ubldr, which you can hook somehow<br class=3D""> > from virtualizer....<br class=3D""> > <br class=3D""> > Stan<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > Mario Marietto wrote:<br class=3D""> > <br class=3D""> > <br class=3D""> > ---> As I understand, it makes sure = that u-boot keeps in secure mode during boot and passes control to<br = class=3D""> > ubldr, which boots FreeBSD kernel, in = that mode.<br class=3D""> > <br class=3D""> > Can you elaborate your sentence more ? I know that the bootloader = secure mode is bypassed by the virtual open<br class=3D""> > systems u-boot. Are you saying that when the control passes to the = second u-boot,it will happen in secure<br class=3D""> > mode,so that the bypass that happened loading the first u-boot,is = annulled ? If this is true,maybe can I boot<br class=3D""> > FreeBSD using the virtual-open-system custom u-boot ? Is this = compatible with FreeBSD ? Where can I find the<br class=3D""> > u-boot.bin that the xen developer talked about ? thanks bro'.<br = class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki <<a = href=3D"mailto:stanislav.silnicki@mailgate.us" target=3D"_blank" = class=3D"">stanislav.silnicki@mailgate.us</a>> wrote:<br class=3D""> > Hi Mario,<br class=3D""> > <br class=3D""> > U-Boot beast is hiding in this den: <a = href=3D"https://source.denx.de/u-boot/u-boot.git" rel=3D"noreferrer" = target=3D"_blank" = class=3D"">https://source.denx.de/u-boot/u-boot.git</a><br class=3D""> > I took a brief look at your post and it seems to me, that = option CONFIG_CMO_BY_VA_ONLY is irrelevant to<br class=3D""> > your target armv7 32 bit<br class=3D""> > platform: <a = href=3D"https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/ar= mv8/Kconfig?ref_type=3Dheads#L3" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu= /armv8/Kconfig?ref_type=3Dheads#L3</a><br class=3D""> > <br class=3D""> > As for compiling the u-boot, it is a doable task, given that you = understand what you are doing. There<br class=3D""> > are no specific options in u-boot devoted to FreeBSD. It is a boot = loader, whose mission to make basic<br class=3D""> > hardware initialization, read you kernel file from some media into = RAM and then pass it control.<br class=3D""> > <br class=3D""> > Basically, you can grab some defconfig, prepared for any other = Exynos5250 based board (say, this one:<br class=3D""> > <a = href=3D"https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale= _defconfig?ref_type=3Dheads" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arnd= ale_defconfig?ref_type=3Dheads</a>) and adopt<br class=3D""> > it somehow.<br class=3D""> > <br class=3D""> > As per my experience, you have to respect these two options, = compiling u-boot for<br class=3D""> > FreeBSD: <a = href=3D"https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-boot= -master/files/FreeBSD_Fragment" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://github.com/freebsd/freebsd-ports/blob/main/sysutils/u-b= oot-master/files/FreeBSD_Fragment</a><br class=3D""> > <br class=3D""> > As I understand, it makes sure, that u-boot keeps in secure mode = during boot and passes control to<br class=3D""> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a = lot of surprises you may realize.<br class=3D""> > <br class=3D""> > Hope, this will help to progress you tasks<br class=3D""> > Stan<br class=3D""> > <br class=3D""> > Mario Marietto wrote:<br class=3D""> > <br class=3D""> > <br class=3D""> > Hello.<br class=3D""> > <br class=3D""> > I'm trying to boot FreeBSD for arm32 bit = as DomU on my ARM Chromebook. Basically there are<br class=3D""> > two ways to accomplish this task :<br = class=3D""> > <br class=3D""> > 1) to write a patch that allows the = FreeBSD kernel to boot as a zImage file. This could be<br class=3D""> > accomplished applying this patch to a = specific file that's on the source code of FreeBSD :<br class=3D""> > <br class=3D""> > <br class=3D""> > <a = href=3D"https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472= 717035f986c979edef0c9" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391= 472717035f986c979edef0c9</a><br class=3D""> > <br class=3D""> > <br class=3D""> > This patch was written by Julien Grall a = lot of time ago and now it does not work anymore.<br class=3D""> > This is the reason :<br class=3D""> > <br class=3D""> > <br class=3D""> > It appears = FreeBSD-CURRENT removed the last step converting the kernel file to<br = class=3D""> > kernel.bin. The = patch can be readily rebased, but without kernel.bin that<br class=3D""> > doesn't do too = much<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > So,without a rebase of that patch the first option is not = applicable. And I'm not able to fix it.<br class=3D""> > <br class=3D""> > 2) booting FreeBSD using U-Boot,as explained to me by a xen = developer :<br class=3D""> > <br class=3D""> > <br class=3D""> > I was trying to explain why and how = Julien's patch works so that you could be the one<br class=3D""> > to re-do something similar or fix the = patch on the FreeBSD kernel that you are<br class=3D""> > working with. I am happy to help review = and write patches but I don't work with the<br class=3D""> > FreeBSD kernel so I wouldn't be able to = help you quickly. However, I might have a<br class=3D""> > suggestion. Do you know if FreeBSD can be = booted by U-Boot ? Because U-Boot<br class=3D""> > definitely boots as Xen on ARM guest = firmware/bootloader. You should be able to build<br class=3D""> > U-Boot and use the U-Boot binary as Xen = guest kernel, then U-Boot could load FreeBSD<br class=3D""> > from disk or network and start it. For = instance as domU config file:<br class=3D""> > <br class=3D""> > kernel=3D"/home/petalinux/u-boot.bin"<br = class=3D""> > disk =3D [ = '/home/petalinux/test.img,raw,xvda' ]<br class=3D""> > <br class=3D""> > I know it is important to build u-boot = with the following config to make it work on<br class=3D""> > Xen.<br class=3D""> > <br class=3D""> > CONFIG_CMO_BY_VA_ONLY=3Dy<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > This option seems more doable to me according to my knowledge. But = I need to understand how to do<br class=3D""> > it.<br class=3D""> > <br class=3D""> > Well,let's say that on the ARM Chromebook I'm forced to use and = install a customized version of<br class=3D""> > u-boot,created by virtual open systems,because it is the only one = that allows bypassing its<br class=3D""> > bootloader protection. You can find more information here :<br = class=3D""> > <br class=3D""> > <a = href=3D"http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chrom= ebook/?vos=3Dtech" rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://www.virtualopensystems.com/en/solutions/guides/kvm-on-ch= romebook/?vos=3Dtech</a><br class=3D""> > <br class=3D""> > This is the relevant section to read :<br class=3D""> > <br class=3D""> > <br class=3D""> > Bootloader :<br class=3D""> > <br class=3D""> > If you wish to skip this chapter you can = download a pre-compiled binary of the<br class=3D""> > bootloader:<br class=3D""> > <br class=3D""> > <br class=3D""> > $ wget<br class=3D""> > <a = href=3D"http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebo= ok/nv_u-boot-snow.kpart" rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://www.virtualopensystems.com/downloads/guides/kvm_on_chrom= ebook/nv_u-boot-snow.kpart</a><br class=3D""> > <br class=3D""> > <br class=3D""> > To be able to run KVM on ARM platforms, = the kernel has to be booted in hypervisor<br class=3D""> > mode. Because of this relatively recent = requirement (due to the introduction of the<br class=3D""> > virtualization extensions), up until now = all booting methods would boot the kernel in<br class=3D""> > the standard Supervisor mode. For the ARM = Chromebook the default boot procedure<br class=3D""> > doesn't allow us to boot in hypervisor = mode. Although the laptop's boot mechanism is<br class=3D""> > based on the frequently used u-boot, the = binary is located in RO memory. Fortunately,<br class=3D""> > a chained u-boot mechanism can be used = (i.e. starting another u-boot after the<br class=3D""> > original). We can then enter hypervisor = mode from our custom iteration of u-boot and<br class=3D""> > subsequently load our kernel and = userspace.<br class=3D""> > <br class=3D""> > Checkout the needed u-boot code :<br = class=3D""> > <br class=3D""> > <br class=3D""> > $ git clone git://<a = href=3D"http://github.com/virtualopensystems/u-boot.git$" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">github.com/virtualopensystems/u-boot.git$</a> cd u-boot$<br = class=3D""> > ./scripts/build.sh<br class=3D""> > <br class=3D""> > <br class=3D""> > If successful, a message about how to = copy the bootloader on the USB flash disk or SD<br class=3D""> > card will appear. We will use it later = when preparing the boot medium to start our<br class=3D""> > system. If you have followed the Setting = up the boot medium chapter and you have a<br class=3D""> > prepared boot device, then you can update = u-boot by running :<br class=3D""> > <br class=3D""> > <br class=3D""> > $ sudo dd if=3Dnv_uboot-snow.kpart = of=3D/dev/sdX1<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > so,the needed u-boot that we must use should be installed on the = first partition of the sd card.<br class=3D""> > <br class=3D""> > There is another relevant section to read :<br class=3D""> > <br class=3D""> > <br class=3D""> > Setting up the boot medium<br class=3D""> > <br class=3D""> > Now it is time to copy all the relevant = files that we created in the previous<br class=3D""> > chapters,and use them to boot Chromebook = with a different kernel and OS. In all these<br class=3D""> > examples the device /dev/sdX is used. = Take extra care to change the examples to the<br class=3D""> > device that you have attached. Insert the = boot medium on your workstation and<br class=3D""> > carefully execute the following step. = First we need to properly format the boot<br class=3D""> > medium.<br class=3D""> > <br class=3D""> > In the uboot source directory :<br = class=3D""> > <br class=3D""> > <br class=3D""> > $ sudo ./scripts/sdcard.sh /dev/sdX<br = class=3D""> > <br class=3D""> > <br class=3D""> > This will erase all data and create 4 = partitions in the medium, along with copying<br class=3D""> > the u-boot binary to the first = partition:<br class=3D""> > <br class=3D""> > <br class=3D""> > Partition 1 =3D ChromeOS signed binary = (V.O.S chained u-boot)<br class=3D""> > Partition 2 =3D not used<br class=3D""> > Partition 3 =3D EXT2 partition for u-boot = files (uImage and exynos5250-snow.dtb)<br class=3D""> > Partition 4 =3D EXT4 partition for = userspace files<br class=3D""> > <br class=3D""> > <br class=3D""> > With u-boot being copied, next is the = kernel image and DTB file. =46rom the kernel<br class=3D""> > source execute :<br class=3D""> > <br class=3D""> > <br class=3D""> > $ mkdir ../mnt/<br class=3D""> > $ sudo mount /dev/sdX3 ../mnt/<br = class=3D""> > $ sudo cp arch/arm/boot/uImage ../mnt/<br = class=3D""> > $ sudo cp = arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/<br class=3D""> > $ sudo umount /dev/sdX3<br class=3D""> > <br class=3D""> > <br class=3D""> > Finally, we have to copy the Ubuntu = userspace filesystem that we created earlier:<br class=3D""> > <br class=3D""> > <br class=3D""> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a = ./precise/* mnt/$ sudo umount /dev/sdX4<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > Now,my idea is to chainload the already chain loaded u-boot created = by V.O.S to the new u-boot<br class=3D""> > that we need for booting FreeBSD and that can be installed in the = partition n.2,as shown in this<br class=3D""> > scheme,because it is not used :<br class=3D""> > <br class=3D""> > <br class=3D""> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot)<br = class=3D""> > Partition 2 =3D not used (maybe we can install the u-boot for arm = 32 bit,compatible with FreeBSD on<br class=3D""> > this partition)<br class=3D""> > Partition 3 =3D EXT2 partition for u-boot files (uImage and = exynos5250-snow.dtb)<br class=3D""> > Partition 4 =3D EXT4 partition for userspace files<br class=3D""> > <br class=3D""> > <br class=3D""> > Take in consideration that default boot string is hardcoded here,in = the snow.h file of the custom<br class=3D""> > u-boot created by VOS :<br class=3D""> > <br class=3D""> > <br class=3D""> > <a = href=3D"https://github.com/virtualopensyste...18a39b6c177dff58a/include/co= nfigs/snow.h#L101" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://github.com/virtualopensyste...18a39b6c177dff58a/include= /configs/snow.h#L101</a><br class=3D""> > <br class=3D""> > <br class=3D""> > and it needs to be recompiled because it should point to the = partition n.2,where I will install<br class=3D""> > the u-boot files as explained here :<br class=3D""> > <br class=3D""> > <br class=3D""> > <a href=3D"https://wiki.freebsd.org/arm/Chromebook" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://wiki.freebsd.org/arm/Chromebook</a><br class=3D""> > <br class=3D""> > <br class=3D""> > I have some questions to ask before I start working on this.<br = class=3D""> > <br class=3D""> > 1) The xen developer said :<br class=3D""> > <br class=3D""> > <br class=3D""> > You should be able to build U-Boot and = use the U-Boot binary as Xen guest kernel...<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > where is the u-boot binary,according to this document ?<br = class=3D""> > <br class=3D""> > <a href=3D"https://wiki.freebsd.org/arm/Chromebook" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://wiki.freebsd.org/arm/Chromebook</a><br class=3D""> > <br class=3D""> > I don't see it.<br class=3D""> > <br class=3D""> > <br class=3D""> > 2) where is the source code of the file that I can get here :<br = class=3D""> > <br class=3D""> > <a = href=3D"http://commondatastorage.googleapis.com/chromeos-localmirror/distf= iles/nv_uboot-snow-simplefb.kpart.bz2" rel=3D"noreferrer" = target=3D"_blank" = class=3D"">http://commondatastorage.googleapis.com/chromeos-localmirror/di= stfiles/nv_uboot-snow-simplefb.kpart.bz2</a><br class=3D""> > <br class=3D""> > I need the source code if I want to recompile u-boot so that it can = point to the partition 4.<br class=3D""> > <br class=3D""> > Maybe it can be found on this link :<br class=3D""> > <br class=3D""> > <a href=3D"http://linux-exynos.org/dist/chromebook/nv_uboot/" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://linux-exynos.org/dist/chromebook/nv_uboot/</a><br = class=3D""> > <br class=3D""> > but it can't be opened....<br class=3D""> > <br class=3D""> > <br class=3D""> > 3) in this specific scenario the source code of u-boot should run = on arm 32 bit,not on arm<br class=3D""> > 64,because I have the Samsung Chromebook "SNOW" model = XE303C12,that's powered by a Samsung Exynos<br class=3D""> > 5250 (ARMv7 32 bit Cortex A15) Soc.<br class=3D""> > <br class=3D""> > <br class=3D""> > 4) I'm not sure if I can chainload the customized u-boot created by = V.O.S that should be<br class=3D""> > installed on the first partition with the u-boot tailored for = booting FreeBSD that should be<br class=3D""> > installed on the partition 2....<br class=3D""> > <br class=3D""> > <br class=3D""> > 5) the xen developer said that u-boot should be compiled enabling = this option :<br class=3D""> > <br class=3D""> > <br class=3D""> > Code:<br class=3D""> > <br class=3D""> > CONFIG_CMO_BY_VA_ONLY=3Dy<br class=3D""> > <br class=3D""> > <br class=3D""> > Well,can you provide some good source that can help me to = understand how I can recompile u-boot<br class=3D""> > for FreeBSD ? thanks.<br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > <br class=3D""> > <br class=3D""> > --<br class=3D""> > Mario.<br class=3D""> > <br class=3D""> > </blockquote></div><br clear=3D"all" class=3D""><br class=3D""><span = class=3D"gmail_signature_prefix">-- </span><br class=3D""><div dir=3D"ltr"= class=3D"gmail_signature">Mario.<br class=3D""></div> </blockquote></div> </div> </div></blockquote></div><br class=3D""></div></body></html>= --Apple-Mail=_FA13BF8B-3EDB-4BA3-9811-F970864C33C7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54C44649-91A1-4A41-B2BA-FFCCACD0099D>