Re: [fedora-arm] Fedora ARM VFAD - Help test Fedora 18 ARM TC1, kernels and device tree! - 2012-10-15
> Made good progress today. :) > Was able to get Device Tree to work on both Panda ES and Trimslice. Awesome! > What works: appended DTB kernels. (cat the .dtb to the end of the > zimage, then generate a new uImage) > > What does NOT work: loading the .dtb from u-boot (similar to the initrd) It's a good start. > One notable breakthrough was being able to boot the trimslice with the > latest version of u-boot. > (had to change boot.cmd to have root=/dev/mmcblk0p3) OK, interesting to see why labels don't work. > For the panda it would seem not all the parts of omap kernel are moved > over to DT, some things do not work. Not surprised as I believe 3.7 should be the end of the OMAP DT support additions but it's good to know it actually works which is my primary concern so that we know it has all the bits needed in F-18. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] How about SAN or other Network Block Storage on ARM devices
Hi. I've been tinkering with the Linux NDAS driver. The competition for this storage system in the x86 world are Coraid's AOE and Linux' NBD. They are essentially the same idea, connecting computers to the block device on the LAN. NDAS seems to work fine, on my Fedora desktops, and on the ARM units I have tested: pogoplug, sheevaplug and seagate goflex. They are running a BusyBox version though. I have not yet installed fedora on the plug to test it though. I am wondering if there is any future using it with ARM networks. I don't see much talk about using this type of storage applications on this and some other ARM lists that I joined. I am working on the web scripts working that allow connecting the storage as a typical drive from my sheevaplug, but it looks like there is no big market now. So I am asking what users here think of this. At first, AMAHI.org released a Fedora based plug version with Greyhole storage pooling by default. I was thinking it might be a good idea as a low cost, high capacity system if the plugs were to pool several of the NetDISKs together. Shall I continue my experiments? Do you think the growing power of ARM boards will lead to simply building in HD and such? Can you see this kind of scale out connectivity in the future of ARM computers, using several block devices on LAN as a storage for lots of ARMs doing background storage and service? Has anyone done multiple ARM computers connecting to a block device for central storage using a Global File System or Greyhole? Thanks for your consideration ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Daily Koji Compare Stats
Tue Oct 16 09:05:01 EDT 2012 f17-updates : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2651 |2 |9 |1 | 179 | 12 | http://142.204.133.82/jon/koji/kc.f17-updates.diff.html f18 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 11788 |6 | 273 |2 | 318 | 365 | http://142.204.133.82/jon/koji/kc.f18.diff.html f18-updates-testing : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 1699 |3 | 172 |0 | 218 | 186 | http://142.204.133.82/jon/koji/kc.f18-updates-testing.diff.html f19 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 11257 | 17 | 874 |2 | 343 | 1519 | http://142.204.133.82/jon/koji/kc.f19.diff.html ARM Build Status Wiki: https://fedoraproject.org/wiki/Architectures/ARM https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide Tue Oct 16 09:29:15 EDT 2012 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Recommendations for a mini monitor
Peter Robinson píše v Pá 12. 10. 2012 v 12:57 +0100: > On Fri, Oct 12, 2012 at 12:54 PM, Niels de Vos > wrote: > > Hi all, > > > > I'm looking to hook up a little monitor on one of my Efika Smarttops > > (mx51 SOC) to test the video output and such. It will not display > > anything due to missing drivers, but hopefully it will be able to show > > a console due course. I've seen some Lilliput monitors that would suit > > 3.6 should shortly give you framebuffer which means you should even > have X and when 3.7 hits there's even a KMS driver which means you > could use the basic X modesetting driver! The problem what still exists is that the drivers for the add-on chips interconnecting the GPU and monitor (siihdmi/mtl1017) are still missing. This should be true for the i.MX5 case, for i.MX6 it's part of the SoC. Hopefully I remember this correctly. Dan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - Help test Fedora 18 ARM TC1, kernels and device tree! - 2012-10-15
On Tue, Oct 16, 2012 at 6:25 AM, Peter Robinson wrote: >> Made good progress today. :) >> Was able to get Device Tree to work on both Panda ES and Trimslice. > > Awesome! > >> What works: appended DTB kernels. (cat the .dtb to the end of the >> zimage, then generate a new uImage) >> >> What does NOT work: loading the .dtb from u-boot (similar to the initrd) > > It's a good start. > >> One notable breakthrough was being able to boot the trimslice with the >> latest version of u-boot. >> (had to change boot.cmd to have root=/dev/mmcblk0p3) > > OK, interesting to see why labels don't work. > >> For the panda it would seem not all the parts of omap kernel are moved >> over to DT, some things do not work. > > Not surprised as I believe 3.7 should be the end of the OMAP DT > support additions but it's good to know it actually works which is my > primary concern so that we know it has all the bits needed in F-18. > > Peter A few things to discuss: * update u-boot in f18 to 2012-10 (important for panda) -> Apparently we only bundle u-boot with omap anyways. -> The updated version only appears for f19, this would be a "nice to have" type thing for f18. -> Only the updated version loads the .dtb succesfully from u-boot, otherwise we can append the .dtb in 2012-07. * Do we even want to load the .dtb for panda? -> my experience was not happy, the omap4-panda.dtb makes things break. -> Breaks: WiFi, Display Subsystem and maybe USB-Host functionality. -> I do believe the omap folks are busy working on improving DT, so maybe we can wait? * Trimslice -> was able to get mmc/sdcard booting with the latest DT-enabled u-boot. -> unfortunately when Brendan ran into a snag when reproducing with his internal /dev/sda boot. -> on the trimslice the .dtb seems to have to be appended, so far loading via u-boot is not happy. -> also there is a rumor that trimslice might support a uEnv.txt type thing, would be nice to have. * adding the .dtb's to the distro. -> I hear the .dtb files are somehow generated from the kernel sources? -> sometimes we may have to append them to the kernel zimage (trimslice). -> Other times they get loaded via u-boot (Panda). -> Would be interesting to findout how our image generation process deals with this. -> necessary first step is deciding how we get access to the .dtbs from the distro. -- -Jon ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - Help test Fedora 18 ARM TC1, kernels and device tree! - 2012-10-15
On 10/16/2012 04:25 AM, Peter Robinson wrote: One notable breakthrough was being able to boot the trimslice with the latest version of u-boot. (had to change boot.cmd to have root=/dev/mmcblk0p3) OK, interesting to see why labels don't work. I think it's a red herring. Booting with root=/dev/sda2 does *not* work. What we can say for sure is that mmc is working, but usb sata is not. Perhaps somebody booting off mmc could try using a label to confirm? My trimslice h's bootlog is here, using the new uboot: http://fpaste.org/iz1r/ Note this boot succeeds when the old uboot is installed- and device tree is active. Appended dtb in both cases. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How about SAN or other Network Block Storage on ARM devices
On Tue, Oct 16, 2012 at 2:19 PM, David Gates wrote: > Hi. > > I've been tinkering with the Linux NDAS driver. > The competition for this storage system in the x86 world are Coraid's AOE > and Linux' NBD. > They are essentially the same idea, connecting computers to the block device > on the LAN. > > NDAS seems to work fine, on my Fedora desktops, and on the ARM units I have > tested: pogoplug, sheevaplug and seagate goflex. > They are running a BusyBox version though. I have not yet installed fedora > on the plug to test it though. > > I am wondering if there is any future using it with ARM networks. > I don't see much talk about using this type of storage applications on this > and some other ARM lists that I joined. > > I am working on the web scripts working that allow connecting the storage as > a typical drive from my sheevaplug, but it looks like there is no big market > now. So I am asking what users here think of this. > > At first, AMAHI.org released a Fedora based plug version with Greyhole > storage pooling by default. I was thinking it might be a good idea as a low > cost, high capacity system if the plugs were to pool several of the NetDISKs > together. > > Shall I continue my experiments? > > Do you think the growing power of ARM boards will lead to simply building in > HD and such? > > Can you see this kind of scale out connectivity in the future of ARM > computers, using several block devices on LAN as a storage for lots of ARMs > doing background storage and service? > > Has anyone done multiple ARM computers connecting to a block device for > central storage using a Global File System or Greyhole? If it's possible on x86, whether it be client or server, it's possible on ARM. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] selinux issue on new images
I've been building test images for ARM systems and have hit an issue. I created an image for Trim Slice today, and it failed to let me log in. The error was: -- root: no shell: Permission denied I checked and the image had: SELINUX=enforcing SELINUXTYPE=targeted This surprised me because in the kickstart I explicitly select: selinux --permissive and in the anaconda program log I see: INFO program: Running... /usr/sbin/lokkit --selinux=permissive but on the final image selinux is set to enforcing. I don't know what is changing the setting. Oddly enough, images I created last week did not exhibit this behavior. The final image had: SELINUX=permissive SELINUXTYPE=targeted just as the kickstart file specified. I assume that some package has changed in the F18 development repos since last week to cause this, but I have no idea which package. Does anyone have suggestions for tracking down this issue? Note: If I force a 'relabel' on the root file system and reboot, the login works even with SELinux set to enforcing, but that does not explain why the settings in the kickstart are not being honored. d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] selinux issue on new images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 17 Oct 2012 00:14:24 -0500 "David A. Marlin" escribió: > > I've been building test images for ARM systems and have hit an issue. > > I created an image for Trim Slice today, and it failed to let me log > in. The error was: > > -- root: no shell: Permission denied > > I checked and the image had: > > SELINUX=enforcing > SELINUXTYPE=targeted > > This surprised me because in the kickstart I explicitly select: > > selinux --permissive > > and in the anaconda program log I see: > > INFO program: Running... /usr/sbin/lokkit --selinux=permissive > > but on the final image selinux is set to enforcing. I don't know > what is changing the setting. > > Oddly enough, images I created last week did not exhibit this > behavior. The final image had: > > SELINUX=permissive > SELINUXTYPE=targeted > > just as the kickstart file specified. > > I assume that some package has changed in the F18 development repos > since last week to cause this, but I have no idea which package. > > Does anyone have suggestions for tracking down this issue? > > Note: If I force a 'relabel' on the root file system and reboot, the > login works even with SELinux set to enforcing, but that does not > explain why the settings in the kickstart are not being honored. Fedora images are to have selinux enforcing. thats what really should be tested. likely its anaconda thats setting it to enforcing. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlB+Ud8ACgkQkSxm47BaWfe4QwCfe52ZdNyJr4OaKCoO7HOxav+t RYYAoIeP1fOtROkPyUg3EBa+5mAABvkD =jny+ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
