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

[Andrew Jeffery]

On Wed, 27 Feb 2019, at 10:04, David Thompson wrote:
> 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.

Great, I'll take a look when I get a chance.

> 
> 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
> > 
> > 
> >
>