Hi, On 06/04/2008, Georges Toth <georges.toth@xxxxxxxxx> wrote: > > > > Congrats. > > > > > Thnx :-) > > > > Has anyone had any luck getting a 2.6.23 or 2.6.24 kernel working > > with the 800 or 810? When I was poking around with it a while back, > > I had to backport our stuff to .21 due to binary-only wifi drivers > > being incompatible with newer kernels. > > > > > AFAIK, no. > > I've just searched through some mailinglists and apparently it is possible > to use a more recent kernel with the n800/n810. > You basically compile a module called cx3110x which is open source [1], and > force to load a binary-only module (umac); in order to get wifi to work. > > I'll probably look into this over the next few days as time permits. > > > [1]: > http://repository.maemo.org/pool/chinook/free/c/cx3110x-module-src/ > > > > Also, if anyone knows of work done to figure out how the battery > > charge control, etc works on the 800/810 hardware, I'm highly curious. > Have not had the spare time to reverse engineer that stuff and if > > somebody's already done the hard work, so much the better. > > > I've only started to work on this last week, but AFAIK the only work that > has been done on the n800/n810 so far is to actually get the android patches > to work and get it to run. Poky (pokylinux.org) and mamona both work pretty well for everyday use on the nseries. Fortunately the userspace can partially ignore the charging issue because the RETU (now Betty) chip takes care of that in the hardware. Charging / charger-cable / power-button / battery-life states are readable from /sys and /dev. For more advanced power management such as that in maemo (battery type detection, battery quality, alarm wake-ups, watchdogs etc) more work would be needed as these are done in userspace on Maemo by services called DSME and BME and libcal (for retrieving information from OTP) that are closed-source and I believe not redistributable separately from Maemo. They are effectively the driver for the RETU and TAHVO chips whose registers / interrupts are accessed through /dev/retu and /dev/tahvo nodes. The best bet for a distro is probably to leave the maemo "initfs", which contains closed-source DSME / BME / flasher, in place and let the custom rootfs run on top of it. If you need some details about retu / tahvo driving / bootloading, I may be able to tell because I recently had to poke on it for a different project. > > Next would be to try to get the framebuffer driver hacked to work with the > m5 image ... the framebuffer driver doesn't support double buffering thus we > only get a black screen :-( I understand the userspace is going to be open-source at some point, which would render this work a bit useless. If it doesn't get open-sourced then it's a waste of time either way I think? Regards -- Please do not print this email unless absolutely necessary. Spread environmental awareness. -- 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
