Op 2 jun 2010, om 15:57 heeft Tony Lindgren het volgende geschreven: > * Jarkko Nikula <jhnikula@xxxxxxxxx> [100602 16:06]: >> On Wed, 2 Jun 2010 14:56:30 +0200 >> Koen Kooi <koen@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >>>> How about add-on cards for e.g. BeagleBoard? It would be nice feature >>>> if a kernel module for that particular add-on card can do the muxing >>>> without needing to specify them on cmdline. I.e. if you are switching >>>> between cards there is no need to figure out new cmdline for each of >>>> them. For me even "rootwait" is sometimes too difficult to remember :-) >>> >>> What we (as in beagleboard.org) are currently doing is this: >>> >>> u-boot: >>> >>> http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a >>> http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224 >>> >>> kernel: >>> >>> http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90 >>> >>> It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM. >>> >> Problem is that amount of expansion boards is practically unlimited so >> patching bootloader and board file could come quite maintenance effort. >> >> Of course there are some lets say generic boards but bunch of in-house, >> DIY, etc. boards and there is no point to patch common bootloader and >> kernel board files because of them. > > Just saveenv the kernel cmdline options in u-boot? People typing 'saveenv' without checking account for like half of the RMAs for beagleboards.... Also, the beagleboard xM has no NAND, so I'm using a boot.scr uboot script on SD to set params. But the problem we are trying to solve is this: "Support all beagle expansion boards mentioned in http://elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs out of the box" That means that a user can plug in an expansion board, apply power and it will "just work". That's the case now for the zippy, zippy2, trainer and beaglefpga boards with the current u-boot and kernel setup. I agree it doesn't scale, but I haven't seen any actual effort by the beagleboard/omap3 community to make the muxing and initializing the board (i2c, spi, gpio, rtc) work completely in the kernel :( regards, Koen-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
