How to get amd64efi BSP running.

Mon Apr 17 00:49:40 UTC 2023

On Sun, Apr 16, 2023 at 4:56 PM Karel Gardas <karel at functional.vision>
wrote:

>
>   Folks,
>
> I just send my amd64efi BSP results for review. One of the commits (with
> BSP actually) awaits moderator approval due to size so before it gets in
> let me add few remarks about how to make that BSP working on either Qemu
> or real hardware.
>

This is all great news!

>
> CAVEAT: We have serious issue somewhere between kernel, newlib and gcc
> which causes SSE aligned isns to work on unaligned data causing general
> protection fault. This issue is serious and needs to be investigated in
> the future by anyone working on amd64. To workaround the issue I did:
>

This generally sounds like a pervasive issue which is historically tied to
needing some changes to compiler arguments or something odd like
aligning the stack more strictly. But your example below is not stack
related so that's not the entire issue.

I looked at the output of waf bspdefaults and I don't see any arguments for
the ABI CFLAGS. That leaves at least the SSE and CPU model revision
to be defaulted which is not a good thing usually.

There are LOTS of x86_64 options for SSE which per this stack overflow
article appear to factor into this:

https://stackoverflow.com/questions/38443452/alignment-and-sse-strange-behaviour

This is an old bug report but one suggestion is that the stack be 16-byte
aligned
along with some other hints.

https://sourceware.org/bugzilla/show_bug.cgi?id=12123

I'm leaning to multiple causes under the hood for unaligned data being
passed to some SSE enabled routine. Unfortunately, if you can get the
faulting address, we can probably figure out what GCC is doing. This
may simply require tweaking the compiler settings internally some to
increase alignment by default.

If you have some small code example which fails, perhaps compiling
it to assembly with the RTEMS and Linux GCC's and seeing how items
are aligned will give a hint.

For sure, this isn't something we want to address on a case by case basis.
The alignment is not strict enough for 1+ broad reasons.

One odd thought to keep in mind is that I don't know how many people
use the x86_64-elf GCC and tools configuration. Lots use say arm-eabi
but how many people are using this bare metal configuration? I vaguely
recall that I may be the author of the GCC configuration which means
it is only used by this RTEMS build and BSP. So a mistake in making the
simple configuration is not out of the question.

Your patch hints that we may need to figure out how to increase the
default alignment on a data item in the compiler configuration.

> - few "fixes" here and there as required by GP crash reports on
> hello/ticker/malloctest tests. Those are only tests I have working here.
> The patch for those fixes is attached. This is *NOT* something for
> review or commit, this is just *WORKAROUND* to get interested people up
> & running!
>
> - unfortunately the issue above not only affects RTEMS kernel, but also
> tools' newlib. Hence there is a need to build a new newlib. I simply
> obtained newlib from git as the 6/rtems-x86_64 is pretty close to HEAD
> of newlib anway and compile that with RTEMS GCC (installed by RSB). When
> this is compiled I touched newlib/libc/stdio/findfp.c and recompile it
> again, but this time with adding '-mgeneral-regs-only' GCC option. This
> is needed since unalignment of data happens when using this:
>
>       30
>       31 __FILE __sf[3];
>       32
>
> and the GCC does not have any attribute which would help with this
> unless the code is rewritten to get rid of array construct here.
> Anyway, using only general purpose regs here is quick and easy
> workaround...
>
> And that's about all needed to get hello/ticker/malloctest working. Just:
> - configure (config file defaults should be more or less sane)
> - build
> - either copy test.exe to real hardware with GRUB setup or
> - use tools' grub to generate EFI-based GRUB image for you and use Qemu
> virtual drive/dir support to boot from it directly.
>
> Note: the configure provides plethora of options especially for EFI
> console. You may also use BSP's command line arguments:
>
>    graphic_mode=<number>
> or
>    text_mode=<number>
>
> this is especially useful when seeing well nothing on the target platform.
>
> Tested platforms:
> - Qemu 7.2.0
> - Kontron D3598-B
> - Kontron D3641-S (only graphic_mode works here, when text is involved I
> get GP somewhere inside UEFI)
> - Lenovo B5400
> - ASRock B450M Pro4
> - Lenovo Ideapad Creator 5 -- does not work at all
> - HP Pro x2 612 G2 -- does not work at all
>
> The problem with last two laptops is that there is no PC-AT serial port
> available there which would throw at me nice GP complain and I would be
> able to investigate like I did in case of D3641-S.
>
> Cheers,
> Karel_______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230416/7ee0b3c1/attachment.htm>