-----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.thebaud...@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----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot