03.04.2013 18:25, KP Kirchdoerfer пишет: > 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. Ok. >>>>>> 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....? This boot loader knows that initrd may consists of separate chains. Generally - we don't know if bootloader supports such hack. >>> 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 > 1st method is more common. 2nd is based in bootloader specific behavior, and may not be supported for all bootloaders. And we need to add only boot-time drivers (FS/storage/flash), not all available. RPi is something between embedded box and usual PC, closer to embedded platforms. AFAIK it hasn't onboard flash with OS and boots from SD/USB (like generic PC), but it's based on SoC with unique kernel (kernel will not work on other SoC) and it uses embedded bootloader.
------------------------------------------------------------------------------ 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
