Hi Yang, (Aside: Apologies if I am using the wrong name part. Please do correct my usage)
Many thanks for your replies and looking into my report. Below I have tried to answer your queries and some more information about what I tried. Yang Chung Fan <sonic.tw...@gmail.com> writes: > Hi, > > I have tested it on my machine. > > Using commit deb3b13759fe08 , I can successfully boot into nsh. Thanks a lot for confirming that this commit works for you. > In addition, may I have your processor model please. I am using an i7-3770 for my testing. Looking at the flags in /proc/cpuinfo, it does have support for "vmx", "tsc" and "x2apic". Are there any other cpu features I should look out for? I am not sure the CPU features that the early boot code is depending upon. >> Single stepping through the early startup code >> (arch/x86_64/src/intel64/intel64_head.S) suggests an unhandled exception >> is taken at the start of __nxstart. Considering the code has a comment >> indicating that it's executing from high memory, I am guessing an issue >> with the memory setup before getting here is causing an issue. > > The processor has triple faulted and resets itself. > That's why it is looping. > I can think of a GP or a PF Fault happening during booting. Right - I suspected something like this is happening but am not very familiar with x86 architecture. I will try and dig into the page table setup and see if I can get any syndrome information for the fault(s). Hopefully it will give a clue to the problem. [...] > I have seen aliked looping problem during porting, mainly due to > improperly setup GPT causing GP or page table causing PF. > > I suppose you didn't modify the code, therefore it seems strange to > me. No changes - just straight up clone from the repository. I wanted to make something work before attempting changes. > For your reference, the following are my environments. > > Build machine: > - Windows10 WSL2 18.04 > - gcc (Ubuntu 9.3.0-11ubuntu0~18.04.1) 9.3.0 > > Execute machine: > - Ubuntu 18.04 > - Xeon 2650 v4 / 16GB > - Custom compiled kernel: > - Linux rtlab-linux 5.4.39-rt23+ #1 SMP PREEMPT_RT Mon May 11 > 22:10:55 JST 2020 x86_64 x86_64 x86_64 GNU/Linux > - Custom compiled Qemu: > - QEMU emulator version 4.2.0 (v4.2.0-dirty) Did you need any changes to Qemu to make the x86_64 port work? To eliminate Qemu version differences, I tried with Qemu v4.2.0 but got the same reboot loop as before. I also tried Qemu in emulation mode (without kvm) and that went quite a bit further. Goes into an infinite loop after failing to find a x2apic in x86_64_check_and_enable_capability(). The emulation is only partial and doesn't implement recent cpu features / system level peripherals. Do let me know if you can think of anything else I can check. Thanks, Punit [...]
