<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 16, 2023 at 4:56 PM Karel Gardas <karel@functional.vision> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Folks,<br>
<br>
I just send my amd64efi BSP results for review. One of the commits (with <br>
BSP actually) awaits moderator approval due to size so before it gets in <br>
let me add few remarks about how to make that BSP working on either Qemu <br>
or real hardware.<br></blockquote><div><br></div><div>This is all great news! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
CAVEAT: We have serious issue somewhere between kernel, newlib and gcc <br>
which causes SSE aligned isns to work on unaligned data causing general <br>
protection fault. This issue is serious and needs to be investigated in <br>
the future by anyone working on amd64. To workaround the issue I did:<br></blockquote><div><br></div><div>This generally sounds like a pervasive issue which is historically tied to</div><div>needing some changes to compiler arguments or something odd like </div><div>aligning the stack more strictly. But your example below is not stack</div><div>related so that's not the entire issue. </div><div><br></div><div>I looked at the output of waf bspdefaults and I don't see any arguments for</div><div>the ABI CFLAGS. That leaves at least the SSE and CPU model revision</div><div>to be defaulted which is not a good thing usually.<br><br>There are LOTS of x86_64 options for SSE which per this stack overflow </div><div>article appear to factor into this:</div><div><br><a href="https://stackoverflow.com/questions/38443452/alignment-and-sse-strange-behaviour">https://stackoverflow.com/questions/38443452/alignment-and-sse-strange-behaviour</a><br></div><div><br></div><div>This is an old bug report but one suggestion is that the stack be 16-byte aligned</div><div>along with some other hints.</div><div><br></div><div><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=12123">https://sourceware.org/bugzilla/show_bug.cgi?id=12123</a><br></div><div><br></div><div>I'm leaning to multiple causes under the hood for unaligned data being</div><div>passed to some SSE enabled routine. Unfortunately, if you can get the</div><div>faulting address, we can probably figure out what GCC is doing. This</div><div>may simply require tweaking the compiler settings internally some to</div><div>increase alignment by default.</div><div><br></div><div>If you have some small code example which fails, perhaps compiling</div><div>it to assembly with the RTEMS and Linux GCC's and seeing how items</div><div>are aligned will give a hint. </div><div><br></div><div>For sure, this isn't something we want to address on a case by case basis.</div><div>The alignment is not strict enough for 1+ broad reasons.</div><div><br></div><div>One odd thought to keep in mind is that I don't know how many people</div><div>use the x86_64-elf GCC and tools configuration. Lots use say arm-eabi</div><div>but how many people are using this bare metal configuration? I vaguely</div><div>recall that I may be the author of the GCC configuration which means</div><div>it is only used by this RTEMS build and BSP. So a mistake in making the</div><div>simple configuration is not out of the question.</div><div><br></div><div>Your patch hints that we may need to figure out how to increase the</div><div>default alignment on a data item in the compiler configuration.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- few "fixes" here and there as required by GP crash reports on <br>
hello/ticker/malloctest tests. Those are only tests I have working here. <br>
The patch for those fixes is attached. This is *NOT* something for <br>
review or commit, this is just *WORKAROUND* to get interested people up <br>
& running!<br>
<br>
- unfortunately the issue above not only affects RTEMS kernel, but also <br>
tools' newlib. Hence there is a need to build a new newlib. I simply <br>
obtained newlib from git as the 6/rtems-x86_64 is pretty close to HEAD <br>
of newlib anway and compile that with RTEMS GCC (installed by RSB). When <br>
this is compiled I touched newlib/libc/stdio/findfp.c and recompile it <br>
again, but this time with adding '-mgeneral-regs-only' GCC option. This <br>
is needed since unalignment of data happens when using this:<br>
<br>
30<br>
31 __FILE __sf[3];<br>
32<br>
<br>
and the GCC does not have any attribute which would help with this <br>
unless the code is rewritten to get rid of array construct here.<br>
Anyway, using only general purpose regs here is quick and easy workaround...<br>
<br>
And that's about all needed to get hello/ticker/malloctest working. Just:<br>
- configure (config file defaults should be more or less sane)<br>
- build<br>
- either copy test.exe to real hardware with GRUB setup or<br>
- use tools' grub to generate EFI-based GRUB image for you and use Qemu <br>
virtual drive/dir support to boot from it directly.<br>
<br>
Note: the configure provides plethora of options especially for EFI <br>
console. You may also use BSP's command line arguments:<br>
<br>
graphic_mode=<number><br>
or<br>
text_mode=<number><br>
<br>
this is especially useful when seeing well nothing on the target platform.<br>
<br>
Tested platforms:<br>
- Qemu 7.2.0<br>
- Kontron D3598-B<br>
- Kontron D3641-S (only graphic_mode works here, when text is involved I <br>
get GP somewhere inside UEFI)<br>
- Lenovo B5400<br>
- ASRock B450M Pro4<br>
- Lenovo Ideapad Creator 5 -- does not work at all<br>
- HP Pro x2 612 G2 -- does not work at all<br>
<br>
The problem with last two laptops is that there is no PC-AT serial port <br>
available there which would throw at me nice GP complain and I would be <br>
able to investigate like I did in case of D3641-S.<br>
<br>
Cheers,<br>
Karel_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>