Re: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 6:20 PM, Shashvat wrote: > I don't know if it changes the answer to the question but it was not > intended as a GSOC application. > > I just needed a project to spend some time learning about the > architecture and how BSPs are built in general. Well, if you have spare cycles, then amd64 bsp screams for attention. If you like reading about architectures then amd64 will provide you with a plenty of documentation to deal with. If you like elegant architecture, then it would not be your cup of tea probably. If you like architecture history, then it'll be probably as it's rooted in early '80s. Also it's not easy architecture like some armv7 board. It's architecture tuned for server usage too and hence quite complex. On the other hand it's not architecture which would not innovate at all. Two examples: (1) interrupt controller: first PIC then two PICs together, then APIC, later xAPIC and even later x2APIC and even later some peripherals just give up and use MSI(-X). From RTEMS point of view MSI-X is most interesting due to lowest latency[1], but amd64 BSP will need to deal with x(2)APIC too just to be able to fire all the cores/threads anyway and due to some peripherals not supporting MSI(-X).[2] (2) firmware: first it was BIOS, then BIOS cloned into various forms. Later with 80386 IBM come with idea to have OS booted right into 32bit (protected mode of the new 386 CPU). It happened on a few IBM PS/2 models and IBM even promised to fully document this which I'm not sure if happened at all since market was flowing in different way. Much later Intel came and did what IBM promised long time ago by porting their EFI (from Itanium) to x86 and this allows modern PCs to look like real 64bit machines from the startup -- except few exceptions you will be able to forget about all those 8086isms and 80386isms since you are right into long mode of blessed AMD64. :-) But or so, even if x86 is quite complex, there are still people tinkering with it and writing toy/example OSes, so this is certainly manageable. Hobby site known for x86 support is osdev.org[3], so definitely a lot of resources available and happy to be consumed if you have just some free time... Good luck! Karel [1]: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/msg-signaled-interrupts-paper.pdf [2]: https://habr.com/en/post/446312/ [3]: https://wiki.osdev.org/Expanded_Main_Page ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
On Mon, Mar 29, 2021 at 11:23 AM Shashvat wrote: > > I don't know if it changes the answer to the question but it was not intended > as a GSOC application. > It does not. I just want to be aware of what's coming in for GSoC. Thanks. > I just needed a project to spend some time learning about the architecture > and how BSPs are built in general. > > Regards > Shashvat > > On Mon, Mar 29, 2021 at 9:27 PM Gedare Bloom wrote: >> >> On Mon, Mar 29, 2021 at 1:28 AM Shashvat wrote: >> > >> > Hello everyone ! >> > >> > I wanted to know the status of the x86_64 BSP's development. >> > Also it would be great help if someone guides me to get it running on QEMU >> > or my x64 based laptop running legacy BIOS.(not UEFI) >> > >> Is this intended for a GSoC application, or just fun/profit? >> >> > >> > Regards >> > Shashvat >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
I don't know if it changes the answer to the question but it was not intended as a GSOC application. I just needed a project to spend some time learning about the architecture and how BSPs are built in general. Regards Shashvat On Mon, Mar 29, 2021 at 9:27 PM Gedare Bloom wrote: > On Mon, Mar 29, 2021 at 1:28 AM Shashvat > wrote: > > > > Hello everyone ! > > > > I wanted to know the status of the x86_64 BSP's development. > > Also it would be great help if someone guides me to get it running on > QEMU or my x64 based laptop running legacy BIOS.(not UEFI) > > > Is this intended for a GSoC application, or just fun/profit? > > > > > Regards > > Shashvat > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
On Mon, Mar 29, 2021 at 1:28 AM Shashvat wrote: > > Hello everyone ! > > I wanted to know the status of the x86_64 BSP's development. > Also it would be great help if someone guides me to get it running on QEMU or > my x64 based laptop running legacy BIOS.(not UEFI) > Is this intended for a GSoC application, or just fun/profit? > > Regards > Shashvat > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 2:41 PM, Karel Gardas wrote: > 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. My original report is here: https://lists.rtems.org/pipermail/devel/2020-December/063878.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 2:41 PM, Karel Gardas wrote: > 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. One very important bit! You also need to tick/switch-on PAE support box. Without it, VBox would assert/crash on RTEMS execution. Please note: VBox allows you to configure serial port and you can forward its output to the file -- so you are able to see output of the RTEMS app running there... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
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 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. 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. 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
Re: x86_64 BSP : Status Update [ticket #2898]
I linked the wrong GSoC status update of mine there - here's the final report that you may find useful: https://blog.whatthedude.com/post/gsoc-final/#future-to-do On Mon, Mar 29, 2021 at 3:38 PM Amaan Cheval wrote: > > Hey Shashvat! > > I've CC'd Chris who may have something to add given that the original > ticket seems to have an update from John Millard - not sure if John's > made progress since my work on the x86-64 BSP was upstreamed, so I'll > let Chris speak to that. > > I wouldn't recommend running it on real hardware yet - I don't think > anyone has tested it on hardware. > 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 > > 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. > (For eg. most Linux systems can't mount UFS/ZFS unless specifically > compiled for that support, which means the dev-environment is quite > hacky and slow - I had to use the network to get my RTEMS apps into > the FreeBSD filesystem for the bootloader to use it.) > > After the bootloader issues are made easier (so we don't need to > replace FreeBSD's kernel every time we want to recompile our RTEMS app > and re-run it), the next aim will probably be to make as many tests > pass as possible, and to improve automated tests, such as a > configuration for rtems-test[1]. > I recall there being some edge-cases in the clock driver, so you'll > likely have the failing tests to guide which drivers you need to work > on in the BSP. > > 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.). > > In case you haven't seen this already, this is my blog post from my > GSoC on the x86-64 BSP, summarizing the status as of then, as well as > potential areas for improvement next: > https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming > > [1] https://docs.rtems.org/branches/master/user/tools/tester.html > > On Mon, Mar 29, 2021, 12:58 PM Shashvat wrote: > > > > Hello everyone ! > > > > I wanted to know the status of the x86_64 BSP's development. > > Also it would be great help if someone guides me to get it running on QEMU > > or my x64 based laptop running legacy BIOS.(not UEFI) > > > > > > Regards > > Shashvat > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
Hey Shashvat! I've CC'd Chris who may have something to add given that the original ticket seems to have an update from John Millard - not sure if John's made progress since my work on the x86-64 BSP was upstreamed, so I'll let Chris speak to that. I wouldn't recommend running it on real hardware yet - I don't think anyone has tested it on hardware. 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 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. (For eg. most Linux systems can't mount UFS/ZFS unless specifically compiled for that support, which means the dev-environment is quite hacky and slow - I had to use the network to get my RTEMS apps into the FreeBSD filesystem for the bootloader to use it.) After the bootloader issues are made easier (so we don't need to replace FreeBSD's kernel every time we want to recompile our RTEMS app and re-run it), the next aim will probably be to make as many tests pass as possible, and to improve automated tests, such as a configuration for rtems-test[1]. I recall there being some edge-cases in the clock driver, so you'll likely have the failing tests to guide which drivers you need to work on in the BSP. 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.). In case you haven't seen this already, this is my blog post from my GSoC on the x86-64 BSP, summarizing the status as of then, as well as potential areas for improvement next: https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming [1] https://docs.rtems.org/branches/master/user/tools/tester.html On Mon, Mar 29, 2021, 12:58 PM Shashvat wrote: > > Hello everyone ! > > I wanted to know the status of the x86_64 BSP's development. > Also it would be great help if someone guides me to get it running on QEMU or > my x64 based laptop running legacy BIOS.(not UEFI) > > > Regards > Shashvat > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
x86_64 BSP : Status Update [ticket #2898]
Hello everyone ! I wanted to know the status of the x86_64 BSP's development. Also it would be great help if someone guides me to get it running on QEMU or my x64 based laptop running legacy BIOS.(not UEFI) Regards Shashvat ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
