Thanks for all the info! :) Installing U-Boot as a bootloader, interacting with its Repl, and booting a system on it is all fine, good and important.
But I'm not talking about that. My concern is how to interact with the hardware from inside PilOS *after* it booted. > Em, hm. I thought the whole idea behind using u-boot is to let care > about device drivers and other low level stuff to u-boot and compiler. Yes, it *would* be nice if U-Boot would provide an API abstracting the hardware. But U-Boot does not provide runtime hardware services (like BIOS INT 13h for disk or INT 10h for display) to an OS after the kernel has taken control. Old PilOS depended on that. > We can use u-boot's API. u-boot has examples folder and I just tried to > run those examples in qemu. All I can find is that U-Boot performs low-level hardware initialization (memory, I/O, storage, etc.), supports a command-line interface for interacting with the system, and can handle complex boot scenarios. Good! But its hardware access features - such as reading/writing storage, accessing USB devices, or interacting with the console - are available *only* within the U-Boot environment itself! So how to code all the necessary system calls in PilOS? E.g. to draw to the screen, read and write block to/from flash memory (not to talk about network access which was also not available in old PilOS, as there is no support in legacy BIOS)? Or did I overlook features in U-Boot? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
