[U-Boot-Users] Breakage of board ports on new features.

[Timur Tabi <timur@freescale.com>]

Pantelis Antoniou wrote:
> Hi there,
> 
> So I'm cleaning my new 834x board in the time period of just two days.

I've been working on 834x changes for several months now, including adding 
support for the Freescale 8349 ITX.

> There's a commit with a bunch of 834x related fixes which totally broke
> the board port.

Sorry.  That patches were originally submitted back in September.  I guess you 
didn't see them.

> I understand that the main code is volatile, but it seems there's a  
> blatant
> disregard of keeping up a minimum of backwards compatibility.

I wouldn't say it's a blatant disregard.  Every time we add support for a new 
board, we need to consider code consolidation.  That often requires changes to 
core code that affects all the boards.

I have no knowledge of your board and your work.  If I had, I would have tried 
to accommodate you as much as possible.

> If someone changes code that's supporting a bunch of board ports, please
> put in some default macros to ensure past behaviour is preserved.
> 
> I.e. in this case the CONFIG_MPC8349 & CFG_FLASH_SIZE could have easily
> been defined with the defaults values for the non updated board ports to
> continue working.

CONFIG_MPC8349 should only be defined on 8349 boards, so there's no way to have 
a default value.  Either you have an 8349 or you don't.

CFG_FLASH_SIZE has always been a part of U-Boot, it just that it was never used 
on 83xx boards.  When my change to start.S that used that macro was introduced, 
we debated whether I should add some kind of default value, but Wolfgang said 
no.  It makes sense, considering the solution was to add this in start.S:

#ifndef CFG_FLASH_SIZE
#define CFG_FLASH_SIZE 8
#endif

You definitely do not want to introduce code like that into U-Boot, or any project.

I have a list of about a dozen significant changes that I want to make to 
U-Boot, many of which will change core files (and break board ports again).  The 
only thing I can do is make my intentions known in advance.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale