Re: [leaf-devel] LEAF for raspberry pi
Le 7 avr. 2013 à 15:55, Andrew a écrit : >> > If we'll merge this branch into master in future - is it OK to merge > master into rpi branch? > Yes you can. But if the rip branch is a topic branch it's perhaps better to do a rebase like you do. Yves -- 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
Re: [leaf-devel] LEAF for raspberry pi
07.04.2013 14:45, Yves Blusseau пишет: > Le 7 avr. 2013 à 12:33, KP Kirchdoerfer a > écrit : > >> Someting might went wrong when rebasing, I had to hard reset my local >> repository to origin/rpi, cause pull and reabse gave resulted in errors. > Yes because rebase is bad for branch already committed. > Rebase rewrite the history so you have to do a git pull -f > It's better to merge master in rpi > > Yves If we'll merge this branch into master in future - is it OK to merge master into rpi branch? -- 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
Re: [leaf-devel] LEAF for raspberry pi
Le 7 avr. 2013 à 12:33, KP Kirchdoerfer a écrit : > > Someting might went wrong when rebasing, I had to hard reset my local > repository to origin/rpi, cause pull and reabse gave resulted in errors. Yes because rebase is bad for branch already committed. Rebase rewrite the history so you have to do a git pull -f It's better to merge master in rpi Yves -- 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
Re: [leaf-devel] LEAF for raspberry pi
Am 07.04.2013 08:40, schrieb Andrew: > 01.04.2013 18:59, KP Kirchdoerfer пишет: >> 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 changed package config generation in the master, and rebased rpi > branch on the top of current master. It seems like moddb is built > without hacks now; and it's possible to add firmware to initmod in > easier way, like modules (just mention it into fw list file). Tested for raspberry pi and I can build kmodules without errors. Someting might went wrong when rebasing, I had to hard reset my local repository to origin/rpi, cause pull and reabse gave resulted in errors. kp -- 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
Re: [leaf-devel] LEAF for raspberry pi
01.04.2013 18:59, KP Kirchdoerfer пишет: > 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 changed package config generation in the master, and rebased rpi branch on the top of current master. It seems like moddb is built without hacks now; and it's possible to add firmware to initmod in easier way, like modules (just mention it into fw list file). -- 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
Re: [leaf-devel] LEAF for raspberry pi
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
Re: [leaf-devel] LEAF for raspberry pi
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. >>>
Re: [leaf-devel] LEAF for raspberry pi
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. > > 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. > 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 impl
Re: [leaf-devel] LEAF for raspberry pi
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 ini
Re: [leaf-devel] LEAF for raspberry pi
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 ___ lea
Re: [leaf-devel] LEAF for raspberry pi
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. >> 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... >> 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. > 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 -- 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
Re: [leaf-devel] LEAF for raspberry pi
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? > 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. > 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. Or, if initrd concatenation is possible - some modules like usb flash may be external, in initmod. > I had the same pb with qemu while testing arm-versatile. I think we need > to enhance the toolchain to distinguish if a host is capable to load > multiple initrd files, or if we have to create a single one. > > I have committed the firmware and raspberry pi special config files to > repo/rpi-firmware, just to put them somewhere. > > Anyway, it's a start. > > kp > -- Own the Future-Intel(R) 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://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF for raspberry pi
Am 31.03.2013 20:00, schrieb Mike Noyes: > On 03/31/2013 10:26 AM, KP Kirchdoerfer wrote: >> 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. > -snip- > > KP, > Outstanding! Blog entry posted. > https://sourceforge.net/p/leaf/blog/2013/03/leaf-for-raspberry-pi/ thx for moving it to the blog. kp -- Own the Future-Intel(R) 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://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF for raspberry pi
On 03/31/2013 10:26 AM, KP Kirchdoerfer wrote: > 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. -snip- KP, Outstanding! Blog entry posted. https://sourceforge.net/p/leaf/blog/2013/03/leaf-for-raspberry-pi/ -- Mike Noyes http://sourceforge.net/users/mhnoyes https://plus.google.com/u/0/113364780158082152468 -- Own the Future-Intel(R) 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://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] LEAF for raspberry pi
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. 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. 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. 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 I had the same pb with qemu while testing arm-versatile. I think we need to enhance the toolchain to distinguish if a host is capable to load multiple initrd files, or if we have to create a single one. I have committed the firmware and raspberry pi special config files to repo/rpi-firmware, just to put them somewhere. Anyway, it's a start. kp -- Own the Future-Intel(R) 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://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
