Am 01.04.2013 21:29, schrieb Andrew: > 01.04.2013 18:59, KP Kirchdoerfer пишет: >> 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. > I don't like 3.6 kerel because 1) we should maintain 2 kernels for LEAF > and 2) 3.6 kernel is EOL - no fixes wil be available.
I agree, and shurely have no intention to support two different kernel versions, esp not one that is outdated. I wanted to start with working code (successfully booting on the rpi...) and then work on remaining issues, like fixing packges that does not build, improving the toolchain where necessary, building images etc - I hope that in the meantime a mainstream kernel will be available that already includes support for the raspberry pi so we will have a unique kernel source for all images. That also means that I currently do not expect that a raspberry image will be available with 5.0, but probably with 5.1. >> >>>>>> 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 :) > I'll try to look on it, maybe at weekend. ok. >>>>>> 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. > What thing you don't understand? I just have read more about this options :) > Also, try to look on OpenWRT, that is placed on some SOHO router > (Atheros one will be good). It has read-only root on squashfs (so all > content is read from flash), it has tmpfs that mounted over the toop of > root, and all writes to root actually are written on tmpfs. This is easy > way to have transparent r/w root in case of squashfs. > Of course, we can use current tmpfs scheme... But for small embedded > devices with 16-32M RAM it'll be too heavy. >>>>> 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). > No, this isn't the same image. Think about initrd as .tar.gz package > (it's really .cpio.gz, but cpio archiver is enough similar to tar - if > we will not look into archive structure; both types of archives contain > uncompressed files with header that specifies place of file into archive). Ok, but then I do see the content of initmod on the rpi box in /lib/modules....? >> 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 > This isn't Geode bug. This is syslinux bug/feature/specific behavior. > Also, w/o leading slashes even fresh syslinux should boot LEAF. So I > don't know why they are really needed. I'll change it. > Initmod package is actual only for platforms with multiple target > hardware - as I said, for embedded system we can just include required > drivers into kernel and remove initmod at all. We will not have any > memory profit from modular drivers - because all essential drivers will > be loaded at boot from modules (possible exclusion - USB flash driver > with SCSI subsystem, that is ~200 kb - but in most scenarios embedded > device will be useless w/o USB flash with packages, so it'll be loaded > in any way); and modular drivers have some overhead for function call > time and for memory footprint. > > x86, from other side, requires many drivers for different hardware - so > modular architecture will save RAM (unneeded drivers shouldn't be loaded). Yes, but the toolchain should be as seamless as possible. So it's the question where to make the cut: - We can add all drivers for rpi into the kernel (if you call the rpi as embedded box) and modify the toolchain not to build initmod and create a buildpacket setup to not search for initmod, - Or we don't touch the buildtool part (except configuration) and modify buildpacket to merge initrd and initmod into one file. at least that's how I understand it right now, maybe I'm simply wrong. kp > This is one idea why I choosed to separati enitrd and initmod packages. > Other - because if we'll have multiple embedded platforms, we should > provide different kernels for each; with same userland. Like as x86, but > for each board we'll have separate kernel (ten boards - ten kernels). > And it'll be better to completely separate kernel and userlevel packages > to simplify building process. If one platform maintainer will decide to > update kernel/kernel config - we shouldn't worry about userland packages > rebuild; and userland can be built separately of kernel (new release > shouldn't mean all kernels rebuilding). So in future we can completely > separate kernel and userland building. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
