Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1
Note at this point it is only Tegra we need a solution for to get F18 GA. We
will resolve more in F19 or even as an update but given it is just one platform
(TrimSlice), and that platform has a pretty reasonable U-Boot, let's get
something resolved today that works for Tegra and move on.
--
Sent from my phone. Please excuse brevity.
Peter Robinson pbrobin...@gmail.com wrote:
On Sun, Jan 27, 2013 at 7:22 PM, Brendan Conoboy b...@redhat.com wrote:
On 01/27/2013 08:51 AM, Peter Robinson wrote:
Basically when you do a make dtbs it makes the dtbs that match the
kernel config. So we end up with the following with the 3.7.x kernels
that we have in F-18 and they're in /boot/dtb-%{uname}. Note this
scheme can be tweaked but I figured getting something there to start
with was better than nothing.
Note: This will require changes to grubby's new-kernel-pkg similar to what
was necessary to run mkimage for uboot. The principle benefit of having a
separate package is that the dtbs land somewhere with a consistent name,
enabling grubby, boot.scr and uEnv.txt to remain static.
grubby needs to deal with all of those because the kernel doesn't
install anything into uboot, the naming scheme is the same and grubby
will need to be able to deal with dtb files so I didn't see that it
added any complexity because the same scheme is already being dealt
with for both the kernel and the initrd.
Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] arm F-18 Branched report: 20130129 changes
Compose started at Tue Jan 29 11:10:27 UTC 2013 Broken deps for arm -- [aeolus-conductor] aeolus-all-0.10.6-2.fc18.noarch requires mongodb-server aeolus-all-0.10.6-2.fc18.noarch requires iwhd aeolus-all-0.10.6-2.fc18.noarch requires imagefactory-jeosconf-ec2-rhel aeolus-all-0.10.6-2.fc18.noarch requires imagefactory-jeosconf-ec2-fedora aeolus-all-0.10.6-2.fc18.noarch requires imagefactory [asterisk] asterisk-fax-10.0.0-2.fc18.1.armv5tel requires libtiff.so.3 asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires perl(:MODULE_COMPAT_5.14.2) asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires librpmio.so.2 asterisk-snmp-10.0.0-2.fc18.1.armv5tel requires librpm.so.2 [bochs] bochs-2.6-1.fc18.armv5tel requires bochs-bios = 0:2.6-1.fc18 [bootconf] bootconf-1.4-6.fc18.noarch requires grub [cloud-init] cloud-init-0.7.1-2.fc18.noarch requires dmidecode [coccinella] coccinella-0.96.20-4.fc18.noarch requires iaxclient [condor-cloud] condor-cloud-0.1-5.fc18.noarch requires qemu-kvm = 0:0.14 condor-cloud-0.1-5.fc18.noarch requires condor-vm-gahp = 0:7.7.0 condor-cloud-node-0.1-5.fc18.noarch requires qemu-kvm = 0:0.14 condor-cloud-node-0.1-5.fc18.noarch requires condor-vm-gahp = 0:7.7.0 [condor-ec2-enhanced] condor-ec2-enhanced-1.3.1-1.fc18.noarch requires condor = 0:7.4.4-0.9 [condor-ec2-enhanced-hooks] condor-ec2-enhanced-hooks-1.3.1-1.fc18.noarch requires condor = 0:7.2.0-4 [condor-job-hooks] condor-job-hooks-1.5-6.fc18.noarch requires condor = 0:7.0.2-4 [condor-low-latency] condor-low-latency-1.2-2.fc18.2.noarch requires condor = 0:7.0.2-4 [condor-wallaby] condor-wallaby-client-5.0.3-1.fc18.noarch requires python-qmf = 0:0.9.1073306 condor-wallaby-client-5.0.3-1.fc18.noarch requires condor = 0:7.4.4-0.9 [cumin] cumin-0.1.5220-2.fc18.noarch requires python-qpid-qmf [ember-media] ember-media-0.6.2.1-3.fc18.noarch requires ember 0:0.6.3 ember-media-0.6.2.1-3.fc18.noarch requires ember = 0:0.6.2 [ghc-wai-extra] ghc-wai-extra-devel-1.2.0.4-4.fc18.armv5tel requires ghc-devel(ansi-terminal-0.5.5.1-b2f5e0314ae93aac1eb9d373e2a3db56) [gnome-boxes] gnome-boxes-3.6.2-1.fc18.armv5tel requires libvirt-daemon-kvm [gofer] ruby-gofer-0.74-1.fc18.noarch requires rubygem(qpid) = 0:0.16.0 [jaffl] jaffl-0.5.9-1.fc16.noarch requires jffi [jnr-ffi] jnr-ffi-0.5.10-3.fc17.noarch requires jffi [jnr-posix] jnr-posix-1.1.8-3.fc18.noarch requires jffi [jruby] jruby-1.6.3-3.fc17.noarch requires jffi = 0:1.0.10 [liveusb-creator] liveusb-creator-3.11.7-2.fc18.noarch requires syslinux-extlinux liveusb-creator-3.11.7-2.fc18.noarch requires syslinux [mcollective-qpid-plugin] mcollective-qpid-plugin-0.1.1-3.fc18.noarch requires ruby-qpid-qmf [merkaartor] merkaartor-0.18.0-0.3.git654e49ba.fc17.armv5tel requires libexiv2.so.11 [nfsometer] nfsometer-1.1-2.fc18.noarch requires filebench [openlierox] openlierox-0.57-0.16.beta8.fc15.armv5tel requires libzip.so.1 [openpts] openpts-0.2.6-4.fc18.armv5tel requires tboot [openshift-origin-broker] openshift-origin-broker-0.6.17-3.fc18.noarch requires mongodb-server [openstack-nova] openstack-nova-compute-2012.2-1.fc18.noarch requires qemu-kvm openstack-nova-compute-2012.2-1.fc18.noarch requires libguestfs-mount = 0:1.7.17 [ovirt-node] ovirt-node-2.5.1-1.fc18.noarch requires grub2 [oz] oz-0.9.0-1.fc18.noarch requires python-libguestfs [perl-MongoDB] perl-MongoDB-0.41-3.fc15.armv5tel requires perl(:MODULE_COMPAT_5.12.4) [pharosc] pharosc-xcircuit-8.3-6.fc18.noarch requires xcircuit [rakudo-star] rakudo-star-0.0.2011.07_3.6.0-5.fc18.1.armv5tel requires libparrot.so.3.6.0 [rootplot] rootplot-2.2.1-6.fc18.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-3.fc18.noarch requires ruby-qmf [rubygem-RedCloth] rubygem-RedCloth-4.2.3-3.fc17.armv5tel requires ruby(abi) = 0:1.8 rubygem-RedCloth-4.2.3-3.fc17.armv5tel requires libruby.so.1.8 [rubygem-boxgrinder-build] rubygem-boxgrinder-build-0.10.4-1.fc18.noarch requires ruby-libguestfs [rubygem-childprocess] rubygem-childprocess-0.2.0-4.fc18.noarch requires rubygem(ffi) 0:1.1 rubygem-childprocess-0.2.0-4.fc18.noarch requires rubygem(ffi) = 0:1.0.6 [rubygem-openshift-origin-msg-broker-mcollective] rubygem-openshift-origin-msg-broker-mcollective-0.1.1-9.fc18.noarch requires qpid-cpp-server rubygem-openshift-origin-msg-broker-mcollective-0.1.1-9.fc18.noarch requires qpid-cpp-client [rubygem-rb-inotify] rubygem-rb-inotify-0.8.8-1.fc18.noarch requires rubygem(ffi) [rubygem-selenium-webdriver] rubygem-selenium-webdriver-2.3.2-4.fc18.noarch requires
[fedora-arm] Daily Koji Compare Stats
Tue Jan 29 09:05:01 EST 2013 f17-updates : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 3201 |1 | 154 |1 | 336 | 206 | http://142.204.133.82/jon/koji/kc.f17-updates.diff.html f18 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 12286 |9 | 40 |2 | 279 | 40 | http://142.204.133.82/jon/koji/kc.f18.diff.html f18-updates-testing : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 2830 |3 | 54 | 10 | 135 | 56 | http://142.204.133.82/jon/koji/kc.f18-updates-testing.diff.html f18-updates : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 1370 |1 |5 |0 | 75 | 5 | http://142.204.133.82/jon/koji/kc.f18-updates.diff.html f19 : arm vs PA Same |Newer |Older |Local | Remote | Missing | -- 3899 |3 | 707 |1 | 927 | 1183 | 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 Jan 29 09:25:21 EST 2013 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned
On Tue, 2013-01-29 at 14:12 +0800, Chen Baozi wrote: On Tue, Jan 29, 2013 at 12:52:24AM -0500, Mark Salter wrote: On Tue, 2013-01-29 at 09:05 +0800, Chen Baozi wrote: Thanks, Mark. I've switched to another machine which has better network connection. And It finally works, :) I guess something I've checkout before was corrupt due to both my poor network connection and big size of the rootfs. BTW, seems it is not up-to-date? I mean there is no /stage3 under the rootfs. Hmm. I looked closer at the tree I checked out and it too had a head at commit 3e7ab1bee31082a0 from Al on Dec 31. I'm at a loss to explain what It is the same with my local git tree. is going wrong. I have a local tree that appears to be up to date with the repo on fedoraproject.org but the log shows 18 commits which aren't in the tree I cloned from fedoraproject.org repo earlier today. I'll try and see if I can sort it all out tomorrow. Thanks a lot. Baozi Al, this may be something for you to look at. If I clone the repo using http, I get 3e7ab1bee31082a as the lastest commit. If I use ssh+git, I get everything correctly. --Mark ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned
On 01/29/2013 11:09 AM, Mark Salter wrote: On Tue, 2013-01-29 at 14:12 +0800, Chen Baozi wrote: On Tue, Jan 29, 2013 at 12:52:24AM -0500, Mark Salter wrote: On Tue, 2013-01-29 at 09:05 +0800, Chen Baozi wrote: Thanks, Mark. I've switched to another machine which has better network connection. And It finally works, :) I guess something I've checkout before was corrupt due to both my poor network connection and big size of the rootfs. BTW, seems it is not up-to-date? I mean there is no /stage3 under the rootfs. Hmm. I looked closer at the tree I checked out and it too had a head at commit 3e7ab1bee31082a0 from Al on Dec 31. I'm at a loss to explain what It is the same with my local git tree. is going wrong. I have a local tree that appears to be up to date with the repo on fedoraproject.org but the log shows 18 commits which aren't in the tree I cloned from fedoraproject.org repo earlier today. I'll try and see if I can sort it all out tomorrow. Thanks a lot. Baozi Al, this may be something for you to look at. If I clone the repo using http, I get 3e7ab1bee31082a as the lastest commit. If I use ssh+git, I get everything correctly. --Mark The only thing I can think of right now is that 'git update-server-info' may not be getting run on updates to the repo for some reason. I've run it by hand to see if this changes the behavior -- let me know if you now get the most recent commit. If not, I'll have to poke the infrastructure folks. The short term workaround is to use ssh+git, as you indicated. Infrastructure and I have been struggling with the underlying problem that http and git and SELinux are in a bit of a disagreement on how access should work -- and it's http that's been losing out so far. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned
On Tue, 2013-01-29 at 11:23 -0700, Al Stone wrote: On 01/29/2013 11:09 AM, Mark Salter wrote: On Tue, 2013-01-29 at 14:12 +0800, Chen Baozi wrote: On Tue, Jan 29, 2013 at 12:52:24AM -0500, Mark Salter wrote: On Tue, 2013-01-29 at 09:05 +0800, Chen Baozi wrote: Thanks, Mark. I've switched to another machine which has better network connection. And It finally works, :) I guess something I've checkout before was corrupt due to both my poor network connection and big size of the rootfs. BTW, seems it is not up-to-date? I mean there is no /stage3 under the rootfs. Hmm. I looked closer at the tree I checked out and it too had a head at commit 3e7ab1bee31082a0 from Al on Dec 31. I'm at a loss to explain what It is the same with my local git tree. is going wrong. I have a local tree that appears to be up to date with the repo on fedoraproject.org but the log shows 18 commits which aren't in the tree I cloned from fedoraproject.org repo earlier today. I'll try and see if I can sort it all out tomorrow. Thanks a lot. Baozi Al, this may be something for you to look at. If I clone the repo using http, I get 3e7ab1bee31082a as the lastest commit. If I use ssh+git, I get everything correctly. --Mark The only thing I can think of right now is that 'git update-server-info' may not be getting run on updates to the repo for some reason. I've run it by hand to see if this changes the behavior -- let me know if you now get the most recent commit. If not, I'll have to poke the infrastructure folks. The short term workaround is to use ssh+git, as you indicated. Infrastructure and I have been struggling with the underlying problem that http and git and SELinux are in a bit of a disagreement on how access should work -- and it's http that's been losing out so far. Yay. A clone using http did get the latest bits. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 28 Jan 2013 22:26:19 -0600 Dennis Gilmore den...@ausil.us escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore den...@ausil.us escribió: Hi all, I wanted to kick off a discussion, I think that with the work that Seneca is doing for armv6hl to support the Raspberry Pi most of the need for building sfp has gone away. I would like us to drop support for sfp in F19 that means that anyone running a kirkwood based system would get supported software updates for approximately 13 months from now. with cubie boards and other devices coming around that are cheap and more powerful and similar options I think there is little benefit to continuing to support sfp. Ive put in a request to get numbers of people using the arm and armhfp portions of mirrormanager to get some idea of the number of users out there, though i suspect most arm are raspberry pi and people building in mock. since there has been no major objection i will disable building armv5tel rpms in rawhide before the mass rebuild. the next rawhide compose will be hfp only Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEISZEACgkQkSxm47BaWfcMhgCfTXYh6hnV1EVfn6N4WxSbVEo4 qY4AoIWbTfosWMpS8PPGELhZsWcIeCcU =FvMg -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned
On 01/29/2013 03:10 PM, Mark Salter wrote: On Tue, 2013-01-29 at 11:23 -0700, Al Stone wrote: On 01/29/2013 11:09 AM, Mark Salter wrote: On Tue, 2013-01-29 at 14:12 +0800, Chen Baozi wrote: On Tue, Jan 29, 2013 at 12:52:24AM -0500, Mark Salter wrote: On Tue, 2013-01-29 at 09:05 +0800, Chen Baozi wrote: Thanks, Mark. I've switched to another machine which has better network connection. And It finally works, :) I guess something I've checkout before was corrupt due to both my poor network connection and big size of the rootfs. BTW, seems it is not up-to-date? I mean there is no /stage3 under the rootfs. Hmm. I looked closer at the tree I checked out and it too had a head at commit 3e7ab1bee31082a0 from Al on Dec 31. I'm at a loss to explain what It is the same with my local git tree. is going wrong. I have a local tree that appears to be up to date with the repo on fedoraproject.org but the log shows 18 commits which aren't in the tree I cloned from fedoraproject.org repo earlier today. I'll try and see if I can sort it all out tomorrow. Thanks a lot. Baozi Al, this may be something for you to look at. If I clone the repo using http, I get 3e7ab1bee31082a as the lastest commit. If I use ssh+git, I get everything correctly. --Mark The only thing I can think of right now is that 'git update-server-info' may not be getting run on updates to the repo for some reason. I've run it by hand to see if this changes the behavior -- let me know if you now get the most recent commit. If not, I'll have to poke the infrastructure folks. The short term workaround is to use ssh+git, as you indicated. Infrastructure and I have been struggling with the underlying problem that http and git and SELinux are in a bit of a disagreement on how access should work -- and it's http that's been losing out so far. Yay. A clone using http did get the latest bits. Well, we now know the workaround; do the commit, then ssh into fp.o and run git update-server-info in the repo. Ugly, but it works. I'm not sure this is fixable, but I'll poke the infrastructure folks and see what we can do. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned
On 01/29/2013 05:24 PM, Al Stone wrote: Well, we now know the workaround; do the commit, then ssh into fp.o and run git update-server-info in the repo. Ugly, but it works. I'm not sure this is fixable, but I'll poke the infrastructure folks and see what we can do. Thanks Al. Jon. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] slow loading of initrd/kernel from ext file system on kirkwood/dockstar
I think the slowness you are experiencing is because you aren't writing the kernel and initramfs images to nand. If you do that, it will speed up the boot considerably. :) in otherwords, the commands I looked at for the guruplug, copied the kernel and initramfs from the device, then boot from there. If that is working there are some directions somewhere, that tell you how to do the nand.erase nand.write. then you change the boot command to just boot those addresses. which will skip about 5+ minutes of the boot time. :) However, I was having issues writing to the nand on mine, it was generating a ton of errors with the nand.write command. :) slow boot is better then no boot, i suppose. :) - Original Message - From: Sean Omalley omalle...@rocketmail.com To: Till Maas opensou...@till.name; arm@lists.fedoraproject.org arm@lists.fedoraproject.org Cc: Sent: Thursday, January 24, 2013 11:39 PM Subject: Re: [fedora-arm] slow loading of initrd/kernel from ext file system on kirkwood/dockstar im guessing here, but IIRC ext2 is supported by the firmware and not ext4.. so if you really are loading your kernel, initramfs, and such from ext4, it might cause some slowness. I also noticed on the pogoplug e02, when I tried F17, it was slow, but I think that had to do with USB 1.0 and booting off a usb thumb drive. (apparently uboot was only recognizing the usb port as usb1.0). - Original Message - From: Till Maas opensou...@till.name To: arm@lists.fedoraproject.org Cc: Sent: Thursday, January 24, 2013 5:04 PM Subject: [fedora-arm] slow loading of initrd/kernel from ext file system on kirkwood/dockstar Hi, I noticed that loading the kernel/initrd from an ext4 file system as it is the default on F18 Beta is very slow compared to vfat. It takes several minutes instead of seconds. Is this only the case on my dockstar? I already updated the uboot to the latest release I found on http://people.debian.org/~tbm/u-boot/ but it did not help. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
