On Tue, Mar 20, 2018 at 8:23 AM Chris Johns <chr...@rtems.org> wrote:
> On 19/03/2018 18:36, Amaan Cheval wrote: > > Thanks for checking the tool status! > > > > TLS support for the tool seems okay to me as well - I see the TLS program header > > and the "T" flag for the ".tbss" section header, as you'd expect in the ELF. I > > haven't looked into the run-time support for TLS in RTEMS yet - is there > > something I need to dig into there? > > > > How do we determine if we need multilib support? > > > GCC should be able to dump it configuration, try adding `--print-multi-lib`. No multilibs were found for me, in that case. Output was ".;". What determines whether we need it or not? Is it based on whether we think of x86_64 as a BSP for the i386 arch vs. it being its own, new arch + BSP? (Since multilib, the way I understand it, would allow us to compile for 32-bit as well.) In that case, I believe we've settled on new arch + new BSP, right? > >> I'd encourage you to flesh out > >> the plan for one of the "bonus" areas for this phase. That way, if you > >> reach it, you will be prepared to undertake it without having to think > >> too hard about the design aspects. > > > > I've added a few bullets about SMP support and it's SMP-specific APIC related tasks. > This requires bringing code in from FreeBSD which includes Intel code to manage > these tables. Good point. I've added what seem to be the relevant FreeBSD sources to the resources listed in the proposal: - https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/local_apic.c#L498-L503 - https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/apic_vector.S (Assuming that by tables you meant the Local Vector Table, etc., and not the ACPI's MADT, which is relevant to SMP in that it contains a list of LAPICs, thereby letting us find how many cores are available.) > > > >> FYI one step I do for new ports is to get to the point where I can link all tests with stubs or first quick cuts at the port and bsp. > > > > That's a good tip! I've added that to the phase 1 deliverable, since it seems > > like an important step - I'll aim to get here much sooner, though. > > > >> I have always thought the first part of this project would be to get > >> an UEFI "hello world" running on Qemu. That is the entry point to the > >> BSP and as Chris pointed out, there is a fair amount of work just > >> to ensure you can do prints to the optional video and later serial port. > > > > The UEFI "hello world" would be achievable through a minimal BSP (primarily > > boot/init code) and stubs for the rest (console, idle thread clock, fake > > context-switching & ISR handling), right? > In theory. We need to resolve the way we build the UEFI header as listed in the > ticket for this task. > >> All that should be doable and testable on qemu. > > > > Sweet! A question about hardware requirements; how do you guys usually test and > > debug hardware problems? > What is involved in booting on qemu with UEFI + 64bit? Besides needing OVMF for UEFI, I don't think there should be any issues in that regard. I'm also familiar enough with QEMU (since we use it a fair bit as an "oracle" to be compared to our x86 emulator at work), so I think we should be able to resolve this setup before the GSoC coding period starts. > > Is there any equipment I'll likely need or should look > > into (JTAG)? > Not that I know of. Intel has a different JTAG like protocol on it's Atom > devices available under NDA some commercial debuggers support. > Qemu is nice because you get a built in debugger that lets you step around these > early bootloader instructions. Ah, yes. I'm particularly wary of issues we run into where it runs in QEMU but not on actual hardware - I imagine we'll need to go old school and just stare hard at the code, throw in "printf"-likes (speaker, VGA, whatever we have control over, depending on what stage the issue occurs at). > > > > Besides, what should I verify about the computers I do have, besides them having > > UEFI firmware? > > > Not too much. Being about to run on a Minnow board would be nice. I don't own a Minnow board. Would testing through someone in the RTEMS community who does be okay? I believe my primary desktop (64-bit) does include UEFI firmware. My secondary MacBook (64-bit) has EFI, I believe. Understandably, I'd rather not have to tinker too much with my primary desktop, but I'm okay to for when we have to, given that I have backups in place. > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
