In your case as you have a dev environment I’d just setup a haiuports recipe instead. Cross-compiling python3 is a major headache, so just compile python3 on real hw.
5 Likes
Screenshots are working. The problem was missing /boot/system/bin/screenshot. Screenshot use quite tricky startup process:
-
/boot/system/apps/Screenshotrun/boot/system/bin/screenshotand immidiately exit. -
/boot/system/bin/screenshotstart/boot/system/apps/Screenshotagain, but now by using special message. -
/boot/system/apps/Screenshotstarted second time now actually takes screenshot and show window.
21 Likes
I currently haven’t experienced a problem where python3 was required. Solving CMake problem is more important for now.
3 Likes
One of current problems is missing syscall restart implementation. Perl build often fails with “interrupted syscall”, I never get it completed for now. Dependencies: perl → automake → gcc and a lot more.
7 Likes
Syscall restart is implemented and tested on TinyEMU, but not yet on real hardware and Perl compilation.
Today I received a lot of feedback on Gerrit from Jessica Clarke, I hope it will help to improve port quality.
15 Likes
Some dispute occurred on Gerrit about bare metal boot loader haiku_loader.riscv. RISC-V community member don’t like it and want to force to use SBI only and external non-Haiku code where it really not needed.
1 Like
The are no technical reasons, reasons are purely ideological. They try to force use of SBI everywhere even if it is not technically needed such as virtual machines with well defined environment and no need of DDR etc. low level initialization.
3 Likes
haiku_loader.riscv was historically beginning of my Haiku RISC-V port and there will be no port without it.
(I will preface this explanation of the dispute at hand by noting that I am not an expert in these matters, and may get some things incorrect, etc.)
CPU architectures generally do not start in a mode where they are running standard instructions that they are documented with; instead, they usually start in some kind of “firmware” mode or something vaguely equivalent to it, and there is some program, embedded in the CPU or otherwise, that usually gets it out of this mode and into a more standard one, before invoking whatever the next boot step is.
On x86, this process is basically totally transparent to any OSes or even bootloaders; by the time any code an OS or bootloader developer has written is being run, the CPU is running in a regular and standard mode (when using MBR/BIOS booting on x86, this is usually … 16-bit real mode, emulating a good old 8088 or something close to it; it is the bootloader’s job to switch to 32-bit or 64-bit mode from there), and usually with some BIOS or other facility available to interact with hardware in a generic manner before you set up device drivers (e.g. IBM PC BIOS, EFI, U-Boot, etc.)
Generally, the layer that performs the truly early initialization and then provides the BIOS is CPU-specific, board-specific, and almost universally proprietary. Maybe it is technically reverse-engineer-able, or even documented, but modifying it is not trivial, and often not supported (“void your warranty”) and definitely not something OSes are ever in the business of doing. Such platforms are almost universally very machine-specific; on embedded platforms like RISC-V or ARM, they will often embed hardware addresses directly into the compiled loader, as there is no way of probing anything during this very early stage of booting.
On RISC-V, which is a truly open CPU platform, this lowest layer is actually officially documented (however, there are some major caveats even to this, it appears the specifications are deliberately looser about it, so this may not be such a strong guarantee), and so it is possible to write truly low-level boot platforms that do not rely on reverse engineering, at least in the abstract, instead of depending on a boot platform. X512 has written one of these, though it is limited to use in virtual machines (maybe just one virtual machine), and probably always will be; for any kind of real use on any bare metal device, either SBI, EFI, or some other like platform will have to be used as the bare metal device provides it.
So the question ultimately is, do we have a reason (if we are going to have to use SBI/EFI/etc. on bare metal, i.e. what Haiku is really geared at running on) to write, merge, and maintain a separate boot platform just for use in (maybe only one) virtual machine? That carries with it a lot of unknowns (for instance: developers that test on VMs may inadvertently break bare metal if they are using a totally different bootloader with different semantics) besides the added maintenance burden for unclear benefit. Hence why my own opinions, so far, side against this idea.
This is just a summary, I probably missed some things. But hopefully this makes the dispute more intelligible.
1 Like
haiku_loader.riscv runs on both TinyEMU and QEMU without modifications. Both virtual machines pass pointer to FDT in A1 register on CPU reset. It is used to detect virtual machine-specific hardware.
1 Like
OK, but that would still put us in the business for maintaining, on RISC-V, a level of bootloader we presently do not (or cannot) on any other architecture. That is no small thing, in my mind (especially if it is VM-specific, and there are alternatives available that are not VM-specific and that do not require us to maintain such a thing.)
1 Like
I agree. Haiku is different from Linux/BSD in many areas and I think that Haiku way is better. No need to bring Linux things and Linux way of thinking like u-boot. The only thing from u-boot we need is EFI.
For example Haiku boot loader is great that it can automatically scan and detect all discs containing Haiku kernel and allow user to select it in user-friendly interface. No configs at all! Unlike GRUB, Haiku loader can load kernel modules, configs and setup MMU so kernel is started with already prepared environment and kernel do not need to be recompiled for different boot drivers. No initramfs hack.
U-boot is a total disaster, it is major reason of ARM computer incompatibilities. It has terrible practice of compiling u-boot for specific combination with kernel. Linux has terrible practice of bringing very platform-dependent FDT table image with OS installation. On x86 such tables are usually located at BIOS ROM chip programmed by manufacturer.
For Haiku it is possible to just write image to USB and boot it on HiFive Unmatched board without any configs, FDT and SD card tricks.
In summary: Linux brings terrible importable and user-unfriendly practices that Haiku should not follow.
9 Likes
X512 has done amazing job and reached great achievements with his RISCV work. But his reluctance to the Jessica’s advice is hardly justified. You say, UEFI, uboot are bloated. but is it your concern? as a Haiku developer? would you deal with that? of course, no. In fact, no matter how “bloated” a UEFI implementation could seem to be, its interface provided to the OS Loader is super easy to understand and use. this is what an OS developer, creating the loader should and would care about. In this respect, using UEFI is the right way. Not to mention, all the future RISCV machines will be UEFI.
An I am happy with it, no more ugly u-boot. I use UEFI on HiFive Unmatched real hardware. But bare metal boot loader is more convenient to use on virtual machines especially when developing and testing kernel related parts. It is also nice that you aware of all code running on system, no unexpected behavior and easier testing.
7 Likes
Which you can never say about Linux. It is so bloated that nobody can know more than a tiny fraction of it.
But yeah, let’s do it like Linux! /s
Some people respect their freedom and select open solutions instead like CoreBoot. It it weird to claim open architecture, but force specific solutions. Open architecture means that you can do anything with it regardless of any opinion and you have access to all documentation and source code.
But of course it is unrelated to haiku_loader.riscv, it is currently pure virtual machine solution.
3 Likes
the argument was not about this. it was about not using a processor mode, intended to be used by only a very machine/platform specific (early) part of firmware and not intended for using by the OS loader. the main practical reason is not even "we don’t like doing like this), but the fact, this code surely will be very different on every SoC family, on every platform, vendor etc. it belongs to such deep FW guts, that for the OS loader, there is really no benefit to get into that. in other words, this code will be only relevant to this particular narrow target set (Qemu, TinyEmu virt). for other targets, the loader arrangement will be absolutely different (UEFI app). is this divergence good in the tree?