Make support for u-boot

[mekosko]

U-Boot passes arguments through int argc and char *const argv[]. In order to work with them riscv-rt should accept appropriate entry point signature. Also because the only way to get boot-hart is through fdt this feature implies single-hart.

Expected entry point signature for u-boot: https://github.com/u-boot/u-boot/blob/master/lib/elf.c#L26

[mekosko]

From CI seems that #[entry] macros should accept not only two arguments when u-boot is enabled, but also one or no arguments at all.

[mekosko]

I've also tried to reduce code complexity.

[mekosko]

Updated CHANGELOG.md, now CI should pass without any troubles.

[romancardenas]

Thanks for your contribution! Please, fix the CI so it works with your new feature

[mekosko]

hartid should be taken from fdt when booting through u-boot
https://github.com/u-boot/u-boot/blob/master/arch/riscv/lib/fdt_fixup.c#L157

[mekosko]

I found out that something else preventing from booting through u-boot. So PR should not be merged yet. :(

[romancardenas]

Don't worry, let's mark it as draft :)

[mekosko]

Initialization of multiple harts breaks booting through u-boot. I disabled it for u-boot so now everything works well and you can pass arguments such as fdt_addr from u-boot. I think it's up to user to initialize harts when working through u-boot.

[romancardenas]

Can you please add documentation to guide users on how to use this feature?

[mekosko]

Can you please add documentation to guide users on how to use this feature?

Done. I'm not sure about writing docs on how to use u-boot to boot resulting elf binary. I don't think this is the right place for that.

[romancardenas]

I'm not familiar with u-boot, so there are some details that I missed. For instance, if u-boot passes arguments via the stack, shouldn't we load the input parameters to a0 and a1 so the Rust main function gets the correct input?

If you tested this and it works, I am probably missing something, but I would like to understand what is going on 😁

[romancardenas]

Can you please add documentation to guide users on how to use this feature?

Done. I'm not sure about writing docs on how to use u-boot to boot resulting elf binary. I don't think this is the right place for that.

What you did is more than enough, thanks!

[romancardenas]

Also, while the current assembly code pushes three registers to the stack, they are popped out before calling main, so it shouldn't be necessary to opt-out of this code, right? The stack pointer will have the original value.

[mekosko]

I'm not familiar with u-boot, so there are some details that I missed. For instance, if u-boot passes arguments via the stack, shouldn't we load the input parameters to a0 and a1 so the Rust main function gets the correct input?

If you tested this and it works, I am probably missing something, but I would like to understand what is going on 😁

I tested this, was able to work with arguments and they were correct.

[mekosko]

Also, while the current assembly code pushes three registers to the stack, they are popped out before calling main, so it shouldn't be necessary to opt-out of this code, right? The stack pointer will have the original value.

There is a chance that I was wrong and they are passed through a0 and a1. Will check with debugger.

[mekosko]

I think everything said about stack was wrong 😐

[mekosko]

I don't know why caller also places argv address in a2

[romancardenas]

I don't know why caller also places argv address in a2

Maybe it points to the last element of argv? Can you try to forward two arguments?

[mekosko]

Now macro can check for pointer types and strips type's path.
core::ffi::c_char == c_char -> true
*const *const core::ffi::c_char == *const *const c_char -> true
*const c_char == *const *const c_char -> false

[mekosko]

I also changed expected type of argv to *const *const c_char in that commit.

[mekosko]

I don't know why caller also places argv address in a2

Maybe it points to the last element of argv? Can you try to forward two arguments?

Same behavior with two arguments

[mekosko]

I think that might be just some kind of side effect.

[mekosko]

s4 is also set to that address

[mekosko]

CI failure seems unrelated to this PR

[romancardenas]

Yep, from time to time, Clippy gets more strict. Please, fix the new lints

[mekosko]

I checked locally and seems like now clippy should not complain.

[mekosko]

Should I add entry to CHANGELOG that I fixed clippy warnings?