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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/22/2013 07:36 AM, Beno?t Th?baudeau wrote:
> 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@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.

Sounds like a plan to me.  Any objection Lukasz?

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRTEzlAAoJENk4IS6UOR1WAc0P/3sY9L/77ElcPtamWLX4csI7
8M+2mf414mNERjIRGeEf1nkVj+EN8RP4cf4RXHFMFz8W3KSfKyuGI9NFIWL+jfB+
Ox0yC7cA2tN8Q6WuINP4xaBKehSPwxg0WkHMgFETVspUXxKb3eL/z4K/vhzzstYC
zQ4SUf2ye/lbRfIx4ELXSWEBfln3SQafr6uaTKLTEzMjIy1KnB+AfZQmYIBcl5pr
Y13m8f4GzonnadXHps4R781zwxa1OvBxcW5ZQGg2OsfWpgv+eKKOAQRukr0jFlO4
cjmIIfyysoWaqyQ5x3RpIbiHK5iquZA8xLhao7XsIp8Ig9mZcnSQjLB/CRUUt/hM
GLGyzuecBvVJXli5ET7dDnGl+euIXhyaGF00oR9ndQHsv/Z6yG/+K3G8qrLV63n8
LhNgMMGxrZ7WubPlgUe/vqtzww6cyiQeZtdUSmZDmLgcwqmI/MhzHt+MLeKv3v0g
m3gvRFy8Ybf5Hk8hplRLSCe5JIMwRQ8sdbC/Io9gk6tFt5Am0nKqcip1Imt6+XEh
mlDyJrh/qQwzhG2i/ILCPba/+lGvctg14Ox/x2bSIZDkPClOahvz/geRmJQKJ7hG
+RZ0AG6qhhlGAQGpdoQbkBPGyYqURDRS/kVnDBj1ESGVauUto0GHMAJnn2s/mD46
uudHUsVPnCopWeOzbElR
=5Jo1
-----END PGP SIGNATURE-----