Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Daniel, On Friday, October 25, 2019 8:13:57 AM PDT Daniel Schwierzeck wrote: > External Email > > -- > Hi Aaron, > > Am 23.10.19 um 05:50 schrieb Aaron Williams: > > Hi all, > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > and merging it upstream. This will involve a very significant amount of > > code that generally will not be compatible with other MIPS processors > > due to our needs and requirements. For example, the start.S will need to > > be completely different than what is present. For example, our existing > > start.S is 3577 lines of code in order to deal with things like RAS, > > exceptions, virtual memory and more. We need to use virtual memory since > > U-Boot can be loaded at any 4MB boundary in memory, not just 0xbfc0. > > A number of drivers will need to be updated in order to properly map > > pointers to physical addresses. This is needed anyway, since I see > > numerous drivers that assume that a pointer is a DMA address. For MIPS > > this is never the case (I'm looking at XHCI). > > Good to see some progress in mainline Octeon support. Could you briefly > describe the differences and commonalities in booting an Octeon CPU > compared to other "generic" MIPS cores? Or could you point me to a > public Git tree? It can't be that different because Linux kernel is also > able to share most of the code ;) > Actually the low level code is significantly different. First of all, we need the U-Boot bootloader to be able to boot from different memory locations. Because of this, we use mapped memory for U-Boot. A side effect of this is that it eliminates the need for relocation when it is shifted to the top of memory. All we need to do is just set a couple of TLB entries. The assembly code is significantly different and is far more extensive. Additionally, the way Octeon Linux is booted is different. The generic start.S is not usable in our case. We have a significant amount of code for dealing with the cache and for things like copying U-Boot from flash into the L2 cache. We also have to deal with taking other cores out of reset in our start.S. Our exception handler has also been extended to handle multiple cores. Some other things we have included are a native API that allows Simple Executive applications to make calls into U-Boot for such things as environment variable access as well as access to block devices and filesystems. We used to have our Octeon SDK available for download but it seems this has been taken down :( I'm trying to find out how I can make it available but I'm getting pushback in sharing our GPLed U-Boot even though it is GPL. > In principle you could compile an own start.S in your mach-octeon > directory, but you should try to use the generic start.S which is > already customisable and extensible. If needed, we could add more > extension points to it. Booting from any custom memory address is > already supported and very common for other MIPS based SoC's. Exception > support is also already there. > The bootloader needs to be able to start from multiple memory locations without recompiling. Our existing bootloader can run from any 4MB boundary without recompiling or relocation. It can start out of flash (from any sector boundary, not just 0) or L2 cache. Starting by L2 cache is supported by eMMC, SPI and PCI target bootloaders. Additionally the same bootloader can be started from RAM such as when the failsafe bootloader starts the main bootloader. In most cases, the failsafe is the same full-featured bootloader since it fits entirely within the L2 cache. Our only bootloader requirement is that it fits in the L2 cache (except when booting from Flash, though this is preferred for speed) and that it remain under 4 MiB in size. I believe our exception handling is more extensive than the standard U-Boot exception handler. It includes the stack output as well as numerous COP0 registers and decoding the cause of the exception. The exception handler is also independent of a working C environment. We also need to handle exceptions occurring on multiple cores as they're brought out of reset and not all cases are exceptions. Cores are first powered on and kept in a halted state, then later when we start the Linux kernel or simple executive applications, the exception handler is updated (via a bootbus moveable memory region) and an NMI is generated for the cores where they will begin executing code out of start.S before moving to the code that sets up the environment for booting Linux and/or simple executive applications. In the latter case, TLB entries are programmed in for each core. > > The new Octeon U-Boot will be native 64-bit instead of how the earlier > > one was 32-bit using the N32 ABI (so 64-bit addresses could be > > accessed). We had to jump through some hoops to make a 32-bit U-Boot > > fully support 64-bit hardware.
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Saturday, October 26, 2019 3:15:36 PM PDT Tom Rini wrote: > External Email > > -- > > On Fri, Oct 25, 2019 at 05:13:57PM +0200, Daniel Schwierzeck wrote: > > Hi Aaron, > > > > Am 23.10.19 um 05:50 schrieb Aaron Williams: > > > Hi all, > > > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > > and merging it upstream. This will involve a very significant amount of > > > code that generally will not be compatible with other MIPS processors > > > due to our needs and requirements. For example, the start.S will need to > > > be completely different than what is present. For example, our existing > > > start.S is 3577 lines of code in order to deal with things like RAS, > > > exceptions, virtual memory and more. We need to use virtual memory since > > > U-Boot can be loaded at any 4MB boundary in memory, not just 0xbfc0. > > > A number of drivers will need to be updated in order to properly map > > > pointers to physical addresses. This is needed anyway, since I see > > > numerous drivers that assume that a pointer is a DMA address. For MIPS > > > this is never the case (I'm looking at XHCI). > > > > Good to see some progress in mainline Octeon support. Could you briefly > > describe the differences and commonalities in booting an Octeon CPU > > compared to other "generic" MIPS cores? Or could you point me to a > > public Git tree? It can't be that different because Linux kernel is also > > able to share most of the code ;) > > > > In principle you could compile an own start.S in your mach-octeon > > directory, but you should try to use the generic start.S which is > > already customisable and extensible. If needed, we could add more > > extension points to it. Booting from any custom memory address is > > already supported and very common for other MIPS based SoC's. Exception > > support is also already there. > > > > > The new Octeon U-Boot will be native 64-bit instead of how the earlier > > > one was 32-bit using the N32 ABI (so 64-bit addresses could be > > > accessed). We had to jump through some hoops to make a 32-bit U-Boot > > > fully support 64-bit hardware. > > > > We have 64 bit support for MIPS. I even sync'ed the asm/io stuff from > > Linux in the past (which includes support for Octeon) so that you would > > be able to use the standard IO primitives and ioremap stuff and hook in > > your platform-specifc memory mappings. > > > > > I think we can shrink the code by removing support for starting "simple > > > executive" tasks. Simple executive tasks are bare metal applications > > > that can run on dedicated cores beside Linux (or without Linux). I will > > > also not be porting any support for anything older than Octeon3. > > > > > > We also make heavy use of our SDK in order to perform hardware > > > initialization and networking. In our old U-Boot, we have almost 900K > > > lines of code. I can cut out much of this but much will remain. > > > > > > We also have added extensive infrastructure for handling SFP and QSFP > > > cables as well as very extensive phy support for phys from > > > Aquantia/Marvell, Vitesse/Microsemi, Inphi/Cortina and an Avago gearbox. > > > Our customer wants us to port all of this to the new U-Boot and upstream > > > it. I'm worried about the sheer amount of code since it is absolutely > > > massive. > > > > Maybe you should cut down your customers expectations a bit. According > > to sloccount we currently have 1.6M SLOC for the whole U-Boot. I guess > > Tom or Wolfgang wouldn't agree with adding another 900k only for one > > CPU. Actually what should be upstream is the basic CPU, driver and board > > support to be able to boot a mainline kernel. Everything else like > > custom bare metal applications or the SFP/PHY handling stuff mentioned > > below could also be maintained in a downstream tree. Maybe Wolfgang is > > willing to host one on gitlab.denx.de. > > > > > Some of these phy drivers are extremely complex and need to tie > > > into the SFP management. We also need to use a background polling thread > > > while at the command prompt. A fair bit of our phy code is not in the > > > normal phy drivers because it did not fit the model. Some of these phy > > > drivers need to interact with the SFP support code in order to handle > > > hot plug events in order to reconfigure themselves based on the cable > > > type. The existing SFP code handles everything from SFP to SFP28 as well > > > as QSFP and 100G QSFP (never tested). > > > > > > In the old U-Boot the PHY support had to be significantly enhanced due > > > to requirements for hot-plugging and how some of the PHYs are > > > configured. It gets quite complicated with phys like the Inphi where one > > > phy can handle either four ports (XFI/SGMII) or a single 4-lane port > > > (XLAUI). It gets even worse since in some boards we use reclocking chips > > > and there is one chip that handles the receiv
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <4176494.JIoP81OjG2@flash> you wrote: > > Actually the low level code is significantly different. First of all, we need > the U-Boot bootloader to be able to boot from different memory locations. > Because of this, we use mapped memory for U-Boot. A side effect of this is > that it eliminates the need for relocation when it is shifted to the top of > memory. All we need to do is just set a couple of TLB entries. > > The assembly code is significantly different and is far more extensive. > > Additionally, the way Octeon Linux is booted is different. > > The generic start.S is not usable in our case. Please excuse my ignorance - I have never touched a Cavium system yet (at least not knowingly), and never looked into any of that code. So for me it would be really helpful if you would not only describe what you have, or what you need, or that things are different or cannot be used, but actually explain _why_ this is the case, and why you cannot use the existing structure of U-Boot mainline code. I know that it is always difficult to upstream code that has been developed out of tree and without synchronizing the design with the mainline maintainers, but as long as you don't explain why it was mandatory to do things different, it is impossible to understand if this is the only sane way things can be implemented, or if you just don't want to change the code that has grown over the years in an uncontrolled way to avoid the efforts for cleaning it up. > We have a significant amount of code for dealing with the cache and for > things > like copying U-Boot from flash into the L2 cache. We also have to deal with > taking other cores out of reset in our start.S. Our exception handler has > also > been extended to handle multiple cores. We should be able to understand why you need this. There might be areas where your code overlaps with things that are already available in U-Boot mainline, and if there are good reasons to duplicate such areas, you should explain them. Daniel already pointed out that doubling the code size of U-Boot by adding just a single new CPU simply makes no sense. I don't know what you are using U-Boot for, but we should keep in mind that it's a boot loader, which main purpose should be to execute as fast as possible just to be replaced by an operating system. I have to admit that I have problems understanding why someone would need hot plug support for hardware in U-Boot. It would be best to restrict initial upstreaming to a minimal sub-set that gives maintainers even a chance to review it. Best regards, Wolfgang Denk -- 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 Alliance: In international politics, the union of two thieves who have their hands so deeply inserted in each other's pocket that they cannot separately plunder a third. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Aaron, Am 27.10.19 um 03:34 schrieb Aaron Williams: > Hi Daniel, > > On Friday, October 25, 2019 8:13:57 AM PDT Daniel Schwierzeck wrote: >> External Email >> >> -- >> Hi Aaron, >> >> Am 23.10.19 um 05:50 schrieb Aaron Williams: >>> Hi all, >>> >>> I have been tasked with porting our Octeon U-Boot to the latest U-Boot >>> and merging it upstream. This will involve a very significant amount of >>> code that generally will not be compatible with other MIPS processors >>> due to our needs and requirements. For example, the start.S will need to >>> be completely different than what is present. For example, our existing >>> start.S is 3577 lines of code in order to deal with things like RAS, >>> exceptions, virtual memory and more. We need to use virtual memory since >>> U-Boot can be loaded at any 4MB boundary in memory, not just 0xbfc0. >>> A number of drivers will need to be updated in order to properly map >>> pointers to physical addresses. This is needed anyway, since I see >>> numerous drivers that assume that a pointer is a DMA address. For MIPS >>> this is never the case (I'm looking at XHCI). >> >> Good to see some progress in mainline Octeon support. Could you briefly >> describe the differences and commonalities in booting an Octeon CPU >> compared to other "generic" MIPS cores? Or could you point me to a >> public Git tree? It can't be that different because Linux kernel is also >> able to share most of the code ;) >> > > Actually the low level code is significantly different. First of all, we need > the U-Boot bootloader to be able to boot from different memory locations. > Because of this, we use mapped memory for U-Boot. A side effect of this is > that it eliminates the need for relocation when it is shifted to the top of > memory. All we need to do is just set a couple of TLB entries. Understood. but still U-Boot relocates itself from its initial entry memory address to its destination memory address based on gd->ram_top. Maybe this is ineffective nowadays with various SPL/TPL boot methods because U-Boot proper is already loaded to an executable memory location by SPL, but you have to initially deal with that design. Feel free to suggest/submit a patch for the generic board init code to make the reloaction configurable. > > The assembly code is significantly different and is far more extensive. > > Additionally, the way Octeon Linux is booted is different. > > The generic start.S is not usable in our case. > > We have a significant amount of code for dealing with the cache and for > things > like copying U-Boot from flash into the L2 cache. We also have to deal with > taking other cores out of reset in our start.S. Our exception handler has > also > been extended to handle multiple cores. it's hard to discuss this without example code but I still think the basic principles of cache and exception handling can't be that different from generic MIPS cores. Locking cache lines and loading code to it could be useful for other MIPS platforms and should be added as generic feature. BTW the exception handler code is a port of the Linux one, I only skipped the stack trace output because of the complicated stack unwinding code. I think the current dump of general and CP0 and EPC registers is more than feasible for a bootloader. It already helped me multiple times to quickly locate code locations with e.g. null pointer dereferencing. > > Some other things we have included are a native API that allows Simple > Executive applications to make calls into U-Boot for such things as > environment variable access as well as access to block devices and > filesystems. This is one of the parts that shouldn't be needed for basic upstream support. It your API is a parallel and independent implementation of the API that U-Boot already has for standalone applications, than I'm afraid this won't be accepted and should be kept in a downstream fork. > > > We used to have our Octeon SDK available for download but it seems this has > been taken down :( I'm trying to find out how I can make it available but I'm > getting pushback in sharing our GPLed U-Boot even though it is GPL. > >> In principle you could compile an own start.S in your mach-octeon >> directory, but you should try to use the generic start.S which is >> already customisable and extensible. If needed, we could add more >> extension points to it. Booting from any custom memory address is >> already supported and very common for other MIPS based SoC's. Exception >> support is also already there. >> > > The bootloader needs to be able to start from multiple memory locations > without recompiling. Our existing bootloader can run from any 4MB boundary > without recompiling or relocation. It can start out of flash (from any sector > boundary, not just 0) or L2 cache. Starting by L2 cache is supported by eMMC, > SPI and PCI target bootloaders. Additionally th
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Daniel & Aaron, In message <7fdf93f6-412e-5fcf-da5e-17665daad...@gmail.com> you wrote: > > > Some other things we have included are a native API that allows Simple > > Executive applications to make calls into U-Boot for such things as > > environment variable access as well as access to block devices and > > filesystems. > > This is one of the parts that shouldn't be needed for basic upstream > support. It your API is a parallel and independent implementation of the > API that U-Boot already has for standalone applications, than I'm afraid > this won't be accepted and should be kept in a downstream fork. The big question here is what these are intended for. If they are indeed thought as standalone applications, especially containing code that shall not be disclosed unter GPL, then there is a licensing issue - the pretty hard restrictions of the API for standalone applications is intentional, and attempts to work around it are license violations. But if it's just normal GPL code that is somehow dependent on U-Boot services, then why is it not linked against U-Boot? Or this might be something ike dynamically loadable modules - well, then a close look is needed because such an approach has to be generic enough (end probably borrow much from Linux). Best regards, Wolfgang Denk -- 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 There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote: > External Email > > -- > > On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote: > > Hi all, > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > and merging it upstream. > > [snip] > > I want to jump back up back to the top of this thread. And first I want > to say that I am glad that there is official desire to upstream support. > This is good. My concern is that the plan seems to be, at a very high > level, "get everything we have for every feature upstream". But as been > said elsewhere this would roughly double the total LOC for the project, > and it's not like we're a new project with a small handful of things :) > It's impossible for the community to review that much code in any > meaningful way over anything less than a period of several years. I > know you've said that to support various customer use cases you need all > sorts of other things, and while I'm certain that's true, I believe the > plan needs to be to step back and pick the smallest possible testable > unit, and upstream it. And add to it, small pieces at a time. Thanks! It might be easier if I were a maintainer for our SOC to limit the needed review of a fair bit of the code. I have already found I can cut out a large chunk of our code by removing support for our older models. Much of the code has been very well tested, for example our serdes initialization and DRAM initialization code. That's not to say I can't do some cleanup. The changes to U-Boot itself should be relatively small as long as I can keep much of our code under arch/mips/arch-octeon and arch/mips/cpu/octeon much like how our ARM code is. For anything that is applicable to other architectures I will place it in the appropriate locations. Our ARM code is quite a bit simpler than MIPS because on ARM most of the heavy lifting is done by our "BDK" bootloader as well as ATF. On ARM, U-Boot doesn't need to deal with SFPs, serdes initialization, DRAM initialization, hot plug or a myriad of other issues. I noticed the same with X86. If it weren't for these other layers the X86 code would also be quite large. I have already identified quite a few very large files that will be removed, such as the error handling code for or Octeon2 and earlier CPUs. Additionally I have identified a number of register definition files I can get rid of, including one that's 2.3MB in size! These files tend to be huge because they contain definitions for every single chip and revision as well as big and little endian definitions. On top of that, there are a huge number of comments. Each field contains all of the text that is in our hardware reference manuals. There is no dearth of comments. I should be able to cut the size of the remaining files to 1/4th their current size or even smaller. Some files will still remain quite large, however, such as our serdes initialization and DRAM initialization code (which I plan to re-architect because the original author didn't believe in functions due to stack limitations. (it is well commented though). If you ever want to learn all the gory details of DDR4 link training and finding trends and so-forth it's all in there. The current memory initialization code is over 1MB in size. I plan to cut this down and break it up in a clean manner. The initialization code has grown in complexity and size over the years as various instabilities have been identified and fixed. The DRAM initialization code for our OcteonTX2 CPU is almost as large, though this code has been cleaned up and re-written. There really is no way to avoid this. The OcteonTX and OcteonTX2 DDR initialization code is similar to that for Octeon. In the case of U-Boot on our ARM SoCs, though, initialization is done before U-Boot is loaded. I'll move the init code to drivers/ram/marvell/octeon. It will be about twice as large as the AXP driver (which only handles DDR3). The serdes init code I figure could go under drivers/soc/marvell/octeon. I noticed that there are several directories under drivers for memory. There's drivers/ram, drivers/memory and drivers/ddr. These should be consolidated. I think some code might be able to be common, such as the SPD decoding code. It's even possible that some algorithms might be able to be made common such as deskew training and read/write leveling. In terms of Octeon specific features, there really aren't too many of those but most of the ones we have are essential in the bootloader. There's no avoiding the Serdes and low-level network initialization. The serdes init code works across all networking interface types (SGMII, 1000Base-X, XAUI, RXAUI, XFI, XLAUI, 25G (XLAUI), SATA, PCIe, SRIO plus all the variants (i.e. KR). It also configures all the clocks and equalization. It's not like a simple gigabit NIC nor is it offloaded to some o
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <1932577.QJWW3v3lL8@flash> you wrote: > > We do this relocation as well, however the way we do it is by changing a > couple of TLB entries. This lets U-Boot begin execution from any memory > location, be it flash, L2 cache or RAM. It also lets us statically link > U-Boot > to run at a fixed address, in our case 0xC000. The relocation happens It seems you have missed the primary purpose of relocation. The interesting thing is not the start address, but the end address of U-Boot in memory, as we alsways try to place the U-Boot code and data at the very end of the available memory (and yes, this includes systems which can cam with different memory sizes). Additionally, we want to be able to reserve additional memry at the end of RAM, above U-Boot, so it can even be kept across warm boots. Features like protected RAM (PRAM), shared log buffers, shared video memory etc. come in to mind here. > This might be something to consider in the future on some platforms where > "relocation" could be performed by just adjusting the TLB or page tables. > MIPS > makes this particularly easy. This cannot be done, not without castrating U-Boot from a number of features that require allocation at the end of the available RAM, see above. > That's fine. The code is actually quite small. It has some custom APIs unique > to our needs. We have need to call into the phy code from these applications. > I don't know if this could work with the general API or not. One reason we > did What exactly do you need this for? Why don't you just link your code with the rest of U-Boot? Best regards, Wolfgang Denk -- 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 Many companies that have made themselves dependent on [the equipment of a certain major manufacturer] (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the un- mastered complexity of their data processing systems. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <1889679.7FQr5zsBR1@flash> you wrote: > > Currently we are using 39MB under arch/mips. I think I can easily cut this > down to 15MB or smaller, especially by moving some code here to the > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > It will still be a large SoC, though. Have you already looked at formal requirements, like coding style etc.? Did you ever run your additions through checkpatch.pl, for example? Best regards, Wolfgang Denk -- 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 If ignorance is bliss, why aren't there more happy people? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wed, Oct 30, 2019 at 11:36:19PM +, Aaron Williams wrote: > On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote: > > External Email > > > > -- > > > > On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote: > > > Hi all, > > > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > > and merging it upstream. > > > > [snip] > > > > I want to jump back up back to the top of this thread. And first I want > > to say that I am glad that there is official desire to upstream support. > > This is good. My concern is that the plan seems to be, at a very high > > level, "get everything we have for every feature upstream". But as been > > said elsewhere this would roughly double the total LOC for the project, > > and it's not like we're a new project with a small handful of things :) > > It's impossible for the community to review that much code in any > > meaningful way over anything less than a period of several years. I > > know you've said that to support various customer use cases you need all > > sorts of other things, and while I'm certain that's true, I believe the > > plan needs to be to step back and pick the smallest possible testable > > unit, and upstream it. And add to it, small pieces at a time. Thanks! > > It might be easier if I were a maintainer for our SOC to limit the needed > review of a fair bit of the code. I have already found I can cut out a large > chunk of our code by removing support for our older models. Much of the code > has been very well tested, for example our serdes initialization and DRAM > initialization code. That's not to say I can't do some cleanup. Don't worry, I totally expect you to become the maintainer for your SoC, that's key to making sure the SoC-specific stuff is done right :) But, you're not the first big SoC to migrate from an internal fork to mainline and have a seemingly impossible number of LOC to deal with. It's why I'm saying you need to start with something absolutely as small as possible, and move forward. > The changes to U-Boot itself should be relatively small as long as I can keep > much of our code under arch/mips/arch-octeon and arch/mips/cpu/octeon much > like how our ARM code is. For anything that is applicable to other > architectures I will place it in the appropriate locations. > > Our ARM code is quite a bit simpler than MIPS because on ARM most of the > heavy > lifting is done by our "BDK" bootloader as well as ATF. On ARM, U-Boot > doesn't > need to deal with SFPs, serdes initialization, DRAM initialization, hot plug > or a myriad of other issues. > > I noticed the same with X86. If it weren't for these other layers the X86 > code would also be quite large. > > I have already identified quite a few very large files that will be removed, > such as the error handling code for or Octeon2 and earlier CPUs. > > Additionally I have identified a number of register definition files I can > get > rid of, including one that's 2.3MB in size! These files tend to be huge > because they contain definitions for every single chip and revision as well > as > big and little endian definitions. On top of that, there are a huge number of > comments. Each field contains all of the text that is in our hardware > reference manuals. There is no dearth of comments. I should be able to cut > the > size of the remaining files to 1/4th their current size or even smaller. > > Some files will still remain quite large, however, such as our serdes > initialization and DRAM initialization code (which I plan to re-architect > because the original author didn't believe in functions due to stack > limitations. (it is well commented though). If you ever want to learn all the > gory details of DDR4 link training and finding trends and so-forth it's all > in > there. The current memory initialization code is over 1MB in size. I plan to > cut this down and break it up in a clean manner. The initialization code has > grown in complexity and size over the years as various instabilities have > been > identified and fixed. The DRAM initialization code for our OcteonTX2 CPU is > almost as large, though this code has been cleaned up and re-written. There > really is no way to avoid this. The OcteonTX and OcteonTX2 DDR initialization > code is similar to that for Octeon. In the case of U-Boot on our ARM SoCs, > though, initialization is done before U-Boot is loaded. > > I'll move the init code to drivers/ram/marvell/octeon. It will be about twice > as large as the AXP driver (which only handles DDR3). The serdes init code I > figure could go under drivers/soc/marvell/octeon. > > I noticed that there are several directories under drivers for memory. > There's > drivers/ram, drivers/memory and drivers/ddr. These should be consolidated. I > think some code might be able to be common, such as the SPD decoding code. >
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Thursday, October 31, 2019 3:36:10 AM PDT Wolfgang Denk wrote: > Dear Aaron, > > In message <1932577.QJWW3v3lL8@flash> you wrote: > > We do this relocation as well, however the way we do it is by changing a > > couple of TLB entries. This lets U-Boot begin execution from any memory > > location, be it flash, L2 cache or RAM. It also lets us statically link > > U-Boot to run at a fixed address, in our case 0xC000. The relocation > > happens > It seems you have missed the primary purpose of relocation. The > interesting thing is not the start address, but the end address of > U-Boot in memory, as we alsways try to place the U-Boot code and data > at the very end of the available memory (and yes, this includes > systems which can cam with different memory sizes). Additionally, we > want to be able to reserve additional memry at the end of RAM, above > U-Boot, so it can even be kept across warm boots. Features like > protected RAM (PRAM), shared log buffers, shared video memory etc. > come in to mind here. This is exactly what we do. We use a high virtual address and always move it to the end of physical memory. > > > This might be something to consider in the future on some platforms where > > "relocation" could be performed by just adjusting the TLB or page tables. > > MIPS makes this particularly easy. > > This cannot be done, not without castrating U-Boot from a number of > features that require allocation at the end of the available RAM, > see above. > > > That's fine. The code is actually quite small. It has some custom APIs > > unique to our needs. We have need to call into the phy code from these > > applications. I don't know if this could work with the general API or > > not. One reason we did > 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). > > Best regards, > > Wolfgang Denk -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > Dear Aaron, > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > Currently we are using 39MB under arch/mips. I think I can easily cut this > > down to 15MB or smaller, especially by moving some code here to the > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > It will still be a large SoC, though. > > Have you already looked at formal requirements, like coding style > etc.? Did you ever run your additions through checkpatch.pl, for > example? We did follow the formal coding style. Everything will go through checkpatch. My biggest complaint about it is the 80 columns for debug and other print statements. > > Best regards, > > Wolfgang Denk -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Thursday, October 31, 2019 6:26:51 AM PDT Tom Rini wrote: > On Wed, Oct 30, 2019 at 11:36:19PM +, Aaron Williams wrote: > > On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote: > > > External Email > > > > > > -- > > > > > > On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote: > > > > Hi all, > > > > > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > > > and merging it upstream. > > > > > > [snip] > > > > > > I want to jump back up back to the top of this thread. And first I want > > > to say that I am glad that there is official desire to upstream support. > > > This is good. My concern is that the plan seems to be, at a very high > > > level, "get everything we have for every feature upstream". But as been > > > said elsewhere this would roughly double the total LOC for the project, > > > and it's not like we're a new project with a small handful of things :) > > > It's impossible for the community to review that much code in any > > > meaningful way over anything less than a period of several years. I > > > know you've said that to support various customer use cases you need all > > > sorts of other things, and while I'm certain that's true, I believe the > > > plan needs to be to step back and pick the smallest possible testable > > > unit, and upstream it. And add to it, small pieces at a time. Thanks! > > > > It might be easier if I were a maintainer for our SOC to limit the needed > > review of a fair bit of the code. I have already found I can cut out a > > large chunk of our code by removing support for our older models. Much of > > the code has been very well tested, for example our serdes initialization > > and DRAM initialization code. That's not to say I can't do some cleanup. > > Don't worry, I totally expect you to become the maintainer for your SoC, > that's key to making sure the SoC-specific stuff is done right :) But, > you're not the first big SoC to migrate from an internal fork to > mainline and have a seemingly impossible number of LOC to deal with. > It's why I'm saying you need to start with something absolutely as small > as possible, and move forward. > > > The changes to U-Boot itself should be relatively small as long as I can > > keep much of our code under arch/mips/arch-octeon and > > arch/mips/cpu/octeon much like how our ARM code is. For anything that is > > applicable to other architectures I will place it in the appropriate > > locations. > > > > Our ARM code is quite a bit simpler than MIPS because on ARM most of the > > heavy lifting is done by our "BDK" bootloader as well as ATF. On ARM, > > U-Boot doesn't need to deal with SFPs, serdes initialization, DRAM > > initialization, hot plug or a myriad of other issues. > > > > I noticed the same with X86. If it weren't for these other layers the X86 > > code would also be quite large. > > > > I have already identified quite a few very large files that will be > > removed, such as the error handling code for or Octeon2 and earlier CPUs. > > > > Additionally I have identified a number of register definition files I can > > get rid of, including one that's 2.3MB in size! These files tend to be > > huge because they contain definitions for every single chip and revision > > as well as big and little endian definitions. On top of that, there are a > > huge number of comments. Each field contains all of the text that is in > > our hardware reference manuals. There is no dearth of comments. I should > > be able to cut the size of the remaining files to 1/4th their current > > size or even smaller. > > > > Some files will still remain quite large, however, such as our serdes > > initialization and DRAM initialization code (which I plan to re-architect > > because the original author didn't believe in functions due to stack > > limitations. (it is well commented though). If you ever want to learn all > > the gory details of DDR4 link training and finding trends and so-forth > > it's all in there. The current memory initialization code is over 1MB in > > size. I plan to cut this down and break it up in a clean manner. The > > initialization code has grown in complexity and size over the years as > > various instabilities have been identified and fixed. The DRAM > > initialization code for our OcteonTX2 CPU is almost as large, though this > > code has been cleaned up and re-written. There really is no way to avoid > > this. The OcteonTX and OcteonTX2 DDR initialization code is similar to > > that for Octeon. In the case of U-Boot on our ARM SoCs, though, > > initialization is done before U-Boot is loaded. > > > > I'll move the init code to drivers/ram/marvell/octeon. It will be about > > twice as large as the AXP driver (which only handles DDR3). The serdes > > init code I figure could go under drivers/soc/marvell/octeon. > > > > I noticed that there are several directories under driver
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
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? It has been mentioned before, but just to be sure: this code which uses your new API is licensed under a GPLv2 conforming lincense? Best regards, Wolfgang Denk -- 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 If you believe that feeling bad or worrying long enough will change a past or future event, then you are residing on another planet with a different reality system. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Mon, Nov 04, 2019 at 04:44:18PM +0100, 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? > > It has been mentioned before, but just to be sure: this code which > uses your new API is licensed under a GPLv2 conforming lincense? And, to be blunt, if it is not, handling your non-GPLv2 applications via an EFI binary is the way forward, not extending the U-Boot binary ABI, in my opinion. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote: > Hi Wolfgang, > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > > Dear Aaron, > > > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > > Currently we are using 39MB under arch/mips. I think I can easily cut this > > > down to 15MB or smaller, especially by moving some code here to the > > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > > > It will still be a large SoC, though. > > > > Have you already looked at formal requirements, like coding style > > etc.? Did you ever run your additions through checkpatch.pl, for > > example? > > We did follow the formal coding style. Everything will go through checkpatch. > My biggest complaint about it is the 80 columns for debug and other print > statements. checkpatch doesn't complain about those when they use standard logging functions, however. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Monday, November 4, 2019 8:23:08 AM PST Tom Rini wrote: > On Mon, Nov 04, 2019 at 04:44:18PM +0100, 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? > > > > It has been mentioned before, but just to be sure: this code which > > uses your new API is licensed under a GPLv2 conforming lincense? > > And, to be blunt, if it is not, handling your non-GPLv2 applications > via an EFI binary is the way forward, not extending the U-Boot binary > ABI, in my opinion. 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. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Monday, November 4, 2019 9:22:16 AM PST Tom Rini wrote: > On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote: > > Hi Wolfgang, > > > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > > > Dear Aaron, > > > > > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > > > Currently we are using 39MB under arch/mips. I think I can easily cut > > > > this > > > > down to 15MB or smaller, especially by moving some code here to the > > > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > > > > > It will still be a large SoC, though. > > > > > > Have you already looked at formal requirements, like coding style > > > etc.? Did you ever run your additions through checkpatch.pl, for > > > example? > > > > We did follow the formal coding style. Everything will go through > > checkpatch. My biggest complaint about it is the 80 columns for debug and > > other print statements. > > checkpatch doesn't complain about those when they use standard logging > functions, however. It complains plenty about printf(), debug() and a number of other standard U- Boot logging calls. Regards, Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <5376617.97hUrJXovB@flash> you wrote: > > > 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. Ouch. I was afraid to hear that. Please be aware that your newly created API does NOT implement a GPL license exception. the only interface that allows for non-GPL code to be run under control of U-Boot is the standalone program interface, which is intentionally very restricted. In other words: what you are doing here is a clear (and intentional, which makes it even worse) GPL license violation. > > 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. It does not have to be linked. You access internal interfaces of U-Boot that have not been exported for non-GPL use, so your code still has to be licensed under GPLv2 or a compatible license. Best regards, Wolfgang Denk -- 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 "I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." - Dennie van Tassel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <1838672.aZrPjDvGh8@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 -- 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 I think animal testing is a terrible idea; they get all nervous and give the wrong answers. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Tuesday, November 5, 2019 12:37:26 AM PST Wolfgang Denk wrote: > Dear Aaron, > > In message <1838672.aZrPjDvGh8@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 0xC000). 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
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... > 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. Best regards, Wolfgang Denk -- 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
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Tue, Nov 05, 2019 at 02:13:13AM +, Aaron Williams wrote: > Hi Wolfgang, > > On Monday, November 4, 2019 9:22:16 AM PST Tom Rini wrote: > > On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote: > > > Hi Wolfgang, > > > > > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > > > > Dear Aaron, > > > > > > > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > > > > Currently we are using 39MB under arch/mips. I think I can easily cut > > > > > this > > > > > down to 15MB or smaller, especially by moving some code here to the > > > > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > > > > > > > It will still be a large SoC, though. > > > > > > > > Have you already looked at formal requirements, like coding style > > > > etc.? Did you ever run your additions through checkpatch.pl, for > > > > example? > > > > > > We did follow the formal coding style. Everything will go through > > > checkpatch. My biggest complaint about it is the 80 columns for debug and > > > other print statements. > > > > checkpatch doesn't complain about those when they use standard logging > > functions, however. > > It complains plenty about printf(), debug() and a number of other standard U- > Boot logging calls. Yes, but not about pr_debug, etc, which are what really should be used. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Tue, Nov 05, 2019 at 02:08:54AM +, Aaron Williams wrote: > On Monday, November 4, 2019 8:23:08 AM PST Tom Rini wrote: > > On Mon, Nov 04, 2019 at 04:44:18PM +0100, 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? > > > > > > It has been mentioned before, but just to be sure: this code which > > > uses your new API is licensed under a GPLv2 conforming lincense? > > > > And, to be blunt, if it is not, handling your non-GPLv2 applications > > via an EFI binary is the way forward, not extending the U-Boot binary > > ABI, in my opinion. > > 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. If there are parts of the EFI specification that we do not implement, but could implement, it would be a much appreciated contribution to the code. If once you're up in the EFI world there are things you cannot do that you need to do, that should be taken up with the UEFI consortium. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote: > Dear Aaron, > > In message <5376617.97hUrJXovB@flash> you wrote: > > > > > 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. > > Ouch. I was afraid to hear that. > > Please be aware that your newly created API does NOT implement a GPL > license exception. the only interface that allows for non-GPL code > to be run under control of U-Boot is the standalone program > interface, which is intentionally very restricted. > > In other words: what you are doing here is a clear (and intentional, > which makes it even worse) GPL license violation. > > > > 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. > > It does not have to be linked. You access internal interfaces of > U-Boot that have not been exported for non-GPL use, so your code > still has to be licensed under GPLv2 or a compatible license. I'm just following up to say that I agree with Wolfgang here. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
From: Wolfgang Denk Sent: Tuesday, November 5, 2019 3:36 AM To: Aaron Williams Cc: Tom Rini ; Daniel Schwierzeck ; 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
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Tom, From: Tom Rini Sent: Tuesday, November 5, 2019 6:16 AM To: Wolfgang Denk Cc: Aaron Williams; Daniel Schwierzeck; u-boot@lists.denx.de Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote: > Dear Aaron, > > In message <5376617.97hUrJXovB@flash> you wrote: > > > > > 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. > > Ouch. I was afraid to hear that. > > Please be aware that your newly created API does NOT implement a GPL > license exception. the only interface that allows for non-GPL code > to be run under control of U-Boot is the standalone program > interface, which is intentionally very restricted. > > In other words: what you are doing here is a clear (and intentional, > which makes it even worse) GPL license violation. > > > > 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. > > It does not have to be linked. You access internal interfaces of > U-Boot that have not been exported for non-GPL use, so your code > still has to be licensed under GPLv2 or a compatible license. I'm just following up to say that I agree with Wolfgang here. Sorry for the broken formatting (our IT department forces the Outhouse web client). I think there is some misunderstanding here. All of the code we include in U-Boot IS GPL or GPL compatible, including the API. "Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+, this does *not* cover the so-called "standalone" applications that use U-Boot services by means of the jump table provided by U-Boot exactly for this purpose - this is merely considered normal use of U-Boot, and does *not* fall under the heading of "derived work"." No part of U-Boot is included in these applications and no application code is included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files are under a BSD-like license, basically do whatever you want with the code but don't hold us responsible. The SDK code is also used in stand-alone applications as well as the Linux kernel, where derivatives were upstreamed long-ago. In any event, I think at this point we can remove this support. I don't think it's used any longer. It also looks like EFI does allow for vendor defined services. I hadn't looked at this code for a while but looking at it again it also appears the phy code has been removed. I think the remaining code for QLM configuration could be modified to just use a hook from some environment variables, removing this issue entirely. -- Tom Regards, Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message you wrote: > > > 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#GPLInProp= > rietarySystem > > This behaves exactly in the manner that is permitted by the GPL. > They are completely separate programs. Are they? You wrote: "There is no linking. Only a call table descriptor is published in a named block of memory." I can only interpret from that that there is a call table, where your applications call into interfaces that have not been exported for non-GPL use. This is not what I call "completely separate". Best regards, Wolfgang Denk -- 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 A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote: > Dear Aaron, > > In message you wrote: > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses > > _old-2Dlicenses_gpl-2D2.0-2Dfaq.en.html-23GPLInProp-3D&d=DwIDaQ&c=nKjWec2b > > 6R0mOyPaz7xtfQ&r=3yfMNumMHGMnOfmVc0dViBi3fJfF8ZXRL_aRWSIGwm4&m=a19tqjpYreP > > S1AEd1tHmUya1hcqvHmvs57fTB9c5I50&s=rp_kzh8HU_FV56RrXpf-0DCuegF0rrporRqWwdT > > MiR0&e= rietarySystem > > > > This behaves exactly in the manner that is permitted by the GPL. > > They are completely separate programs. > > Are they? > > You wrote: > > "There is no linking. Only a call table descriptor is published in a > named block of memory." > > I can only interpret from that that there is a call table, where your > applications call into interfaces that have not been exported for > non-GPL use. This is not what I call "completely separate". > > > Best regards, > > Wolfgang Denk Calling directly into U-Boot would be bad. We don't do that. It wouldn't work anyway on our 32-bit bootloader due to the required TLB mapping. There is no call table. There is a single XKPhys address that points to some assembly code that saves the state of the calling application and sets up the memory mapping and stack for U-Boot (we map it to 0xC000) then look at an opcode that's passed and parameters. From there it performs one of several functions based on the opcode. On the way out the reverse is done, the state is restored and the TLB restored before returning to the outside application. The calling application has its own virtual memory map, so that has to be saved and restored on entry by the assembly code as well. Since U-Boot uses a TLB for mapping, it's just not possible for an outside application to call into U-Boot using a function table, so everything must go through the one assembly function. The old U-Boot code was written before EFI support was added. It looks like I'll be removing it anyway, though. We have never exported any U-Boot functions save for the assembly code and the API functionality. The API functionality was not usable by our applications since our applications were typically 64-bit whereas our old U-Boot was 32-bit running in mapped memory (0xC000/0xC000) and physically located at the top of physical memory. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wed, Nov 06, 2019 at 10:18:45PM +, Aaron Williams wrote: > Hi Wolfgang, > > On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote: > > Dear Aaron, > > > > In message > > > you wrote: > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses > > > _old-2Dlicenses_gpl-2D2.0-2Dfaq.en.html-23GPLInProp-3D&d=DwIDaQ&c=nKjWec2b > > > 6R0mOyPaz7xtfQ&r=3yfMNumMHGMnOfmVc0dViBi3fJfF8ZXRL_aRWSIGwm4&m=a19tqjpYreP > > > S1AEd1tHmUya1hcqvHmvs57fTB9c5I50&s=rp_kzh8HU_FV56RrXpf-0DCuegF0rrporRqWwdT > > > MiR0&e= rietarySystem > > > > > > This behaves exactly in the manner that is permitted by the GPL. > > > They are completely separate programs. > > > > Are they? > > > > You wrote: > > > > "There is no linking. Only a call table descriptor is published in a > > named block of memory." > > > > I can only interpret from that that there is a call table, where your > > applications call into interfaces that have not been exported for > > non-GPL use. This is not what I call "completely separate". > > > > > > Best regards, > > > > Wolfgang Denk > > Calling directly into U-Boot would be bad. We don't do that. It wouldn't work > anyway on our 32-bit bootloader due to the required TLB mapping. > > There is no call table. There is a single XKPhys address that points to some > assembly code that saves the state of the calling application and sets up the > memory mapping and stack for U-Boot (we map it to 0xC000) then > look at an opcode that's passed and parameters. From there it performs one of > several functions based on the opcode. On the way out the reverse is done, > the > state is restored and the TLB restored before returning to the outside > application. The calling application has its own virtual memory map, so that > has to be saved and restored on entry by the assembly code as well. > > Since U-Boot uses a TLB for mapping, it's just not possible for an outside > application to call into U-Boot using a function table, so everything must go > through the one assembly function. The old U-Boot code was written before EFI > support was added. It looks like I'll be removing it anyway, though. We have > never exported any U-Boot functions save for the assembly code and the API > functionality. The API functionality was not usable by our applications since > our applications were typically 64-bit whereas our old U-Boot was 32-bit > running in mapped memory (0xC000/0xC000) and physically > located at the top of physical memory. Alright, so I think here's the important thing to look at moving forward. In mainline U-Boot, the options for communication between closed source components and U-Boot itself (where GPLv2 is the minimum license) are either the defined ABI or making use of the EFI ABI. We do not want to add or support a 3rd method. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wed, Nov 06, 2019 at 12:03:23AM +, Aaron Williams wrote: > Hi Tom, > > > From: Tom Rini > Sent: Tuesday, November 5, 2019 6:16 AM > To: Wolfgang Denk > Cc: Aaron Williams; Daniel Schwierzeck; u-boot@lists.denx.de > Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support > > On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote: > > Dear Aaron, > > > > In message <5376617.97hUrJXovB@flash> you wrote: > > > > > > > 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. > > > > Ouch. I was afraid to hear that. > > > > Please be aware that your newly created API does NOT implement a GPL > > license exception. the only interface that allows for non-GPL code > > to be run under control of U-Boot is the standalone program > > interface, which is intentionally very restricted. > > > > In other words: what you are doing here is a clear (and intentional, > > which makes it even worse) GPL license violation. > > > > > > 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. > > > > It does not have to be linked. You access internal interfaces of > > U-Boot that have not been exported for non-GPL use, so your code > > still has to be licensed under GPLv2 or a compatible license. > > I'm just following up to say that I agree with Wolfgang here. > > Sorry for the broken formatting (our IT department forces the Outhouse web > client). > > I think there is some misunderstanding here. All of the code we include in > U-Boot IS GPL or GPL compatible, including the API. > > "Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+, > this does *not* cover the so-called "standalone" applications that > use U-Boot services by means of the jump table provided by U-Boot > exactly for this purpose - this is merely considered normal use of > U-Boot, and does *not* fall under the heading of "derived work"." > > No part of U-Boot is included in these applications and no application code > is included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files > are under a BSD-like license, basically do whatever you want with the code > but don't hold us responsible. The SDK code is also used in stand-alone > applications as well as the Linux kernel, where derivatives were upstreamed > long-ago. > > In any event, I think at this point we can remove this support. I don't think > it's used any longer. It also looks like EFI does allow for vendor defined > services. I hadn't looked at this code for a while but looking at it again it > also appears the phy code has been removed. I think the remaining code for > QLM configuration could be modified to just use a hook from some environment > variables, removing this issue entirely. Not needing to worry about how to deal with this support is indeed the best case for everyone, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
