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


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

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

Indeed it does.


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

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

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

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

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

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

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

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

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

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

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

=
Warner

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


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

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

Hi Mario,

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

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

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

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

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

Cheers,

Stefano


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


--
Mario.

--000000000000703ceb060cf8caea--