<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 14, 2018, 6:08 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for your input, everyone! I appreciate it! :)<br>
<br>
On Thu, Jun 14, 2018 at 11:25 AM, Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
> On 14/06/2018 05:33, Joel Sherrill wrote:<br>
>> On Wed, Jun 13, 2018, 6:57 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a><br>
>> <mailto:<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>>> wrote:<br>
>><br>
>> On Wed, Jun 13, 2018 at 9:35 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a><br>
>> <mailto:<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>>> wrote:<br>
>> > On Wed, Jun 13, 2018 at 11:33 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a><br>
>> <mailto:<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>>> wrote:<br>
>> >> Hi!<br>
>> >><br>
>> >> As we discussed in the last thread on the topic[1], I'm trying to use<br>
>> >> FreeBSD's loader.efi directly with RTEMS' generated static binaries<br>
>> >> (since FreeBSD's loader.efi has an ELF loader).<br>
>> >><br>
>> >> In brief, I did this by:<br>
>> >> - Installing FreeBSD in QEMU with UEFI firmware<br>
>> >> - Confirming that FreeBSD's loader.efi is in fact used<br>
>> >> - Replacing FreeBSD's ELF kernel with a "custom" kernel[2] with an RTEMS ELF<br>
>> >> - Verifying that the code running after FreeBSD's loader.efi is in<br>
>> >> fact the "RTEMS ELF" by attaching gdb to QEMU (the rtems ELF is simply<br>
>> >> a while(1) loop compiled with RTEMS' tools - see later on why I can't<br>
>> >> do something more elaborate)<br>
>> >><br>
>> >> Some more details of the process I followed for testing this:<br>
>> >> <a href="https://gist.github.com/AmaanC/42faa131ee97a1d6c4c7c25c29f0fde9z" rel="noreferrer noreferrer" target="_blank">https://gist.github.com/AmaanC/42faa131ee97a1d6c4c7c25c29f0fde9z</a><br>
>> >><br>
>> >> I think this method is superior to the PIC RTEMS method because:<br>
>> >> - FreeBSD uses it<br>
>> >> - RTEMS retains static ELF binaries, which can likely easily be<br>
>> >> combined with a Multiboot header + protect mode starter code<br>
>> >> - FreeBSD has methods to provide ACPI related hints to their ELF<br>
>> >> kernel - this might make our implementation with regards to ACPI<br>
>> >> simpler too<br>
><br>
> I agree this is the best approach. In time we can host on our file server a<br>
> package of FreeBSD binaries that boot an RTEMS kernel.<br>
><br>
>> >><br>
>> >> Regarding some concerns Chris had with linker options and whatnot,<br>
>> >> here's what FreeBSD uses:<br>
>> >> <a href="https://www.freebsd.org/doc/en/books/arch-handbook/boot-kernel.html" rel="noreferrer noreferrer" target="_blank">https://www.freebsd.org/doc/en/books/arch-handbook/boot-kernel.html</a><br>
>> >><br>
>> >> Here's what I used (with the code being a simple while(1) loop):<br>
>> >> x86_64-rtems5-gcc ktest.c -c -nostdlib<br>
>> >> x86_64-rtems5-ld ktest.o -e main -o kernel<br>
>> >><br>
><br>
> Nice, this looks fine. It is normal for a bare metal piece of C code.<br>
><br>
>> >><br>
>> -------------------------------------------------------------------------------------<br>
>> >><br>
>> >> What I need input on:<br>
>> >> - Right now, we use the following RTEMS code for testing:<br>
>> >><br>
>> >> int main() {<br>
>> >> while(1) {}<br>
>> >> }<br>
>> >><br>
>> ><br>
>> > It's not really an RTEMS code, it is a C program (ktest.c) compiled<br>
>> > with the RTEMS-flavored toolchain, right?<br>
>><br>
>> Yeah, for now that's right. I'm going to conduct the same gdb based<br>
>> debug-stepping style test for RTEMS setting boot_card as the entry<br>
>> point soon - for now, it crashes QEMU with:<br>
>><br>
>> qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000b0000<br>
>><br>
>> RAX=00000000006004c0 RBX=00000000006003d8 RCX=0000000037f36000<br>
>> RDX=0000000000400000<br>
>> RSI=0000000004000000 RDI=0000000000000180 RBP=00000000006003d8<br>
>> RSP=000000003c589fb8<br>
>> ...<br>
>><br>
>> I see that it reaches that stage even from some code it ought not to<br>
>> be executing, so I'll look into what that may be about.<br>
<br>
It was quite simple, really - my stub doesn't define<br>
_CPU_Context_restore yet - rtems_initialize_executive calls that<br>
function expecting it to never return, but when it does, we lose<br>
control and just start running code from virtual address 0 (or<br>
possibly whatever happens to be on the stack as the return instruction<br>
pointer).<br>
<br>
What we _do_ know is a positive sign, though - an actual RTEMS static<br>
binary does seem to be loaded just fine, and starts executing too,<br>
until we call _CPU_Context_restore and lose control.<br>
<br>
Next up: I'll work on the context-switching code to move past this,<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You will need context initialize and restore to get through initialization to the first task. You might as well complete all of the methods related to non-FP contexts and see if you can run base_sp. It may even call shutdown so you can do that.</div><div dir="auto"><br></div><div dir="auto">But getting to a user init task would be success and return to printk.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and then we can follow the original plan in my proposal<br>
(context-switching, basic IRQ, idle thread based clock driver,<br>
printk/console support - I'd like to get to the console driver as soon<br>
as is viable - I could work on it directly outside of the RTEMS static<br>
binary, using the "ktest" style kernel I mentioned earlier, but I<br>
think we'd rather make progress directly on the BSP first).<br>
<br>
><br>
> Hmm.<br>
><br>
>><br>
>> ><br>
>> > It would be nice to get an RTEMS x86-64 BSP to start, at least to<br>
>> > confirm that you reach _start, and then even you can try to make it to<br>
>> > the "boot_card" startup sequence.<br>
>><br>
>> Right, I'll aim to have that working soon (using boot_card as the<br>
>> entry, since "_start" usually does the bootloader stuff that we're now<br>
>> offloading to FreeBSD, and then calls boot_card anyway).<br>
>><br>
>><br>
>> To be consistent with other BSPs, I have a start.c on the Deos BSPs. It fetches<br>
>> the boot arguments which are passed to boot_card() and does some other setup<br>
>> specific to Deos.<br>
>><br>
>> No need to do this now but there is a good reason to follow the pattern. Start<br>
>> doesn't have to be in assembly.<br>
<br>
Noted for the future, thanks!<br>
<br>
>><br>
>><br>
>> ><br>
>> >> That's literally it, because we have no access to standard libraries,<br>
>> >> and loader.efi calls ExitBootServices, after which we can't just<br>
>> >> easily directly access video memory (at 0xb8000 for eg.) to print to<br>
>> >> the screen. The way FreeBSD handles this is by initializing the<br>
>> >> console and printing to that - I haven't been able to easily port that<br>
>> >> yet.<br>
>> >><br>
>> >> The question is - should I start with that effort (i.e. bringing<br>
>> >> printk console functionality to RTEMS) the way FreeBSD does? This way,<br>
>> >> we skip the bootloader for now by simply using the one built on the<br>
>> >> real FreeBSD - if the console prints and more elaborate linking tests<br>
>> >> work fine, we can be certain that this works. If _not_, I believe the<br>
>> >> console initialization code will likely still remain the same since<br>
>> >> we'll want to do it similar to how FreeBSD does it.<br>
>> >><br>
>> ><br>
>> > I think this approach to getting a console to work may be reasonable,<br>
>> > assuming the FreeBSD console is not much more complicated than what<br>
>> > RTEMS needs. ...<br>
>><br>
>> I can't say about this yet, but I'll look into it (and perhaps<br>
>> simplifying it as we port it if it _is_ too complicated).<br>
>><br>
><br>
> It has been a couple of years but I think FreeBSD contains some of the Intel<br>
> code to interface to UEFI and via this you can get to the UEFI console. This<br>
> should be easy but it comes with a side effect.<br>
><br>
> UEFI boots in graphics mode and so it's console on a PC is a slow scroll one. On<br>
> boards like a Minnow using the UEFI console has the advantage of being able to<br>
> support any redirection UEFI has enabled such as a serial port. The disadvantage<br>
> of this is performance and overhead. In time this may be a boot option.<br>
><br>
> What I am not sure is the boundary between UEFI and the kernel and what is<br>
> enabled or available when the kernel is loaded.<br>
<br>
<br>
That's good information, thank you! I'll look into it as I can - for<br>
now, can we settle on these for next steps?<br>
<br>
- We're using FreeBSD's loader.efi - to do so, we just need our BSP to<br>
generate static ELFs, so nothing needs to go in the source tree<br>
- I'll focus on the context-switching code for the BSP next, aiming to<br>
get it to actually reach bsp_start - once that's done, we can focus on<br>
the console output (this means that until then, verifying the progress<br>
will likely still be done through emulators and debuggers).<br>
<br>
Let me know!<br>
<br>
><br>
>> ><br>
>> >> What do you think?<br>
>> >><br>
><br>
> Awesome work.<br>
> Thanks<br>
> Chris<br>
</blockquote></div></div></div>