Patches for U-Boot v2016.07-aspeed-openbmc?

[David Thompson]

Correct, for my BMC project I have made changes to OpenBMC's U-Boot image (v2016.07-aspeed-openbmc branch).

My goal is to "upstream" these changes to OpenBMC so that
I don't need to carry them around in my private repo.

I had already sent in one patch for review, addressed to Joel.
I will add you Andrew to that same email, since I did not know Joel was on leave.

Thank you,
- Dave


-----Original Message-----
From: Andrew Jeffery <andrew at aj.id.au> 
Sent: Monday, February 25, 2019 6:30 PM
To: David Thompson <dthompson at mellanox.com>; OpenBMC Maillist <openbmc at lists.ozlabs.org>; Joel Stanley <joel at jms.id.au>
Subject: Re: Patches for U-Boot v2016.07-aspeed-openbmc?



On Tue, 26 Feb 2019, at 04:59, David Thompson wrote:
>  
> The latest OpenBMC 2.6 is based on U-Boot v2016.07-aspeed-openbmc.
> 
> 
> I have a few patches I’m considering upstreaming,

"Upstream" in this case being OpenBMC, or to the actual u-boot project?

> one of which is a new
> 
> U-Boot machine/board. Should I send in patches based off this older,
> 
> but currently used, U-Boot branch?

If you're planning to send to the u-boot project you certainly can't base it on OpenBMC's fork :)

> Or, should I just be sending in
> 
> patches based on latest upstream U-Boot, with the intent that
> 
> eventually OpenBMC will be picking up a newer version of U-Boot?

Our u-boot is in a pretty bad state at the moment, and no-one really seems to have the time to improve it. Several factors make it a bit of a pain:

* Aspeed's chip team produces a monolithic platform.S file to initialise hardware and work around chip bugs where they can
* platform.S includes DRAM initialisation
* upstream u-boot includes a C implementation of DRAM initialisation that is almost but not quite entirely unlike the strategy used in platform.S

An easy way forward would be to dump platform.S for each generation into upstream, but the suspicion is we'd need a pretty damn convincing argument for it and for the removal of the C-based DRAM initialisation. Converting it all to C doesn't really seem feasible either, as we'd need to analyse all the assembly for each release of the SDK and port the new fixes on each release.
That's a pretty tedious task. Maybe some middle ground can be found though?

I do know that Joel is keen to turn the situation around andmay have some feedback when he comes back from leave.

In the mean time I guess you can send the patches here? At least that way you won't be carrying them in the yocto tree.

Andrew

> 
> 
> Thanks in advance,
> 
>  * Dave
> 
> 
> David Thompson
> 
> Sr. Staff Engineer, System SW
> 
> Mellanox Technologies
> 
> 1900 West Park Drive, Suite 290
> 
> Westborough MA USA 01581
> 
> Direct: +1 508-475-6375
> 
> 
>