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. >>> 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. >>> 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. >> 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).
------------------------------------------------------------------------------ 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
