Hi Wolfgang, On Tuesday, November 5, 2019 12:37:26 AM PST Wolfgang Denk wrote: > Dear Aaron, > > In message <1838672.aZrPjDvGh8@flash> you wrote: > > To be blunt, the current U-Boot EFI driver does not provide the required > > functionality. It would need to be extended in order to work. In addition, > > spinlocks would be required in order to handle the case of reentrancy. > > Also, how does the EFI loader deal with loading multiple applications > > across multiple cores? The block support is the least important part of > > it. There are several other services not related to block devices or > > network calls. > Maybe you are just trying to squeeze too much of operating system > functionality into a mere boot loader? > > Using tools for purposes they have not been designed for has never > been a good idea... > > Best regards, > > Wolfgang Denk
With the complexity of U-Boot, it certainly exceeds a number of operating systems I've used :) U-Boot OS might be fun for people writing applications where they want bare metal (i.e. hard real-time), though that's already provided with the API and examples. Our API is very much at arms length. It consists of a descriptor placed into a named block of memory that has the physical address of a single entry point, version information and a magic number, similar to EFI. There has to be some way to hand the CPU over to U-Boot, after all. That single entry point is basically a syscall. It saves the context of the caller and performs a TLB context switch and sets up a new stack for U-Boot and the TLB mapping (we run U-Boot at 0xFFFFFFFFC0000000). There is also a spinlock so that no other core may enter U-Boot until the current request finishes. The C code then interprets the opcode and copies any data (using physical addresses) into buffers used by U-Boot then when done it copies the data back to the application's pointers (which are physical addresses). U-Boot code other than the API never sees outside pointers and all data is copied to a local buffer. It's not fast but it's been very reliable. The external program doesn't need to know anything other than pass some parameters and call the address to hand the CPU context over to U-Boot. Neither side knows anything about the other. You can't get much more arms length than that except perhaps requiring U-Boot to use an interrupt. They are by just about any definition, completely separate binaries. I'm no lawyer, but reading the GPL FAQ I think we fall well within the arms length separation. At least on MIPS, U-Boot doesn't seem to care which core it's running on as long as only one core is executing at a time. It's proven to be quite reliable. It's not meant to be a heavy-duty OS and by design it limits how much I/O can be performed. It's only meant to load and save configuration and a few other operations. Even functions like getc/putc are not supported (since the native application can do that). The main functions used are for changing the phy parameters and the MAC quad-lane-module parameters like amplitude and equalization which goes along with the phy code. It also provides some very basic file I/O and block I/O and environment variable support like EFI. EFI would be nice to use, but it would require the proper lock support and a few other things to work in a multi-core environment. It could be converted over to EFI, though EFI would need to be expanded in order to provide the spinlocks and a few other minor changes for the SoC. EFI would also need to be expanded to allow for platform-specific calls to be supported related to the phy and QLM. Ideally we won't need this at all with some of the work we're doing on the Linux kernel. Regards, Aaron _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
