[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Booting the FreeBSD kernel as an zImage file needs a patch upgrade ?.
I still see too many variables in the equation. I need to eliminate some of them. So : 1) Do I need to patch the file locore-v6.S with the Julien's patch ? ---> https://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=commit;h=12a7cb346b88c6d3f52a20b98f361dc62797fbcd 2) What kind of u-boot are you talking about ? Where should I get it ? @balanga (a nice enthusiastic 'hacker') helped me to solve half part of the u-boot equation,giving to me this suggestion : "If you simply want me to extract : http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/11.2-RELEASE/src.txz and run make TARGET_ARCH=armv5 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel" so,theoretically in this way I have the ARMv5 rootfs (and the freebsd kernel file) that will boot with the proper version of u-boot,as has been explained here : https://forum.doozan.com/read.php?3,49039,136530#msg-136530 "Whether you use "go" or "bootelf ", you will need to have some knowledge about what files are the kernel files in your ARMV5 rootfs. The BSD rootfs must be built for this architecture. And how to pass parameters to the kernel bootelf with API is more powerful, "go" is primitive" The other half part of the equation is related to u-boot. On the doozan forum has been explained that has been created the Kirkwood (Armv5) u-boot. I've asked the link where to grab it,because I could try to chainload "ubldr" using that version of u-boot with the ARMv5 rootfs that balanga explained to me how to create. I could try,but I don't see the utility. Infact armV5 is dead as well as FreeBSD 11.2 for i386. I think that to follow the road of using u-boot for Kirkwood is a waste of time. I think that the right thing to do is to fix the main problems which FreeBSD is affected by : that it can't be booted as an zImage file by xen. It needs to be patched. And there are some missing hypercalls for arm32. Using u-boot for armV5 complicates things a lot and forces me to use a dead version of FreeBSD. On Mon, Jan 1, 2024 at 9:48 PM Warner Losh <imp@xxxxxxxxxx> wrote: > > So kernel.bin is expected to be loaded, by u-boot, using the 'load' command > at a specific address. On arm, this can be any 2MB boundary. Once it is > loaded, you jump to the _start address woth the 'go' command. The kernel.bin > file doesn't have symbols, so you'll need to see where _start winds up at. > > So, let's say that the memory starts at 0x80000000 and _start is something > like 0xc0000020 when you nm kernel | grep start you'd do something like: > > u-boot> load kernel.bin 0x80000000 > u-boot> go 0x80000020 > > Though I'm unsure what u-boot will read the kernel.bin from. Maybe xen can > load it at a specific spot (and maybe your hunch is right that you can > replace uboot with this binary... ive never xen booted like this so i don't > know if you need the low level steps uboot preforms to be done or not). I > suspect that it might and my info is just for raw hardware... > > Warner > > On Mon, Jan 1, 2024, 12:47 PM Mario Marietto <marietto2008@xxxxxxxxx> wrote: >> >> Thanks Warner. But the kernel.bin file should be used instead of the u-boot >> file as bootloader ? and will it work as expected ? even if i have patched >> the elliott code with the wrong patch ? thats because I havent a working >> patch to use that can allow the frrebsd code to be threated as an zImage >> file ? >> >> Il lun 1 gen 2024, 20:39 Warner Losh <imp@xxxxxxxxxx> ha scritto: >>>> >>>> Julien said that I could try to revert the commiting removing the step >>>> to create kernel.bin,but I don't know what it means,I don't know how >>>> to do that and I haven't found anyone who wants to explain to me how >>>> to do it. And I'm not sure that it will be enough. >>> >>> >>> You need to add WITH_KERNEL_BIN for it to generate a kernel.bin file. >>> We turned that off by default since most people don't need/can't use that >>> file. >>> >>> Warner -- Mario.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |