Support for Aspeed SoC in upstream U-Boot

Support for Aspeed SoC in upstream U-Boot

[Maxim Sloyko]

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.

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. SDRAM driver is
not compatible and my understanding that the controllers on ast2500
and ast2400 boards are different enough to require different drivers.

I plan to continue expanding this support, which basically means
adding more drivers :)

-- 
Maxim Sloyko

Re: Support for Aspeed SoC in upstream U-Boot

[Cédric Le Goater]

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.

> I plan to continue expanding this support, which basically means
> adding more drivers :)

What is on your todo list  ? Have you tried to rebase the current 
missing drivers, even in an hacky way, on top of upstream u-boot ? 


Thanks, 
  
C. 

Re: Support for Aspeed SoC in upstream U-Boot

[Rick Altherr]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

FWIW, the Quanta Q71L I'm playing with uses an AST2400 so I'm interested in
getting those drivers moved to upstream.  I have a few other things to
finish before i'll get to it though.

On Wed, Feb 1, 2017 at 1:15 AM, Cédric Le Goater <clg@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.
>
> > I plan to continue expanding this support, which basically means
> > adding more drivers :)
>
> What is on your todo list  ? Have you tried to rebase the current
> missing drivers, even in an hacky way, on top of upstream u-boot ?
>
>
> Thanks,
>
> C.
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>

[-- Attachment #2: Type: text/html, Size: 2511 bytes --]

Re: Support for Aspeed SoC in upstream U-Boot

[Maxim Sloyko]

On Wed, Feb 1, 2017 at 1:15 AM, Cédric Le Goater <clg@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