On Wed, Apr 08, 2015 at 07:24:34AM +0200, drEagle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Le 07/04/2015 02:39, Tom Rini a écrit : > > On Sat, Apr 04, 2015 at 06:13:18PM +0200, drEagle wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Le 03/04/2015 23:46, Vagrant Cascadian a écrit : > >>> On 2015-03-25, drEagle wrote: > >>>> Le 21/03/2015 15:53, Vagrant Cascadian a écrit : > >>>>> It seems that OpenRD Ultimate with u-boot 2015.04-rc3 and newer no > >>>>> longer builds from source, both in Debian and with mainline git. It > >>>>> appears to have overgrown the size limits set for it: > >>>> > >>>> Looks like the NAND partition map had to be changed to give more space > >>>> for u-boot. > >>> > ... > >>> I'll likely remove openrd_ultimate from future uploads to Debian if I > >>> can't get confirmation about how to fix this properly. > >> > >> The same may be a problem for SHEEVAPLUG and GURUPLUG, may be also all > >> KIRKWOOD derivatives. > >> We need to get a more robust and compatible way to define the NAND PARTS, > >> the BOOTLOAD and the NAND UPGRADE. > >> Each distribution has differents needs. > >> > >> It's a discution needed upstream because it ill impact all distribution > >> and users. > > > > It's possible that by removing some CONFIG options things can fit under > > the size limit and not require env to be moved. > > I do not agree with a stay in the past situation. > I have proposed these refresh to help kirkwood plugs become useable. > This is a platform that was looking promising and had also been not so user > frendly in the beginning. > The features like the sheevaplug MMC/SD driver was a pain. > UBOOT have greatly gain in a peace of software more robust that in was few > years ago. > For Kirkwood Sheevaplugs we have also a device, SD cards, which was simply > unuseable. > > So I decided to get this driver upstream. > > So what now ? > USB layer get fixed. > IDE layer get fixed. > UBIFS is a new standard. > EXT4 support helpfull. > DEVICETREE is needed for linux kernel support. > > What I proposed is to get a refresh for : > - - The NAND partitions (with a possible study to be friendly with most > distributions around) > - - To discuss about the better BOOTSTRAP method (I may used a script, > propose defaults ENV. We may need to boot from IDE, USB, NAND, NET, ...) > > It's an open discussion to get a friendly users, understand with the lesser > patch in each distribution, with the most possibility afford. > > I do not think that, all around customisation is the solution.
I am fine with whatever the general community of users for these parts wants to do of course. And more functionality being used is better for everyone IMHO. The only thing I would really make a hard suggestion on is making sure that when growing the partitions to make sure it's got as much room as feasible for future growth. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
