________________________________ From: Wolfgang Denk <w...@denx.de> Sent: Tuesday, November 5, 2019 3:36 AM To: Aaron Williams <awilli...@marvell.com> Cc: Tom Rini <tr...@konsulko.com>; Daniel Schwierzeck <daniel.schwierz...@gmail.com>; u-boot@lists.denx.de <u-boot@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@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: w...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
