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


On Wed, Dec 20, 2023, 4:07=E2=80=AFPM Mario Marietto &= lt;marietto2008@gmail.com> wrote:
Warner,you didnt read one of my last email,wher= e i said that i have fixed that bug and I can boot my freebsd image with qe= mu and even the network interface works well. I remember to you that my pro= ject is to boot freebsd under xen. Thanks.

I do... but I've not been a= ble to locate your fix....=C2=A0 I do know it's not relevant to these r= est of this thread.

I= 9;d hoped the .fd files from EDK II might be helpful instead of uboot... bu= t now I'm less sure it would be useful...

Warner

Il mer 20 dic 2023, = 23:49 Warner Losh <imp@bsdimp.com> ha scritto:

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

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

=
Indeed it does.


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

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

I'd think you'd need the right virtualizatio= n loader. I'm not entirely sure the u-boot.bin you've been creating= is for a dom-u..=C2=A0
If I misunderstood, then the below isn= 9;t good advice. Chain booting the u-boot, the first u-boot initializes thi= ngs so you want
to start with stage after the SPL But the differe= nt error messages suggest that it's trying to reboot with kexec, which<= /div>
isn't supported on armv7 at the moment.

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

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

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

So, I did the following to boot the virtualized armv7 FreeBSD environ= ment, following a post on the forums I found and knew to have the right rec= ipe:

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

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

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

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

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

Warner

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

https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_f= reebsd_for_arm32_bit_as_domu_with/

Maybe his a= nswer can be useful to understand why it does not work.
On Tue, D= ec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini <sstabellini@kernel.org> wrote:
+Michal

Hi Mario,

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

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

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

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

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

Cheers,

Stefano


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


--
Mario.

--0000000000009a6559060cf9214e--