[U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Aaron Williams]

Hi Wolfgang,

On Tuesday, November 5, 2019 12:37:26 AM PST Wolfgang Denk wrote:
> Dear Aaron,
> 
> In message <1838672.aZrPjDvGh8 at 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