Re: Adding or1k support to mkroot.

[Rob Landley <rob@landley.net>]

On 12/17/23 03:05, Stafford Horne wrote:
>> Can't you have #defines in your toolchain saying what architecture variant it
>> supports? And thus the code can #ifdef those without kconfig having to care?
> 
> Yes, the toolchain supports these, the kernel switches enable the toolchain
> flags when building the kernel (mostly).  For example:
> 
> $ or1k-elf-gcc --target-help
> The following options are target specific:
> ...
>   -mcmov                      Enable generation of conditional move (l.cmov)
>                               instructions.  By default the equivalent will
>                               be generated using set and branch.
> ..
>   -mhard-div                  Enable generation of hardware divide (l.div,
>                               l.divu) instructions.  This is the default; use
>                               -msoft-div to override.
>   -mhard-mul                  Enable generation of hardware multiply
>                               instructions (l.mul, l.muli) instructions. This
>                               is the default; use -msoft-mul to override.
> ..

And presumably have compile-time defaults settable in gcc's ./configure command
line. (Other architectures generally do.)

> The exception is where we use these flags to enable bitops. In:
> 
>  arch/openrisc/include/asm/bitops/ffs.h
>  arch/openrisc/include/asm/bitops/fls.h
> 
> Like other architectures the or1k toolchain doesn't expose which architecture is
> being built. While architectures such as m68k define tunes and export i.e.
> __mcfisaa__ to infer which instructions are enabled.
> 
> OpenRISC has no such architectures as within a softcpu architecture instructions
> can be enabled or disabled as required.  I know, its a bit crazy.

I like the "single point of truth" style where you specify something once and it
gets picked up from that one place by everything that uses it. On other
architectures, I setup mytoolchain to produce the right kind of binaries for the
target, and then the various programs take their cue from the toolchain.

The extra-confusing part here is if I run make menuconfig specifying ARCH= but
NOT specifying CROSS_COMPILE, that changes the config enough that when I build
vmlinux specifying CROSS_COMPILE again I get prompted to set symbols by "make
config". Specifically:

Enable register zeroing on function exit (ZERO_CALL_USED_REGS) [N/y/?] (NEW)

So this architecture IS querying the toolchain for some stuff (and then having
dangling dependencies when you change it out from under a build that it wants
manually fixed up), but other toolchain micromanagement has to be set manually
via menuconfig.

>> >> Hmmm, I've got:
>> >> 
>> >> qemu-system-or1k -M or1k-sim -m 256 "$@" -nographic -no-reboot -kernel
>> >> "$DIR"/linux-kernel -append "HOST=or1k console=FIXME $KARGS"
>> >> 
>> >> And it looks like the answer to "how do you enable a halt/reboot switch that can
>> >> exit qemu" is "don't use the or1k-sim board, use the virt board".
>> > 
>> > Yeah, virt board is the only one that supports halt/reboot.  The 'or1ksim'
>> > platform that we used as the model of qemu 'or1k-sim' supported reboot and halt
>> > via special 'nop' instructions.  The QEMU maintainers did not feel these special
>> > nop instructions should be supported in QEMU.
>> 
>> Sigh. Ok, I'll start the process over digesting the other config and trying to
>> get that one to work instead...

Still need to do this. (Holidays...)

>> >> It provides boot messages without any initrd at all. It eventually panics
>> >> because there's no init, but early in board bringup I'm just looking for proof
>> >> of life.
>> >> 
>> >> > Do you have a valid initrd that maybe I can try out?  I recently use qcow2
>> >> > images to build, but I did used to use initrd images and it did work fine.
>> >> 
>> >> Sure, just remove the BUILTIN=1 from the if or1k stanza, and... it's 582k, I'll
>> >> send it _not_ cc-ing the mailing list. :)
>> > 
>> > OK, I will try this out. But sorry busy this weekend I will probably not get
>> > time.
>> 
>> No rush, I think you've answered my question above. It would be nice to get the
>> bug fixed, but unless I can -device,poweroff or similar on the qemu command line
>> to insert whatever it's poking to halt (and then tell the kernel about it), the
>> sim board isn't useful to me for automation.
> 
> I tried to boot your initramfs with my virt_defconfig kernel, I just exchanged
> driver for -initrd.  It seems to work, but panics with the following:

Testing it in virt_defconfig doesn't reproduce the bug in or1k_sim, but I guess
the answer is "don't use or1k_sim".

> [    0.260000] 90000000.serial: ttyS0 at MMIO 0x90000000 (irq = 2, base_baud = 1250000) is a 16550A
> [    0.270000] printk: console [ttyS0] enabled
> ..
> [    0.420000] usbhid: USB HID core driver
> [    0.420000] NET: Registered PF_PACKET protocol family
> [    0.490000] clk: Disabling unused clocks
> [    0.490000] ALSA device list:
> [    0.490000]   No soundcards found.
> [    0.520000] Freeing unused kernel image (initmem) memory: 232K
> [    0.520000] This architecture does not have kernel memory protection.
> [    0.520000] Run /init as init process
> Type exit when done.
> oneit: /dev/ttyS0ttyS0: No such file or directory
> [    0.780000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
> [    0.780000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---
> 
> I am not sure about /dev/ttyS0ttyS0.

Hmmm, looks like /sys/class/tty/console/active had something I hadn't
encountered before in it, so oneit bugged out trying to redirect the console.
(It can have multiple lines and present or missing /dev/ prefix on each line,
and I didn't have test cases for all the combinations...)

And the problem is, of course:

    memmove(toybuf+5, TT.c, strlen(TT.c));

Needs a +1 on the strlen to also move the null terminator. :P

Oneit runs a child process (with the console redirected to the ACTUAL console
device so it can do job control) and then waits for it to exit, reaping zombies
until then, and calling reboot() when its child process was the one exiting (or
halt, or restarting the child; there's command line flags). This lets you boot
to a shell prompt with working job control (ctrl-C and friends) and a clean
shutdown instead of a panic when it exits.

Thanks,

Rob

P.S. And of course I don't want to check the obvious-seeming oneit fix in until
I can _test_ it, meaning booting the virt board, meaning converting the kernel
config... Working on it.