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

[Aaron Williams]

Hi Wolfgang,

On Monday, November 4, 2019 7:44:18 AM PST Wolfgang Denk wrote:
> Dear Aaron,
> 
> In message <2710076.TiSPtmOvtb at flash> you wrote:
> > > What exactly do you need this for?  Why don't you just link your
> > > code with the rest of U-Boot?
> > 
> > We need it to obtain and modify the phy parameters. This is a custom 25G
> > gearbox that needs a lot of hand holding. This may end up being a low
> > priority (not the gearbox, but the API). It's only a few hundred lines of
> > code (the API).
> 
> Again you don't answer my question.  Why do you need a special new
> API for such code?  Why do you not just link that code with the rest
> of U-Boot?

The code in question that is calling the API is not GPL and hence cannot be 
linked with U-Boot though the phy code is GPL. The applications that are 
calling also have their own virtual memory configuration and there can be 
multiple applications running on multiple cores that can make simultaneous 
calls. Because of the way the phy must be maintained with a lot of state 
information, the code controlling it cannot be spread between the separate 
independent applications which run on their own dedicated cores and address 
spaces. The API I wrote takes care of the required context switching and 
provides the services for these applications, such as control of the phy, 
access to devices like eMMC, tuning our QLM interfaces (this code is required 
for U-Boot networking anyway), etc. There is no linking. Only a call table 
descriptor is published in a named block of memory. The API also provides the 
necessary spinlocks and switch stacks. The code in question adds around 36K in 
total, so it is fairly small. The main differences are the addition of a 
number of calls that are unique to our needs in addition to the method of 
calling since a context switch is required in addition to the spinlocks.

The phy in question also does not fit in the normal phy framework. It doesn't 
even communicate with  SMI. It is a complex gearbox where there needs to be 
interaction between applications and the gearbox where some code runs on the 
phy itself but a lot needs to be external.

The API also provides a number of other services such as access to and saving 
environment variables as well as access to block devices and filesystems. It 
is centralized in U-Boot because 1) the functionality is already available in 
U-Boot which is in memory anyway and 2) it's centralized and accessible by all 
applications so it can safely provide services to multiple applications 
simultaneously.

These applications are primarily bare-metal applications.

It may be that this functionality isn't needed. I will try and remove it if I 
can.

> 
> It has been mentioned before, but just to be sure: this code which
> uses your new API is licensed under a GPLv2 conforming lincense?
> 
There should be no need. None of the code is linked against U-Boot, either at 
compile time nor at runtime. The application doesn't even know where it is 
located except by looking for a named block of memory.

This is another thing we make use of in Octeon. There is a concept of named 
blocks in memory. These named blocks are used by U-Boot, simple executive 
applications and the Linux kernel. This allows physical memory to be 
partitioned between Linux and Simple Executive applications as well as 
providing some blocks that are used by some hardware blocks. I believe this 
support is already in the upstream Linux kernel for Octeon.

> Best regards,
> 
> Wolfgang Denk

Regards,

Aaron