Hi Aaron, On Wed, Oct 23, 2019 at 4:50 PM Aaron Williams <awilli...@marvell.com> wrote: > > 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 0xbfc00000. 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).
I don't have any specific reply to your questions. But as a Cavium/Marvell customer I'm really happy to see this finally happening. I've got a few boards using the Octeon3 SoC that I'd be able to upstream once this code lands. > 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. > > 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. 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 receive path of a QSFP and another that handles the transmit > path. Further complicating things, with a QSFP it can be treated either as > XLAUI or as four XFI ports, so you can have four ports spread across two > chips, with each port using different slices of each chip. In the case of the > Inphi/Cortina chip, a single device can handle one or four ports based on the > configuration and it is configured by "slice" which is basically an offset > into the MDIO register space. We had to jump through hoops in order to have > this stuff work in a sane way in the device tree. We added entries for SFP > and QSFP slots in the device tree which point to the MACs, GPIOs and I2C bus > because pointing them to the phys just got too insane. This will need to be > ported to the new U-Boot. It should not break the existing support since most > of it was implemented outside of the core PHY handling code. In the port, it > would be far better if this could be integrated in. The SFP management code > is architecture agnostic as is all of the PHY support. The callbacks for the > SFP support are used by the MAC which then notifies the PHY since the MAC > often needs to reconfigure itself. It can handle some crazy configurations. > > While I see some phy drivers that we also support, i.e. Cortina, our drivers > tend to have a lot more functionality. For example, all of our phy drivers > that support firmware support commands for upgrading the firmware as well as > things like cable testing and other features. > > Our bootloader needs to be able to be booted from a variety of sources, > including SPI, eMMC, NOR flash and booting over the PCI bus from a host > system. This is one reason we use virtual memory. The other reason is that it > eliminates the need to perform relocation. Our start.S code handles all of > these different cases as well as exception handling. > > I will also say up front that the memory initialization code is a mess and > quite large (it was written by a hardware engineer who never heard of > functions). > > One thing is that this will break mips unless it is refactored like ARM is, > for example, separating armv7 and armv8. This way we could have > arch/mips/cpu/octeon. I did this with the old bootloader to separate our > stuff. I'm open to suggestions as for the naming. I don't see how we can > share much of the code with the other MIPS CPUs. > > All in all, I think the final port will add between 500K-1M lines of code for > the Octeon CPU. It is much more extensive than what is required for OcteonTX > since in the latter case most of the hardware initialization is done by > earlier stage bootloaders and the ATF handles things like SFP port management > and many of the networking operations. > > I'm not sure how well I'll be able to upstream all of this code at this point > since I was just handed this task. We already have at least 1M lines of code > added to the old U-Boot which is based off of 2013.08 with a lot of backports. > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
