Hi Andrew; Am 01.04.2013 17:24, schrieb Andrew: > 01.04.2013 16:40, KP Kirchdoerfer пишет: >> Hi; >> >> Am 31.03.2013 21:56, schrieb Andrew: >>> Hi. >>> 31.03.2013 20:26, KP Kirchdoerfer пишет: >>>> Hi all; >>>> >>>> with the help of David and based on the work of buildtool.org developers >>>> and many others, I was able to create a toolchain that produces a kernel >>>> and lrp's able to boot on a raspberry pi, to login, to get local net >>>> access and to ssh into the remote box. >>>> >>>> While it will be a long way to create images for the raspberry pi, it >>>> clearly shows that our toolchain is able to successfully cross-compile - >>>> something I've expected, but it's always good to see it really works. >>> Good work. >>>> Before I create a remote repository, so anyone has something to work >>>> with, I'm running rebuild from scratch. >>>> >>>> Some notes about what has been accomplshed and the remaining tasks: >>>> >>>> It's based on kernel version 3.6.11, because the patches are for 3.2 or >>>> 3.6, but not for our currently used 3.4 kernel. >>>> There is ongoing work to include the patches into the mainline kernel, >>>> so life will be easier in the future. >>> Maybe 3.2 patch (or 3.6) will lay on 3.4 kernel? Did you try? >> No; I wanted to start with something known to work. >> The rpi patches has been changed a lot between 3.2 and 3.6 AFAIK, so >> only option would be to test if the 3.6 patches can applied to 3.4 >> kernel, but I believe we'll see errors. And can't be shure if it is >> reliable afterwards. > There is also 3.3 branch: https://github.com/lp0/linux/tree/raspberrypi-3.3 > IMHO porting patches from near beanches aren't too painful.
Maybe, but IMHO we should not look backwards (adding possibly outdated patches). As I said there is ongoing work to include patches for raspberry pi into the mainline kernel, and this AND a kernel update for LEAF will make it easier. Currently I think, that going with a working 3.6 kernel is enough to work on issues we do have maintaining other architectures than X86; and those issues are not related to the kernel version I choosed for the raspberry pi. >>>> Not all packages build, esp kernel related packages, as expected, but >>>> also others fail, like iptraf, and I do see errors with perl >>>> Digest/SHA1, which also means shorewall will fail to start. >>>> I also had to remove e100* from kmodules to build moddb. >>> e100* should not even be compiled for rpi, like many others NICs - rpi >>> hasn't PCI/PCI-E busses, so it's waste of time and space. >> Yes; but we have the modules listed in kmdodules/common.tpl and >> kmodules/modulelist.common, so packaging fails if they are missing. This >> needs to be improved... > I think that it'll be no pb if some module in modulelist.common will be > missed. Or even all modules will be missed. > About common.tpl - firmware for e100 may be a pb, but we can do a hack - > just create empty folder, or folder with some dummy file. Well, if you can provide a solution I'd be happy :) >>>> The kernel config needs a review. Esp regarding modules. The kernel >>>> config as-is compiles ext4 and vfat into the kernel. >>>> >>>> It seems that the raspberry is not able to load more than initrd (initrd >>>> and initmod), so we have to concatenate initrd and initmod - with >>>> something like the following command: >>>> >>>> cat initrd.gz initmod.gz > initrd-rpi.gz >>> initmod on embedded platforms may be removed at all - all boot-time >>> modules may be compiled into kernel. One platform, one chipset, one >>> device set. >> That's what I did to get a start (compiled ext4 into kernel), but I >> don't like that solution. The raspberry pi is more flexible than other >> embedded devices, cause one can add all sort of things via USB. Some >> could be added later, but at least device drivers, filesystem drivers >> should be in initrd/initmod, so one has choice, while the ablity to >> remove it later. > This is common solution for embedded devices - to build all essential > drivers/modules as static-linked with kernel. Fo rpi this is file system > drivers, mtdblock driver and usb bus/usb flash driver. > Also, for embedded platforms there is common practice to use r/o rootfs > (like squashfs) with tmpfs mounted on top of it (via something like > unionfs) for optware/changed configs. Or even mounted tmpfs only for > some dirs, with r/o root. So IMHO we should decide what strategy we'll > implementing in future embedded targets: r/w root with 3rd-party patches > to kernel for this, or r/o root with r/w /etc, /lib/modules, /root, > /tmp, /usr and /var? 1st is more transparent for current state, more > flexible and is easier to implement, 2nd will require more work and will > cause more pbs on embedded platforms with errorous packages, but it'll > use vanilla kernel codebase. No comment here - I simply do not understand. >>> Or, if initrd concatenation is possible - some modules like usb flash >>> may be external, in initmod. >> The above command works, maybe even if the file extension is lrp instead gz. >> >> kp >> > If concatenated initramfs image is booted OK via boot loader - it's > good. But in generic case boot loader may fail to boot with such image, > or it'll extract just 1st part (initrd). I'll have to take a closer look, but I assume the concatenated image is the same as we had before we splitted initmod from initrd (as in 4.x). I'm starting to wonder about "multiple initrd files" when booting - see leaf-user and the 5.0-beta1 geode pb - the Alix geode based board supports multiple initrd, but _without_ the leading slash, where it seems to with the leading slash elsewhere, rpi does not support multiple initrd files, the same with qemu when booting arm-versatile, while it works if I test an i486 image in qemu...?? kp ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
