[U-Boot] [PATCH v9 25/30] arm: Remove support for smdk6400

[Benoît Thébaudeau]

Hi Lukasz,

On Friday, March 22, 2013 11:12:14 AM, Lukasz Majewski wrote:
> Hi Benoît,
> 
> > Hi Lukasz,
> > 
> > On Thursday, March 21, 2013 10:43:49 PM, Lukasz Majewski wrote:
> > > Hi Benoît
> > > 
> > > > The migration of boards from Makefile to boards.cfg was due for
> > > > v2012.03, but smdk6400 did not follow, and it does not build, so
> > > > move it to scrapyard. It will still be possible to restore it
> > > > from the Git history before fixing it.
> > > > 
> > > > Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau at advansee.com>
> > > 
> > > There were several attempts to convert the smdk64x0 to boards.cfg
> > > (in the end of 2012). For several reasons they failed.
> > > 
> > > I was planning to prepare the whole patch series, which would also
> > > include some improvements (like USB + DFU).
> > > 
> > > However, now I see that there is a firm deadline, so I will resubmit
> > > converting patches ASAP.
> > 
> > Will this series also fix the build of the smdk6400 and port it to
> > generic SPL?
> 
> I posses smdk6410 board. I suppose that those (6410 and 6400) are very
> similar.
> 
> Fixes provide building this board with eldk-5.2.1 toolchain (for armv6
> version).

Good.

> Also it will convert the board to boards.cfg.

Good.

And regarding SPL? NAND SPL is on its way to obsolescence, so boards should
switch to generic SPL.

Also, the MMU stuff that was in relocate_code() should be moved out of it (see
my 29/30).

> > I don't know if I should rebase on your series or if you should
> > rebase on mine. My series could be split at this patch in order to
> > apply its beginning ASAP, but that would still make a v10 and
> > postpone the end of it.
> 
> I can rebase on top of your series. Mine patches are rather small.
> It is up to your convince - I will adjust.

My series was about to be applied, so I'd prefer if you rebased on mine. Also,
if your series is brand new, it can't make it into the upcoming release, so it'd
be better not to have one more release with a broken smdk6400, and you'll fix it
for the following release.

So, basically, what you will have to do in your series is:
 - pseudo-revert my 29/30, moving MMU stuff out of relocate_code(),
 - revert my 27/30,
 - pseudo-revert my 25/30, moving smdk64x0 to boards.cfg, fixing its build, and
   switching it to generic SPL.

Best regards,
Benoît