[U-Boot] Cavium Octeon support for u-boot

Tue Aug 21 22:00:55 UTC 2018

On Tue, Aug 21, 2018 at 5:57 AM, Alexander Graf <agraf at suse.de> wrote:
> Hi Aaron,
>
> On 08/21/2018 08:07 AM, Aaron Williams wrote:
>>
>> The Octeon version of U-Boot is based off an older versin of U-Boot
>> (2012.07)
>> with a lot of features backported. For example, I have backported NVME
>> support
>> as well as the latest filesystem code. Since there have been significant
>> changes to U-Boot (i.e. 64-bit support) that were missing at the time it
>> would
>> be a massive undertaking to support the current U-Boot with Octeon or to
>> push
>> the Octeon support upstream. While in general the changes to the core
>> U-Boot
>> were fairly minimal for Octeon, there were significant changes to board.c.
>>
>> Hopefully we can get OcteonTX pushed upstream, however, since we are
>> tracking
>> the current U-Boot releases. I'm not sure how to go about doing this,
>> since I
>> would basically need a branch that I can maintain.
>
>
> What help exactly do you need here? We already do see partners shipping with
> random downstream versions of U-Boot on Octeon TX and every time I see them
> missing out on amazing efi_loader fixes, a tiny fraction of my heart dies
> :).
>
> So I would really like to see Octeon TX support simply developed fully
> upstream. That way your partners (and again their downstreams) can base on
> upstream U-Boot versions and are not tied to particular older versions that
> may be lacking features or bug fixes.

I maintain U-Boot for Octeon TX platforms at Cavium, which is based on
v2018.01 currently
and also tracking future releases.
efi loader support could be added but lacks customer use case as of now.
Upstream effort, atleast, for OcteonTX may kick off soon.

Regards,
Suneel
>
>
> Thanks,
>
> Alex
>
>
>>
>> No significant new work is planned for the Octeon SDK or bootloader,
>> however,
>> other than maintenance releases or adding features as needed by customers.
>>
>> Although the Octeon code makes extensive use of the device tree, it does
>> not
>> follow the dm model since that was not available when the U-Boot work took
>> place.
>>
>> The way the Linux kernel and simple executive applications are started is
>> also
>> unique to Octeon since multi-core support was also not present. This code
>> is
>> complex due to the way it has evolved while trying to maintain backwards
>> compatibility.
>>
>> Another potential barrier to upstreaming Octeon support is the fact that
>> it
>> makes heavy use of our rather large SDK and the sheer amount of code. A
>> quick
>> check with wc shows that we have around a million lines of code involved
>> under
>> arch/mips/cpu/octeon, arch/mips/include/asm/arch-octeon and board/octeon/
>> common. This doesn't include the various drivers, either, or our custom
>> board.c file needed for the required flexibility. Around 434Klocs are the
>> hardware register definition files, which admittedly are huge due to the
>> autogenerated nature of them and all the comments and big/little endian
>> support. These files are shared by U-Boot, the Linux kernel and simple-
>> executive applications.
>>
>> Some of the SDK and common board code is a mess since it tries to avoid
>> changes to the core of U-Boot. The networking and QLM configuration code
>> is a
>> bit of a  mess since it has evolved over many years. I'm sorry to say that
>> the
>> SFP/QSFP code I recently added just makes it worse due to the way it ties
>> in
>> phy support. There's duplication of code between U-Boot and our SDK in the
>> networking code, especially for things like phy link support. Some phys
>> also
>> just don't map cleanly into the U-Boot (or Linux for that matter) model.
>> Inphi
>> (Cortina) and the Microsemi (Vitesse) in particular do not map into the
>> one
>> phy per MAC model and all hell breaks loose with QSFPs where multiple MACs
>> share a phy or one MAC is split between multiple phys.
>>
>> We also have implemented hooks in a number  of key places that are missing
>> in
>> standard U-Boot. For example, we use a hook in the serial driver for a
>> number
>> of boards to poll the SFP/QSFP ports to detect when a module is plugged in
>> or
>> unplugged and to update activity LEDs.
>>
>> We have also implemented something similar to native application support
>> so
>> that simple-executive applications can make calls into U-Boot via a
>> context
>> switching mechanism. This is used for filesystem access as well as some
>> phy
>> operations with our 25G Liquid I/O boards.
>>
>> We also run U-Boot in KSEG2 rather than KSEG0 so that U-Boot is always
>> mapped
>> to the same virtual address regardless of where it is loaded in physical
>> memory. We do this for several reasons. First of all, it eliminates the
>> need
>> to perform relocation fixups. Second of all, this frees up the lower 2GB
>> of
>> memory space which can be a tight resource with a number of customers.
>> While
>> we compile it as n32, it could conceivably be compiled as n64 but continue
>> to
>> run in kseg2. n64 mode would simplify things by allowing the removal of
>> using
>> cvmx_read_csr/cvmx_write_csr to instead use readq/writeq. The mapping
>> between
>> virtual and physical addresses in our drivers would need to remain since
>> there
>> is no IOMMU.
>>
>> The code for bringing multiple cores out of reset and starting SE and the
>> Linux kernel would be tricky to port. There is a fair amount of assembly
>> code
>> I've maintained on Octeon in order to do this.
>>
>> Some of the fixes could also be pushed upstream, such as endian fixes we
>> have
>> made in the USB and ext4 code.
>>
>> Right now the main limitation to doing this is I'm pretty much the only
>> one
>> maintaining Octeon support for U-Boot across all of our boards as well as
>> working on support for OcteonTX and OcteonTX2. A number of OcteonTX
>> drivers
>> could easily be modified to work with Octeon, such as SPI, eMMC, NAND,
>> i2c,
>> etc. The main difference in many cases is the fact that OcteonTX
>> represents
>> devices as PCI devices (in addition to the device tree), whereas on Octeon
>> they are directly accessible and are only represented in the device tree.
>> There are huge differences, however, between OcteonTX and Octeon. With
>> OcteonTX, the memory and device tree are prepared by the BDK and ATF
>> before U-
>> Boot is started. On Octeon, often U-Boot is the first thing that is loaded
>> or
>> it is loaded by a simple SPI or eMMC bootloader and U-Boot is responsible
>> for
>> memory initialization and a lot of other things.
>>
>> -Aaron
>>
>> On Wednesday, July 25, 2018 12:55:36 AM PDT Chris Packham wrote:
>>>
>>> External Email
>>>
>>> Hi Aaron,
>>>
>>> On Wed, Jul 25, 2018 at 2:06 PM Aaron Williams
>>>
>>> <Aaron.Williams at cavium.com> wrote:
>>>>
>>>> While mainline U-Boot does not support Octeon, we have our own fork of
>>>> it
>>>> that I maintain. I am using the 2018.07 release with only a few minor
>>>> changes around the periphery to support the older version of U-Boot
>>>> Octeon is based off of.
>>>
>>> Just out of interest is there any particular barrier to Octeon support
>>> landing upstream? At $dayjob we have 4 platforms using various Octeon
>>> III processors. We're in the position of being stuck on an older
>>> version of u-boot because we can't bring support for our boards up to
>>> date without having to bring all the Octeon SoC support forward as
>>> well. Is there any interest from Cavium to get Octeon upstreamed?
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot