On 3/29/21 12:08 PM, Amaan Cheval wrote: > I wouldn't recommend running it on real hardware yet - I don't think > anyone has tested it on hardware.
I did and reported to the mailing list. Generally speaking works on some systems (both demos: hello/ticker) and another it causes general protection fault on an attempt to disable legacy interrupt controller. Advice on osdev was that using 1GB pages may be problematic so I should switch to 2M pages at least for test. Still slacking on this one as I'm overloaded in real life. > Not all tests in the testsuite pass in QEMU either, from what I > remember (some basic ones do), so that will likely be what you'll need > to work on. > > To run the BSP in QEMU, you'll need to follow these instructions: > https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html > > Let me know if you run into any issues, since the setup can be a bit > complicated. In summary, for the setup, you'll want to: > > - Build RTEMS/RSB with x86-64 as the BSP (this should be the same as > what you did for your GSoC proof in terms of building the BSP and > samples/tests) > - Get QEMU > - Build OVMF's open-source UEFI firmware > - Get FreeBSD booting in QEMU with UEFI, and then replace it's > `kernel` with a built RTEMS application (such as the ticker tests or > hello.exe, etc.) > - Run FreeBSD image with RTEMS app as its kernel Or! Install VirtualBox, install FreeBSD into it but before it make sure you tick/switch on UEFI box and then install. Once done you do have FBSD working in UEFI environment. The advice on replacing kernel is not needed as you can select rtems binary dynamically from the bootloader command line. Simply: boot to boot loader and hit '3' to get into boot loader prompt then type: boot <path to your rtems binary> and hit ENTER key and it'll boot, e.g.: boot /boot/rtems/hello.exe works here. > We need to do this because for the x86-64 BSP, we use FreeBSD's > bootloader. This is slightly problematic, because FreeBSD's bootloader > only supports UFS/ZFS for filesystems. > I think ideally, we'll want a UEFI-compatible bootloader which can > support more filesystems - FreeBSD's bootloader is functional, but > perhaps not the best for a dev/prod environment long-term - maybe > Joel/Chris can comment on this. <rant>This is quite personal note, it basically depends where you develop. If in FreeBSD, then its boot loader is best option since you only need to copy rtems binary into /boot somewhere and reboot for test.</rant> Anyway, I've tested also bootboot but this has not worked well e.g. not at all. GRUB probably requires multiboot support which is a step back from UEFI. I have multiboot bits done here but not tested as I've moved to real UEFI work later. I've also investigated compiling RTEMS binary directly into PE+ but this requires PIC for all code (which Chris does not like and which may be a bit problematic -- e.g. asm needs to be fixed in some places). You have written somewhere that you have been able to do that, but I was not able to duplicate your success with it. So I think the best option is to use current freebsd bootloader for now and then perhaps test other real UEFI/64bit loaders (slimboot comes to mind). If not satisfied then write own wrapper/boot loader support which will be compiled together with rtems app and it'll then relocate its ELF code properly and boot. Zephyr provides some python code for generating such wrapper. https://github.com/zephyrproject-rtos/zephyr/tree/master/arch/x86/zefi Note: if would be fantastic if RTEMS have the capability to call UEFI so it would be best if bootloader does not call ExitBootServices() before booting RTEMS. Well if it does, then still calling UEFI is nice to have to for example: - grab resolution and address of framebuffer -- which is way much better than VESA fb in pc386 BSP IMHO. - grab IP address from possible network boot - set/check for nvram values. > If there's still time after that, I think we can figure out which > specific portions need to be worked on (i.e. running on hardware, > improving existing drivers, adding libbsd support, SMP support, etc.). I think the issue summary summs that very well. What we need for working amd64 support is we need to grab required ACPI regs/tables to get memory ranges and APICs configuration details, better paging (e.g. hopefully 2M below 4G and then 1GB pages on top of that? -- depends on experiment above), LoAPIC/APIC support in minimum but rather MSI(-X) where supported. Use available bsd code as much as possible... Note: I spent some time in FBSD code, I'm most interested in passing r/xsdt + UEFI addr from fbsd loader to RTEMS app due to a need to grab right memory map and UEFI fb addr/resolution. I've seen a lot there, but so far not materialized any code for it -- especially since fbsd boot loader is a bit complex due to a need of supporting loadable modules (besides kernel). Thanks, Karel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
