On Mon, Mar 1, 2010 at 7:02 PM, Hector Oron <zu...@debian.org> wrote: > Hello,
hi hector, this is a timely message / issue to raise: it's very relevant for the (newly discovered) CT-PC89E arm netbook which a friend of mine found. > Nowadays, the number of devices (non x86) is growing and growing. > Lots of these devices have not upstream linux kernel support, which > makes it a bit harder to maintain in the context of debian-installer. in the case of the CT-PC89E, we haven't yet taken on the burdensome and patient task of explaining the implications of the GPL to the factory, yet, and of the need and obligation for them to provide the GPL source code of both the linux kernel _and_ of the u-boot startup. i'm not mentioning this in order for people to go, "well, you're a fool, and you can expect every problem you get, can't you, and don't expect anyone on any debian mailing to ever provide you with any assistance whatsoever". i'm mentioning it because with the increased uptake in guhoogul anderoyd, the complete lack of understanding of the hardware manufacturers - chinese - for the implications and obligations of the GPL is going to be much more commonplace. thus, _realistically_, it makes sense to take into consideration that some devices aren't going to _immediately_ get the linux source code, and thus the fact that there may be binary-only linux kernels to work from - initially - would also need to be taken into consideration. > Also, afaict, debian-installer team does not like to add complexity to > d-i, which I understand, so it has better maintainability in the > future. > > Also live-installer could be the path to track for such kind of > devices, but again, live-installer was not meant for such purposes and > I believe maintainer won't be happy to add such extra features. > > Ubuntu people has been working on a nice tool (evolution from > build_arm_rootfs) named 'rootstock' which basically prepares a > filesystem for ARM targets. yes - i heard about this. i did the hack-job approach before i'd heard of it: qemu for ARM, installed rsync, then rsync'd the root filesystem out. not ideal, but it did the job. > Which is best way forward, in your opinion, for supporting non-x86 > arches installations (even installation done from a x86 platform)? > (debian-installer, live-installer, rootstock or start from scratch) there are two different main categories of systems. the first is one where you have access to the storage device: it can be removed (SD card), the system can somehow be booted from SD card, USB, etc. whatever it is, it's possible to just "blop" a root filesystem onto it, and go. for these, i think the absolute ideal case would be to have a netboot installer which can replace itself. for example, by creating a ramdisk, pivot-rooting onto it and then umounting the root filesystem. exactly the _opposite_ of initrd :) then the root filesystem is free to be wiped out, and the "real" OS installed. variations on this theme include the CD / ISO "searcher" - the usbstick stuff. having pivot-rooted into a ramdisk, it would be handy to have an option of going hunting on usb and other storage for iso filesystems or iso images. [i imagine that this is pretty much what, or is near-as-damnit similar to what debian-live does, but that's another story] the second case is where you have absolutely no chance of gaining access to the root filesystem in any kind of "normal" sense. this is the example of the CT-PC89E: what we've got, that's it, we're hosed (for now), and we have to work within the structure that the factory has imposed, which is this: http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile this is our "way in", because they've followed that procedure, and it turns out that yes, we can press-and-hold power and both mouse buttons, activating the factory's "upgrade" procedure, and thus "drop" the contents of a .tgz archived root filesystem directly onto the NAND flash, by creating our own "datang-epc.tar.gz". this was how i managed to get debian/lenny onto the CT-PC89E: http://elinux.org/CT-PC89E_Debian now, what would have been _really nice to have_ would have been a debian-installer tarball (as described in case 1, with the preparation to get itself into a ramdisk that's then pivot_root'd) which could be unpacked onto the NAND flash by the hardware manufacturer's "upgrade" procedures, and then, after a reboot, it would go directly into the debian installer etc. etc. just as in case 1). and no, right now, we don't even have access to the serial console on which u-boot is displaying its startup messages: there's an unpopulated header on the CPU+RAM+NAND SO-DIMM. other important caveats: * the binary-only kernel we're working with, they haven't even bothered to put in ext2,3 or 4 and so despite the u-boot-loaded initrd being able to gain access to the ext2 root filesystem, we can't mount any partitions other than FAT, once debian is actually running. the implications of this are that ISO images searched for (and loop-mounted) NEED to be capable of being searched for on "any kind of media" i.e. not just extN but also FAT. * installing a kernel should not be assumed as part of the debian installer phase, nor should grub, grub-efi, lilo, u-boot or in fact any boot loader or kernel at all should be assumed to be installable or required to be installed. * the binary-only kernel we're working with: whilst they've set up the /dev/fb0 through to /dev/fb2 for LCD, VGA-out and TV-out, they *haven't* compiled in any console fonts!! thus, it cannot be assumed that there will be any /dev/ttyNs available (!) or if you do try to use them, they'll be black on black squares! and, therefore a libsvga or x-windows-based installer will be required (helloooo xserver-xfbdev, hello upstream-unmaintained xserver-kdrive, pleased to ironically meet you: you'll do nicely for fitting into a pivot-rooted ramdisk, i'm so pleased that your build instructions are described here: http://kemovitra.blogspot.com/2009/10/linux-compiling-xorg-kdrive-server.html) questions to consider: how much of this is simply one-off effort by me to regain control over hardware and thus be in a position to give better feedback to the factory _despite_ their lack of information to us right now, and how much of it would be beneficial to actually implement because it's clear that it's going to be needed time and time again, only you can decide that one. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ced5f0f61003011255l515c13b3sba07e5f5019d9...@mail.gmail.com
