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