Friday, 12 February 2010

Kernel Development Status

Some bugs in the last release:
  • Some poking around with the DMFC made codecs and accelerated X11 not work. 3D would probably have been hosed too. Since we've not released the codecs yet it's not a huge problem but, the next release should be more sound and allow us to do a release
  • Enabling "Improved Transaction Translator Scheduling" broke the build - a patch I fixed for Ubuntu a long while ago but didn't seem to drag it into the new kernel
There are some other things but those were the most annoying. Freescale released a new BSP snapshot for February so we are rebasing on that. The result:
  • Efika MX: Integrates RT3070 Wireless properly
  • Efika MX: CompCache (ramzswap) working
  • A REAL patchset against 2.6.31 mainline (to bring up to BSP level) and then Efika patches on top, a special present for distro maintainers
  • More stable
  • Finally, HW accelerated codecs!
  • Finally, 2D Acceleration for X11 (but not OpenVG, sorry)
  • Finally, OpenGL ES 1.1 and 2.0!
  • steev@gentoo requested devtmpfs which should speed up boot and be much nicer to work with. We have to thank Canonical for backporting that to 2.6.31 :)
Those are the goals anyway. We will keep you posted. This is going to be kernel version 2.6.31.12-ER2-efikamx to differentiate between the ER1 releases (ER means "Engineering Release" for the curious). We're working our way up to PR (Production Release) which should square everything away for non-Aura kernels.

Secondly: we may release a kernel build based on Con Kolivas' "BFS" Scheduler to go with it, and for everyone who got (or still wants) a "1.0" Efika MX Developer Edition (the one with no case, flakey PATA and flakey ethernet) to make clusters, compile farms and generally do cool things with a lot of Cortex-A8s connected together, a custom kernel build that will Just Work (tm).

Long Term: Aura release (developer preview) and a kernel to go with it (2.6.32 or 2.6.33).
Posted by at 15:15
Labels:

2 comments:

  1. Some minor tweaks to the config I would like to see -
    Currently,

    CONFIG_UNIX98_PTYS=y
    CONFIG_LEGACY_PTYS=y
    CONFIG_LEGACY_PTY_COUNT=256

    Are all set... most modern machines only need
    CONFIG_UNIX98_PTYS=y
    This will dynamically create ptys as needed, and the max (at least on my Efikamx) is set to 4096.

    Also, unnecessary but somewhat nice:

    CONFIG_SND_PCM_OSS=y

    This allows for the creation of /dev/dsp which a lot of applications still use for outputting sound (no they shouldn't but, until they get fixed...)

    CONFIG_MAC80211_LED=y would be nice - this allows for LEDs to be activated based on the wireless (assuming we get working in kernel wireless - but it also helps for those who might have a usb rt2x00 based wifi device)

    I've been running devtmpfs here without issues, when you patch it in, I'd suggest

    CONFIG_DEVTMPFS=y
    CONFIG_DEVTMPFS_MOUNT=y

    Not really sure how much it matters, but something I always turn on is also

    CONFIG_MAGIC_SYSRQ=y

    which allows you to send various key combinations to the kernel regardless of state. (useful for rebooting when there is a hardlock mostly)

    There are a few other changes, but most of them are just silly little nuances of mine (turning off devices I don't/won't ever have) to reduce compile times.

    I also had tested the last 2.6.31 release of BFS, and unfortunately, the performance seemed snappy at first... and then after a little while just seemed to really lag behind - possibly this would be different if I was sitting at the Efika, and I'm really considering moving it into my room as opposed to the office, where I have a little more space, I just need to set up the networking in here properly.
    ReplyDelete
  2. steev, all noted, and you know we have the devtmpfs patches :)

    With the Smartbooks in we have to brush up a couple kernel versions for that too and try and integrate the two devices under the same driver set and kernel (it is possible to build a single kernel ;) - this is going to take a little while longer unfortunately as we're missing a few things and some of the support needs to be brought up to the current version (2.6.28 -> 2.6.31).

    We may check out how easy bringing up 2.6.33 is. rc8 is pretty close to release and it would allow us to basically bring in patches based on subsystem rather than Freescale's engineering releases, making for a cleaner kernel development process all round, but quite how much of that would be "wasted" once we get Aura released is under debate.
    ReplyDelete

Subscribe to: Post Comments (Atom)