Re: 64bit startup

[Sergey Bugaev]

On Sat, Jan 6, 2024 at 2:42 AM Luca <luca@orpolo.org> wrote:
> I had this small patch applied that apparently is enough for me to have
> some kind of core dump, I'm not sure if it's a good solution:

> +#ifdef __x86_64__
> +      struct _libc_fpstate fpstate;
> +      memset(&fpstate, 0, sizeof(fpstate));
> +      note.data.pr_fpreg = &fpstate;
> +#endif
>         fetch_thread_regset (threads[i], &note.data.pr_reg);
>         fetch_thread_fpregset (threads[i], &note.data.pr_fpreg);

Well, that should surely prevent the crash, but so will commenting out
the fetch_thread_fpregset call completely (perhaps this is what we
should actually do for the time being).

note.data is what we're writing out into the ELF core dump file; it
doesn't make any sense for it to be a pointer to a stack-allocated
variable in the dumper's address space. It doesn't make much sense for
it to be a pointer at all.

We need to figure out what kind of note GDB expects there to be, and
write that out. It doesn't necessarily have to match our definition of
fpregset_t; in fact I think it'd be better if builds of GDB without
any explicit support for x86_64-gnu would be able to read our core
files. And this means copying what Linux does, instead of apparently
Solaris, as the current elfcore tries to. Doing this might fix issues
with reading core files on i686-gnu, too.

> sure, I've started looking into it,

\o/

> but it will take a while before I
> can run something in userspace.

Sure, I don't expect you to produce a working kernel overnight :)

I kind of want to participate in kernel-side hacking too, but I don't
nearly have the understanding required.

How does initial boot protocol work, for example? I mean, where and
how control is transferred, what gets passed in registers, that kind
of thing. I've found many detailed explanations of board-specific boot
details (e.g. for Raspberry Pi 3), and [0] has a nice explanation of
how to make U-Boot load a custom kernel instead of Linux. I haven't
been able to find much info on GRUB; it sounds like Multiboot still
exists on AArch64, but it's unclear exactly how it works.

[0]: https://krinkinmu.github.io/2023/08/21/how-u-boot-loads-linux-kernel.html

Then, we're supposed to parse & use the device tree, aren't we? Do I
understand it right that both Mach and userland would have to deal
with the device tree? — in case of Mach, this would be needed to get
info on CPU cores, RAM, and serial / console / UART, right?

Do the questions at least make sense? Or am I talking nonsense? Can
you recommend any useful resources?

Are you targeting (or: do you think it's realistic to target) many
platforms / boards in a generic manner, or would we have to have
platform-specific gnumach builds? Does it make sense to start with
some specific platform (qemu "virt"?), and expand from there, or is it
better to build in the genericity from the start?

Sergey