On 17/05/2012 21:19, Oney Kursad-B37792 wrote: >>> * I am booting using a very recent kernel from kernel.org using >>> imx_v4_v5_defconfig >> >> I could be persuaded to include a suitable kernel rpm for this board >> provided it >> is as close as possible configuration-wise to the stock upstream (RH) kernel. >> Even more preferable would be a patch to add imx53 support to the upstream >> 2.6.32 kernel as I could then include an official (as opposed to >> "contrib/extras") kernel rpm for imx53 (imx51 would be useful, too, as it >> would >> mean support for the likes of Genesi Efika and Hercules ecafe). >> > Does it have to be 2.6.32? I'm using 3.4.0-rc7+ right now. Do you prefer > 2.6.32 > because it's what's normally shipped with the equivalent x86 version?
Yes. RHEL6 ships with a heavily patched 2.6.32, so ideally I would like to patch in the support for the SoCs we can support and ship the same kernel if at all possible. Otherwise it gets sufficiently far from upstream that it becomes questionable on the features/compatibility front. That's why at the moment I only have a kirkwood kernel (that was in mainline by 2.6.32). Having said that, if patches against the upstream 2.6.32 kernel aren't available, I'll be happy to provide a kernel in a SoC specific repository. For example, I was intending to include a Tegra2 kernel based on ChromeOS 2.6.38.8 (because that's what I use on my AC100 and I am comfortable that it will work). There is a 2.6.32 Tegra2 kernel based on the Android 2.2 tree, IIRC, but I hadn't used it much, and I'd have to patch out the Android stuff to keep it clean and then get a diff against vanilla - complicated and it would likely need manual intervention to make it work. > 2.6.32 might be a bit too old for this board. Yeah, I get that a lot. ;) > Freescale's BSP is at 2.6.35. It > usually takes a while for the changes in the BSP to get into the mainline (if, > ever). Sounds like somebody needs to be pushing it harder, and more importantly, writing code in a suitably clean way that makes it acceptable for upstreaming. > The ARM tree is also changing at a crazy pace. I am aware of that. I have read a number of rants from the maintainers on the subject. > For my experiment here, I built the mainline kernel without any changes, using > the stock defconfig file for these boards. The same kernel should also work > with > mx51 and mx6. Hopefully I can try those out soon too. Sounds good, but it'd be important that it works for specific devices that are available, e.g. Genesi Efika Smartbook (complete with the TFT panel EDID, and the other hardware). >> [...] >>> * The "plymouth" command seems to be missing (/etc/rc.d/rc.sysinit: >>> line 594) but init continues >> >> Plymouth isn't mandatory, but the anaconda installer always seems to install >> it. >> You can always: >> yum install plymouth >> > Whoa I wasn't aware that yum would work out of box! That's great! Well, that's why the rootfs is so minimalist. It's enough to get you up and running to the point where you can yum install anything else you need. :) >> [...] >> Hmm, what is ttymxc? Proprietary serial port on the imx devices? Doesn't it >> provide /dev/ttyS nodes? >> > You're correct. i.mx devices name their serial ports "ttymxcX" and do not > provide /dev/ttyS nodes. My version of tty.conf is hacky since I don't know > where > $TTY is set. Hmm... There is /etc/init/serial.conf. Is that perhaps closer to what you're after rather than hacking start-ttys.conf? Just since it IS a serial port. You might be able to get a udev rule together to make the ttymxc* appear as ttyS nodes/links. That might make the stock serial.conf. >> [...] >> >> yum --installroot=/path/to/chroot install<list of basic rpms> >> >> Then, force-re-install (rpm -Uvh --force --root=/path/to/chroot): >> - initscripts (or shutdown will hang due to one of the init scripts missing, >> haven't figured out why yet) >> - MAKEDEV (or you'll get start time complaints about vcsa user missing, >> again, >> don't know why the initial install doesn't add it) >> > This is a great starting point. Thanks! Note that there is also a "big" rootfs (browse the same directory on the ftp site, you'll see it). It was put together for people that have WiFi-only networking and want an easy life of using NetworkManager and nm-applet to configure the network (since you need a working network before you can yum install things). >>> * The alpha rootfs doesn't seem to have httpd although it is listed in the >>> 109 >>> rpms. How can I add this to the rootfs? >> >> Where do you see it listed? >> You can install it the usual way: >> yum install httpd >> (obviously you'll need working networking for that and internet access) >> > http://ftp.hands.com/redsleeve/yum/os/SRPMS/changed/httpd-2.2.15-9.el6.0.src.rpm Yup. The package is indeed available. I thought you meant it's in the rootfs. > Am I reading this incorrectly? I thought any rpms in "changed" meant > they have been modified by you to compile/work under ARM. I will try to > install > it using yum. Yup, that should just work. > Speaking of which - my board is on a private network. Would you guys be OK if > I > downloaded all RPMs using wget's recursive download option and set up a repo > on > my computer on the private network? Sure you can pull it down from ftp.hands.com mirror, it'll be a lot faster (the primary site is on a slow uplink). That can be a little behind on the updates, though, so if you need Firefox 10, pull that down off the primary site. Gordan
