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

Aaron Williams awilliams at marvell.com
Tue Nov 5 23:09:01 UTC 2019



________________________________
From: Wolfgang Denk <wd at denx.de>
Sent: Tuesday, November 5, 2019 3:36 AM
To: Aaron Williams <awilliams at marvell.com>
Cc: Tom Rini <trini at konsulko.com>; Daniel Schwierzeck <daniel.schwierzeck at gmail.com>; u-boot at lists.denx.de <u-boot at lists.denx.de>
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support

Hi Wolfgang,

I apologize in  advance for the lack of email formatting (blame our IT department for forcing Linux users to use the broken Outhouse web client).

Dear Aaron,

In message <2609392.0ByMiX4J6F at flash> you wrote:
>
> 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.

Urgh... no!!! U-Boot is definitely *not* suitable for any kind of
real-time tasks.  By design it implements strict single-tasking with
usally polling hardware access only.  No multi-tasking, no
interrupts, no locking, no timers, nothing...

And I wouldn't ask U-Boot to do this. We don't do any multi-tasking with U-Boot with the exception of SoC specific code that deals with starting simple executive applications. Our API uses a single giant spinlock to prevent there being any multi-tasking within U-Boot.

Now there is other SoC specific code that does use locks and does support multiple cores simultaneously running code. This is needed when we start these Simple Executive applications. The code allows for multiple applications as well as the Linux kernel to be started simultaneously from within U-Boot. The code is executed by all cores in use and does things like set up memory and TLB mapping for the simple executive applications for each core. None of this code would be exposed outside of our SoC code and there is zero interaction with any of U-Boot's code. Each simple executive application has a core mask of cores assigned to it. Obviously in order to be able to do this there is locking within the SoC specific code. It does not involve any code outside of the SoC in order to do this.


> 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.

Definitely not.  You could not implement any of this without heavily
relyin on and deriving from internal interfaces of U-Boot which are
not exported for non-GPL use.

See https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLInProprietarySystem

This behaves exactly in the manner that is permitted by the GPL. They are completely separate programs.

Best regards,

Wolfgang Denk

Regards,

Aaron Williams

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.


More information about the U-Boot mailing list