Hi Wolfgang,
On Monday, November 4, 2019 7:44:18 AM PST Wolfgang Denk wrote:
Dear Aaron,
In message 2710076.TiSPtmOvtb@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