Support for Aspeed SoC in upstream U-Boot

[Maxim Sloyko]

On Wed, Feb 1, 2017 at 1:15 AM, Cédric Le Goater <clg at kaod.org> wrote:
> On 01/31/2017 01:00 AM, Maxim Sloyko wrote:
>> Hi all,
>>
>> I'm happy to announce that the basic support for aspeed (ast2500 eval
>> board, to be specific) has been accepted into the upstream U-Boot and
>> will appear in 2017.03 release.
>>
>> It's a bare minimum required to boot the board into U-Boot prompt, but
>> it already has WDT, Timer, Sysreset, Clock (very basic) and SDRAM MC
>> drivers, all implemented in C from scratch.
>
> Nice job. Thanks for working on this.
>
>> Of these drivers, WDT, Timer and Sysreset *should* be ast2400
>> compatible, but I haven't tested it,
>> since I don't have the hardware. Clock driver is not ast2400
>> compatible, but it should not be hard to make it such.
>
> indeed. a couple of dividers are different. SCU also.
>
>> SDRAM driver is not compatible and my understanding that the controllers
>> on ast2500 and ast2400 boards are different enough to require different
>> drivers.
>
> That is the main issue and the driver will be much more complex but
> maybe we can start with some assembly.
>

Didn't you have it all rewritten in C in your branch? The way SDRAM
driver is hooked up to the boot process is basically a "manual" call
in dram_init() function in board file, so if you don't want to have a
driver, you can still put your code in there and use it "as is".

>> I plan to continue expanding this support, which basically means
>> adding more drivers :)
>
> What is on your todo list?

My main goal is to have full Zaius support in upstream. It means that we need
* To read FRU: I2C driver, EEPROM driver (upstream already has one),
* To configure network: NIC driver (rewrite the one from ASPEED to use
Driver Model)
* To reset PHY: GPIO driver.

For these drivers to work properly we also need Pinctrl driver and the
support for I2C and MAC clocks in the Clock driver.

> Have you tried to rebase the current
> missing drivers, even in an hacky way, on top of upstream u-boot ?

I haven't tried it, though I don't see why that wouldn't work. There
should not be any conflicts between openbmc/u-boot and mainline
u-boot, apart from maybe in configuration files (Kconfig, Makefiles,
board configs)
In addition to that, the amount of work needed to make it work
properly (i.e. "u-boot way") does not seem unreasonable, so I'd rather
spend time doing that.

>
>
> Thanks,
>
> C.
>



-- 
Maxim Sloyko