On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns <chr...@rtems.org> wrote: > On 08/06/2018 01:50, Amaan Cheval wrote: >> >> Joel, Chris, I'd appreciate guidance on what I ought to work on next > > I would like to see the focus on the kernel context switcher, FPU support, and > then interrupts so we have the basic drivers we need like a tick interrupt > running. > > This assumes the loader issues we have not resolved do not effect this work. >
They do affect it to a certain extent - I'd be working semi-blind since without tying the loose ends required to boot, I wouldn't be able to test the implementations of the areas you mentioned. I'm not at that point yet, but I suspect I will be within a week or so, so the sooner we determine the approach required for booting, the better. >> and what >> discussions we need to have to decide between the "bundled kernel.so >> approach" >> (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe" approach. >> Let >> me know! >> > > I do not think I can help too much here. I understand the loader.efi+exe > solution and it should work because all RTEMS applications we have are > statically linked (I am assuming it is here). I have not looked at the details > being used with the -fPIC and .so solution so I cannot comment. I do have some > concerns the relocatable exe might expose some dark corners and issues in the > host tools we have, for example how does GDB find the base address of the > image > so you can debug it? and is this just working or is it really suppose to work > this way? Well, these images won't simply _run_ through GDB, no - but here's some stuff that may be helpful to see: https://gist.github.com/AmaanC/4e1aaa2cbdda974b93c5a3e1eac5318a One concern of yours was the unnecessary addition of the GOT/PLT. Thankfully, through options like -Bsymbolic, we can circumvent the GOT/PLT for all symbols which have already been resolved (as you'll see happens for "InitializeLib", "Print", "boot_card", etc. (boot_card because this is from my WIP version trying to get boot_card to work with this method too)). I'm definitely concerned, but having looked at it more, I can't find anything specific that would genuinely cause problems besides unresolved symbols - we could have a build-time check for them, though, failing the build when that's the case (-Wl,-z,defs does it). So for next steps, I guess you'll be looking into how the use of -fPIC may affect us, and we can work on addressing those concerns, right? I personally preferred the static build approach too, since that way we can "plug" loaders in: - loader.efi for UEFI firmware - multiboot header + 32 to 64 bit mode code for Multiboot That's a slight oversimplification since (1) needs to be packaged on the filesystem with the static hello.exe and (2) needs to be linked in with it, but I think the build system retains more of its separations from the boot method this way (though I can't be sure given my relatively naive view of RTEMS + autotools). > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel