Re: [fedora-arm] Fwd: Help!Failed to find a suitable stage1 device when using PXE installation.
On 12/29/2014 08:10 PM, Brooks Hu wrote: David, I suppose the kickstart file was loaded successfully, because after changing content in kickstart file(for example, text mode), the installation process will reflect the change. You mentioned checking server logs, how can i do this? I have only access to a serial console. Thanks a lot. When I refer to the 'server logs' I am referring to the logs on the DHCP/TFTP/HTTP server(s) where the PXE configuration, install tree, and kickstart configuration files are stored. You can also inspect the anaconda logs on the target (Mustang) system from the serial console. Anaconda uses tmux for the serial terminal session, [anaconda] 1:main* 2:shell 3:log 4:storage-log 5:program-log so you can toggle between the main screen (Ctrl-B 1) and a shell (Ctrl-B 2), or to the log files themselves (Ctrl-B and 3, 4, or 5), much as you would switch screens (tabs) using 'screen' on a normal terminal window. Ctrl-B [ will put the active screen in 'copy mode' so you can scroll up and down using the arrow keys to see more of the logs. The Esc will exit copy mode. d.marlin === Brooks On Mon, Dec 29, 2014 at 11:56 PM, David A. Marlin dmar...@redhat.com mailto:dmar...@redhat.com wrote: On 12/29/2014 12:05 AM, Brooks Hu wrote: David, Thanks for the help. Regarding my configuration file, i just copied it from other thus some lines wrong, but i think they have nothing to do with this issue. This issue should only be related to disk partitioning. Are you certain that anaconda is finding the kickstart file (checked the server logs)? There were two issues pointed out before: 4) [!] Software selection (Nothing selected) 5) [!] Installation Destination (No disks selected) Since it did not know which Software was selected (%packages in the kickstart) or the Installation Destination (specified as sda in the kickstart), it may not be finding the kickstart at all, or may not be able to successfully parse it. Is it also possible that the initrd does not include all the requisite drivers to find the network or disk. Please inspect the anaconda logs to see what errors are occurring. From the shell window you can also verify that the network is functional (use curl to get the kickstart file), and check that the expected partitions are available. I tried your kickstart configuration, but the issue still exists. I noticed in the configuration there is a line bootloader --location=mbr, does it mean you are using legacy BIOS rather than EFI? I am using EFI BIOS. I am using EFI as well. Please be sure you are using the most recent firmware version. I downloaded the image from here http://arm.koji.fedoraproject.org/compose/21_RC7/Server/aarch64/iso/Fedora-Server-DVD-aarch64-21.iso then setup a local FTP to host it. RC7 should be a good release to install, so I suspect is it an issue in the setup as mentioned above. d.marlin Best Regards, Brooks On Mon, Dec 29, 2014 at 9:19 AM, David A. Marlin dmar...@redhat.com mailto:dmar...@redhat.com wrote: On 12/27/2014 06:19 PM, Brooks Hu wrote: -- Forwarded message -- From: *Brooks Hu* brooks...@gmail.com mailto:brooks...@gmail.com Date: Friday, December 26, 2014 Subject: Help!Failed to find a suitable stage1 device when using PXE installation. To: arm@lists.fedoraproject.org mailto:arm@lists.fedoraproject.org Hi all, I am trying automatic PXE installation (Fedora 21 for AARCH64) on my Mustang board, but looks like kickstart can't work. Here comes the detail: Starting installer, one moment... find_file: stat /proc/device-tree/chosen/bootpath, No such file or directory anaconda 21.48.21-1 for Fedora-Server 21 started. * installation log files are stored in /tmp during the installation * shell is available on TTY2 * when reporting a bug add logs from /tmp as separate text/plain attachments 10:26:29 Not asking for VNC because of an automated install Starting automated install.. Generating updated storage configuration storage configuration failed: failed to find a suitable stage1 device Installation 1) [x] Language settings 2) [!] Timezone settings (English (United States)) (Timezone is not set.) 3) [x] Installation source 4) [!] Software selection (ftp://192.168.1.1/F21/) (Nothing selected) 5) [!] Installation Destination 6) [x] Network configuration
Re: [fedora-arm] Fwd: Help!Failed to find a suitable stage1 device when using PXE installation.
On 12/29/2014 12:05 AM, Brooks Hu wrote: David, Thanks for the help. Regarding my configuration file, i just copied it from other thus some lines wrong, but i think they have nothing to do with this issue. This issue should only be related to disk partitioning. Are you certain that anaconda is finding the kickstart file (checked the server logs)? There were two issues pointed out before: 4) [!] Software selection (Nothing selected) 5) [!] Installation Destination (No disks selected) Since it did not know which Software was selected (%packages in the kickstart) or the Installation Destination (specified as sda in the kickstart), it may not be finding the kickstart at all, or may not be able to successfully parse it. Is it also possible that the initrd does not include all the requisite drivers to find the network or disk. Please inspect the anaconda logs to see what errors are occurring. From the shell window you can also verify that the network is functional (use curl to get the kickstart file), and check that the expected partitions are available. I tried your kickstart configuration, but the issue still exists. I noticed in the configuration there is a line bootloader --location=mbr, does it mean you are using legacy BIOS rather than EFI? I am using EFI BIOS. I am using EFI as well. Please be sure you are using the most recent firmware version. I downloaded the image from here http://arm.koji.fedoraproject.org/compose/21_RC7/Server/aarch64/iso/Fedora-Server-DVD-aarch64-21.iso then setup a local FTP to host it. RC7 should be a good release to install, so I suspect is it an issue in the setup as mentioned above. d.marlin Best Regards, Brooks On Mon, Dec 29, 2014 at 9:19 AM, David A. Marlin dmar...@redhat.com mailto:dmar...@redhat.com wrote: On 12/27/2014 06:19 PM, Brooks Hu wrote: -- Forwarded message -- From: *Brooks Hu* brooks...@gmail.com mailto:brooks...@gmail.com Date: Friday, December 26, 2014 Subject: Help!Failed to find a suitable stage1 device when using PXE installation. To: arm@lists.fedoraproject.org mailto:arm@lists.fedoraproject.org Hi all, I am trying automatic PXE installation (Fedora 21 for AARCH64) on my Mustang board, but looks like kickstart can't work. Here comes the detail: Starting installer, one moment... find_file: stat /proc/device-tree/chosen/bootpath, No such file or directory anaconda 21.48.21-1 for Fedora-Server 21 started. * installation log files are stored in /tmp during the installation * shell is available on TTY2 * when reporting a bug add logs from /tmp as separate text/plain attachments 10:26:29 Not asking for VNC because of an automated install Starting automated install.. Generating updated storage configuration storage configuration failed: failed to find a suitable stage1 device Installation 1) [x] Language settings 2) [!] Timezone settings (English (United States)) (Timezone is not set.) 3) [x] Installation source 4) [!] Software selection (ftp://192.168.1.1/F21/) (Nothing selected) 5) [!] Installation Destination 6) [x] Network configuration (No disks selected) (Wired (eth0) connected) 7) [!] Root password 8) [!] User creation (Password is not set.) (No user will be created) Not enough space in filesystems for the current software selection. An additional 2861.02 MiB is needed. Please make your choice from above ['q' to quit | 'b' to begin installation | UEFI version is 1.1.0-rh-0.13 Here comes the kick start config file(I modified based on a sample from certain website): Note that the installation options indicate: 4) [!] Software selection (Nothing selected) and 5) [!] Installation Destination (No disks selected), which implies anaconda is not seeing (or accepting) some of the options in your kickstart. Please look in the logs in /tmp to find any errors. There are some things in you kickstart that I am not familiar with, such as: vznetcfg --net=virt_network1:eth0 vztturlmap $FS_SERVER http://myrepository.com nosfxtemplate %eztmplates --cache and the following just look wrong for an aarch64 install: centos-6-x86_64 centos-6-x86 mailman-centos-6-x86_64 mailman-centos-6-x86 I would try a more standard Fedora kickstart install first to make sure the repos, etc. are working, and then try adding the 'custom' config options to see what breaks. Attached is an example kickstart I have successfully used for provisioning a Mustang board. d.marlin - text
Re: [fedora-arm] Fwd: Help!Failed to find a suitable stage1 device when using PXE installation.
On 12/27/2014 06:19 PM, Brooks Hu wrote: -- Forwarded message -- From: *Brooks Hu* brooks...@gmail.com mailto:brooks...@gmail.com Date: Friday, December 26, 2014 Subject: Help!Failed to find a suitable stage1 device when using PXE installation. To: arm@lists.fedoraproject.org mailto:arm@lists.fedoraproject.org Hi all, I am trying automatic PXE installation (Fedora 21 for AARCH64) on my Mustang board, but looks like kickstart can't work. Here comes the detail: Starting installer, one moment... find_file: stat /proc/device-tree/chosen/bootpath, No such file or directory anaconda 21.48.21-1 for Fedora-Server 21 started. * installation log files are stored in /tmp during the installation * shell is available on TTY2 * when reporting a bug add logs from /tmp as separate text/plain attachments 10:26:29 Not asking for VNC because of an automated install Starting automated install.. Generating updated storage configuration storage configuration failed: failed to find a suitable stage1 device Installation 1) [x] Language settings 2) [!] Timezone settings (English (United States)) (Timezone is not set.) 3) [x] Installation source 4) [!] Software selection (ftp://192.168.1.1/F21/) (Nothing selected) 5) [!] Installation Destination 6) [x] Network configuration (No disks selected) (Wired (eth0) connected) 7) [!] Root password 8) [!] User creation (Password is not set.) (No user will be created) Not enough space in filesystems for the current software selection. An additional 2861.02 MiB is needed. Please make your choice from above ['q' to quit | 'b' to begin installation | UEFI version is 1.1.0-rh-0.13 Here comes the kick start config file(I modified based on a sample from certain website): Note that the installation options indicate: 4) [!] Software selection (Nothing selected) and 5) [!] Installation Destination (No disks selected), which implies anaconda is not seeing (or accepting) some of the options in your kickstart. Please look in the logs in /tmp to find any errors. There are some things in you kickstart that I am not familiar with, such as: vznetcfg --net=virt_network1:eth0 vztturlmap $FS_SERVER http://myrepository.com nosfxtemplate %eztmplates --cache and the following just look wrong for an aarch64 install: centos-6-x86_64 centos-6-x86 mailman-centos-6-x86_64 mailman-centos-6-x86 I would try a more standard Fedora kickstart install first to make sure the repos, etc. are working, and then try adding the 'custom' config options to see what breaks. Attached is an example kickstart I have successfully used for provisioning a Mustang board. d.marlin - text install lang en_US.UTF-8 keyboard us part efi --fstype=efi --size=300 --ondisk=sda part /boot --fstype=ext4 --size=512 --ondisk=sda part / --fstype=ext4 --size=20096 --ondisk=sda part /vz --fstype=ext4 --size=40768 --ondisk=sda part swap --size=4000 bootloader --location=partition --ondisk=sda network --bootproto dhcp rootpw root auth --enableshadow --passalgo=sha512 timezone --utc America/New_York reboot vznetcfg --net=virt_network1:eth0 vztturlmap $FS_SERVER http://myrepository.com nosfxtemplate %eztmplates --cache centos-6-x86_64 centos-6-x86 mailman-centos-6-x86_64 mailman-centos-6-x86 %packages @base @core @vz @ps %end I have tried all kinds of option combination, also deleted all the partitions, but it still can't work. Any suggestions/comments are welcomed! Best Regards, Brooks ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm F21-aarch64-RC7.ks Description: application/java-keystore ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Cubieboard 2 compatible kernel package
On 08/14/2014 06:26 AM, Andy Green wrote: Hi - I have a headless cubieboard 2 running a 3.4 kernel that came with the board, but a Fedora rootfs already. It's been pretty workable, but now I need to compile an OOT kernel module, and that's a big mess with the magic 3.4 kernel. The defconfig it was built with has gone 404, although a tarball of the sources (with different defconfigs) exists. So after reading the megathreads here about cubieboard 2 support working, I went to look for a rawhide kernel package and give it a try. However after looking at Wikis that are out of date compared to the mailing list, and an Arm Koji that only has 64-bit arm binaries in the kernel package, I have no idea where to go to get the latest armhf kernel package, U-Boot pieces etc. ARMv7 is a primary architecture now, so all the packages are built in the main koji (not arm.koji), i.e., the F22 kernel-3.16 build for ARMv7 is: http://koji.fedoraproject.org/koji/buildinfo?buildID=550198 3.17-rc0 builds are also available, but I'm not sure if they have been tested. d.marlin I think this respin concept is not a good idea, I see rotting one-off respins including one from Feb for Cubieboard. But all I want is to upgrade the 3.4 kernel to use a Fedora one with latest upstream pieces. My fedora rootfs is already in good shape. What steps should someone in this situation take to align themselves with latest armv7 hf kernel and boot-related pieces that will work on Cubieboard 2? Thanks for any advice. -Andy ___ 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
Re: [fedora-arm] arm-temp.ausil.us is shutting down
On 11/27/2013 02:04 AM, Jon Masters wrote: On 11/22/2013 05:24 PM, Brendan Conoboy wrote: On 11/22/2013 02:22 PM, Brendan Conoboy wrote: Hi everybody, Dennis's email server is currently migrating so I'm sending this for him. The system we did aarch64 bootstrap on, arm-temp.ausil.us, is shutting down. If you're currently using this system to retrieve packages you'll want to update your yum configuration to use http://arm-temp.ausil.us/pub/fedora-arm/stage4/ instead. Make that: http://arm.koji.fedoraproject.org/aarch64/stage4/ Handy updated stage4.repo reference file attached. Jon. Do we have anything post-stage4 built for fedora (maybe through koji)? Those packages are getting a bit old now. d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 19 TC6
On 06/26/2013 08:21 AM, Hans de Goede wrote: Hi, On 06/26/2013 03:16 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Jun 2013 08:05:21 -0500 Dennis Gilmore den...@ausil.us wrote: Why are we making 8GB images, is 4GB too small? or ... ? I would really like to see this fixed for F-20, where and against which component do I file a bug for this? it was a design decision I made. I guess that to change it discussion would need to happen on this list or the spins list since that's where discussions on spin-kickstarts happens which is where all the kickstart snippets live. i choose 8gb because its common and because we dont have anything working to resize the rootfs. smaller images make the processes faster, bigger makes for a more usable out of box experience Ah, what happened to the rootfs-resize script ctyler wrote, is that no longer working? There is an open BZ on it: https://bugzilla.redhat.com/show_bug.cgi?id=974631 d.marlin I agree that before moving back to 4gb images we should first have a working rootfs-resize. Regards, Hans ___ 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] GCC Built-In Atomic Operations
The Wiki page linked below gives an overview of how to use the GCC Built-In Atomic Operations to add support for ARM-based systems. http://fedoraproject.org/wiki/Architectures/ARM/GCCBuiltInAtomicOperations Please let me know if you have questions, or suggestions for improvement. Thank you, d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19 Alpha RC5 compose
On 05/10/2013 10:51 AM, Brendan Conoboy wrote: On 05/09/2013 09:08 PM, David A. Marlin wrote: Is there any special U-Boot version requirement for Trim Slice, and if so, what version(s)? It requires one of the 2012 uboots which include dtb support. Works fine with the 1GB firmware as long as those extra environment variables are set. Thank you. Coincidentally, Compulab tells me there will be a -3 release which resolves the need to set those variables, sometime in June. Any chance of getting a 'preview release' for testing? Also, will this image work for OMAP, and if so, are there any special instructions for Panda? The image I saw doesn't have a vfat partition 1, so without a great deal of manual intervention it would not work on OMAP. So what are the 'blocker' images on F19? For F18 it was vexpress, highbank, and panda. Is it now just vexpress and highbank? d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19 Alpha RC5 compose
On 05/09/2013 04:28 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, there is a Release Candidate compose for Alpha at http://armpkgs.fedoraproject.org/mash/stage/19-Alpha-RC5/ there is a install tree as well as a image, the image is a minimal install. it has all 3 kernels installed, kernel, kernel-lpae, and kernel-tegra. to install to a sdcard run xzcat image sdcard it does not have boot.scr setup as an example to boot on a trimslice you would put something like setenv bootargs cma=64M root=LABEL=_/ ro rhgb console=ttyS0,115200 ext2load mmc 0:1 588 vmlinuz-3.9.0-301.fc19.armv7hl.tegra ext2load mmc 0:1 408 uImage-3.9.0-301.fc19.armv7hl.tegra ext2load mmc 0:1 400 dtb-3.9.0-301.fc19.armv7hl.tegra/tegra20-trimslice.dtb bootz 408 588 400 in a boot.scr.in file in the first partition then run mkimage -A arm - -O linux -a 0 -e 0 -T script -C none -n Fedora Boot Script -d boot.scr.in boot.scr i have tested it on a trimslice Is there any special U-Boot version requirement for Trim Slice, and if so, what version(s)? Also, will this image work for OMAP, and if so, are there any special instructions for Panda? d.marlin Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGMFOcACgkQkSxm47BaWfe70gCfRrNaSPcnwNmI4MxrKAw9tvxo TZYAoMKmJe/nZzBeSM3L3gyaS8POBKu6 =uxxv -END PGP SIGNATURE- ___ 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
Re: [fedora-arm] Trimslice with 1GB of RAM and DTB now working
On 04/15/2013 10:04 AM, Brendan Conoboy wrote: Hi folks, The people at Compulab sent me a pointer for how to fix the problem with the trimslice not booting using the latest kernel. It's as simple as setting a couple new uboot environment variables. See: http://www.trimslice.com/wiki/index.php/Trim-Slice_Firmware_Updater#U-Boot_environment_variable This works for me! My trimslice is now running 3.8.5-201.fc18.armv7hl.tegra with 1GB of memory. Since this work-around was noted for v2010.09-1.01, but v2010.09-1.03 is the latest (that I see on their website), has this been addressed in the newer versions (variables pre-defined in the firmware release)? If not, will it be addressed in the next release? If these settings are required, there should be no need for every user to add them manually. d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 for the Pogoplug e02
On 04/15/2013 10:28 PM, Robert Moskowitz wrote: I have a Pogoplug e02 sitting waiting to be used, and now I am ready to set it up. I have been using Fedora on my notebooks and Centos on my servers for a lot of years, so want to stay with what I know. I see that F18 for ARM was released in Feb: http://lists.fedoraproject.org/pipermail/arm/2013-February/005314.html However the instructions I am finding are for the F18 beta. I started with: http://fedoraproject.org/wiki/Architectures/ARM/PogoplugUSBDisk which has both F17 and F18 instructions. At this point, why start with F17 and have one less year before having to upgrade? But this page points to: http://fedoraproject.org/wiki/Architectures/ARM/Kirkwood#Writing_the_Image which talks about F18-beta. So what do I have to do to build a F18 production image and is there anything else I need to do? I don't know about the PogoPlug, but there is an F18 Kirkwood release image that was tested on GuruPlug: http://fedoraproject.org/wiki/Architectures/ARM/F18/GuruPlug#Writing_the_Image so maybe that could replace the Kirkwood#Writing_the_Image part of the instructions. Oh, the primary use of this system will be as a backup/archive server. ___ 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
Re: [fedora-arm] vexpress 3.8 update
On 02/28/2013 12:03 PM, Peter Robinson wrote: On Thu, Feb 28, 2013 at 6:05 PM, Jon Masters j...@redhat.com wrote: On 02/28/2013 12:29 PM, Mark Langsdorf wrote: The highbank model is upstream but I haven't used it in a while. The midway model is being used right now and is known to work, so I suspect the highbank model is mostly working. I can fix bugs that people report to me. Like I said the other day, I think we might need to consider moving to an A15 model just because that's what people are playing with. Meanwhile, what's the consensus on A9 qemu as a priority? Like I've said previously A15 at a later point in time. A9 qemu priority is low well below a working OMAP, tegra and highbank 3.8 kernel Since VExpress (QEMU) is a release blocker, and tegra is not, I would think it would be a higher priority, or we need to adjust our release criteria to match our new priorities. d.marlin = P ___ 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
Re: [fedora-arm] Asterisk build on ARM
On 01/20/2013 10:32 AM, Sean Omalley wrote: - Original Message - From: David A. Marlin dmar...@redhat.com To: arm@lists.fedoraproject.org Cc: Sent: Sunday, January 20, 2013 4:19 AM Subject: Re: [fedora-arm] Asterisk build on ARM On 01/19/2013 09:25 PM, Jeffrey Ollie wrote: Today at the ARM hackfest @ FUDCon I was able to get Asterisk 11.2.0 to build in mock on the Calxeda server and Asterisk started up on Smooge's Trimslice that I borrowed from him. However, when I looked at the ARM koji[1] the latest build failed here: armv7hl-redhat-linux-gnueabi-ar rv ../lib/libpj-armv7l-unknown-linux-gnu.a output/pjlib-armv7l-unknown-linux-gnu/ioqueue_select.o yadda yadda yadda make[5]: armv7hl-redhat-linux-gnueabi-ar: Command not found Seems rather odd that ar can't be found... In the arm.koji log it appears that it is trying to cross-build the package: : checking whether we are cross compiling... yes : configure: WARNING: using cross tools not prefixed with host triplet checking for ar... /usr/bin/ar so it is looking for a cross-ar instead of the native one. I'd look for why the configure script thinks it is cross compiling. I think because a platform is specified, it assumes it is a cross-compile. It has installer helper tools that need to run natively similar to the js stuff. Looking in the log I see the following configure line: ./configure --build=armv7hl-redhat-linux-gnu --host=armv7hl-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --host=armv7hl-redhat-linux-gnueabi LDFLAGS=-Wl,--as-needed,--library-path=/usr/lib Notice that '--host' is there twice, and the two do not match: --build=armv7hl-redhat-linux-gnu --host=armv7hl-redhat-linux-gnu --host=armv7hl-redhat-linux-gnueabi I think that second '--host=...' is what make configure try to cross compile the package, since it differs from the '--build'. I'd check for where the second '--host' was coming from, and why it is different from the first (and the '--build=...'). d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Trim Slice kernel issue
I was attempting to update the kernel on a Trim Slice running the Beta release on the internal SSD, when I started seeing errors on the console (log attached). Due to these errors the kernel update was incomplete. This looks similar to the issues we saw early on (f15) before we added the tegra-usb-no-reset hack/patch, so I downloaded the 3.6.10-6 SRPM and checked. The patch is still being applied. Is this a different issue with similar symptoms, or does this patch no longer address the issue in the newer kernels? Please let me know if I need to open a BZ on this. Thanks, d.marlin : Jan 18 19:35:13 trimslice-f18-v7hl kernel: [ 384.01] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:14 trimslice-f18-v7hl kernel: [ 385.055219] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:15 trimslice-f18-v7hl kernel: [ 385.518402] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:35:25 trimslice-f18-v7hl kernel: [ 395.842919] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:26 trimslice-f18-v7hl kernel: [ 396.887733] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:27 trimslice-f18-v7hl kernel: [ 397.729486] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:35:37 trimslice-f18-v7hl kernel: [ 408.107699] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:37 trimslice-f18-v7hl kernel: [ 408.337614] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:38 trimslice-f18-v7hl kernel: [ 408.814917] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:39 trimslice-f18-v7hl kernel: [ 409.608724] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:39 trimslice-f18-v7hl kernel: [ 409.966261] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:35:49 trimslice-f18-v7hl kernel: [ 420.275088] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:50 trimslice-f18-v7hl kernel: [ 421.316876] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:35:51 trimslice-f18-v7hl kernel: [ 422.177031] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:36:01 trimslice-f18-v7hl kernel: [ 432.484654] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:36:03 trimslice-f18-v7hl kernel: [ 433.526379] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:36:03 trimslice-f18-v7hl kernel: [ 434.465003] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:36:14 trimslice-f18-v7hl kernel: [ 444.803019] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:36:15 trimslice-f18-v7hl kernel: [ 445.557507] hub 3-0:1.0: cannot reset port 1 (err = -110) Jan 18 19:36:15 trimslice-f18-v7hl kernel: [ 446.445178] usb 3-1: reset high-speed USB device number 2 using tegra-i Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.740912] sd 0:0:0:0: [sda] Unhandled error code Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.745740] sd 0:0:0:0: [sda] Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.748899] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.754614] sd 0:0:0:0: [sda] CDB: Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.758122] Write(10): 2a 00 00 01 12 b6 00 00 32 00 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.763305] end_request: I/O error, dev sda, sector 70326 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.768730] Buffer I/O error on device sda1, logical block 34139 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.774900] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.780082] Buffer I/O error on device sda1, logical block 34140 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.786117] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.791304] Buffer I/O error on device sda1, logical block 34141 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.797330] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.802320] Buffer I/O error on device sda1, logical block 34142 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.808339] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.813349] Buffer I/O error on device sda1, logical block 34143 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.819370] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.824518] Buffer I/O error on device sda1, logical block 34144 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.830566] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.835567] Buffer I/O error on device sda1, logical block 34145 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.841747] lost page write due to I/O error on sda1 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.846747] Buffer I/O error on device sda1, logical block 34146 Jan 18 19:36:16 trimslice-f18-v7hl kernel: [ 446.852769] lost page write due
Re: [fedora-arm] rpmbuild on Fedora 17 ARM
On 01/19/2013 11:21 AM, Sean Omalley wrote: I'm having the same issue along with the build was looking for armv6 repo in the build requires even though the armv5 versions were installed. I just symlinked /usr/lib/rpm/platform/armv6l-linux to /usr/lib/rpm/platform/armv5tel-linux It isn't the proper fix, but it will give you the correct flags. I was told if you put: [mock@raspi ~]$ cat .rpmmacros %_host armv5tel-redhat-linux-gnu %_host_cpu armv5te that would work (and it may my errors were elsewhere) I ended up setting up mock though. I don't have a RPi to try this on, but can you just use: rpmbuild -ba --target=armv5tel SRPM d.marlin - Original Message - From: Antonio anto.tra...@gmail.com To: Development discussions related to Fedora de...@lists.fedoraproject.org; arm@lists.fedoraproject.org Cc: Sent: Saturday, January 19, 2013 11:07 AM Subject: [fedora-arm] rpmbuild on Fedora 17 ARM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. If I try to build a rpm on Fedora 17 ARM (installed on a RaspberryPi Model B) from a src.rpm fc18, rpmbuild compiles a binary file '.rpfr.armv6l' . But almost all RPMs from repositories are 'armv5tel'. Why ? Does a specific command exist in these cases ? Or would I edit the .spec file specifically for an ARM ? Thanks - -- Antonio Trande Fedora Ambassador Fedora italian translation group Blogger mail: mailto:sagit...@fedoraproject.org Homepage: http://www.fedora-os.org Sip Address : sip:sagitter AT ekiga.net Jabber :sagitter AT jabber.org GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ+sTLAAoJED2vIvfUANbEufgP/Ryj22bp2DB4maBvpjynuZKC U98Oeetgwetq4r6TX0SFpP3blGY20VkLSDKGHYG7Z3yWNHCQNxdnky+Qs/DYFAiO 2U4FWlt6ckHeRY8G4rdrRWkbW9XBU8Slgngg1jjG+8bCW6FP4Fl/g5pvuScZVt8R UGQikdPM8aJVu8IfHve+s2Lqwe09QBpVzK7bhGcDmggrLkydt0Q48NMaFbByiqrA Sn1U0wHwrMZb0XO0VVaeiR4UtxpT+NYAjSN0tAxswQN2a8/qtaLnVYTE+AwdKXTb wsPyw/z0k+4QEvjMGDbH9MiR/6I5bSFt34Da5+zt0TRquMcJk+yxogWAdKDh/XwD FdxSmoEy7n2o/ZsDMbAEb4Jl1jMFnVxRykM9gnS+J/yi4nkdO0GsUYxiMtv7u5ge GNc3BuxQ5yLAlqzFjo9XLCcyDYGJBb4/VYZpfOqyo4pf/YSIKZrMsQPPpFLh3KTt LuCo8GeofMjp+LAYMG0zCSXgpPYvoPgI8bqAooaVcJehFa1NQ4OZjhyWWN1hXJ3Y uKoUzg72OllKPQlLl1AnsSjcFd4Ti35UOveOIln5Dj8Vbfu5IAaapjdOFTTkxg8J DgHJYDxGun1lPJHDJ/j5nYrMwOzbwWWl8A0RBmgS2p4nY3lcLfoS5CNPXxEHwyrz 0uVIyF69dmY17EeR4oum =In1y -END PGP SIGNATURE- ___ 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
Re: [fedora-arm] Announcing Fedora 18 Beta for Allwinner A10 based devices
On 01/16/2013 11:51 PM, Daniel Veillard wrote: On Tue, Jan 15, 2013 at 04:28:19PM +0100, Hans de Goede wrote: [...] Known Issues: * Composite video out does not work Selecting composite video out (see README) causes the system to hang on boot. Investigation of this is pending. Thanks to Hans for his work on this, this allows me to use the Cubieboard instead of the Raspi and that feel far more sane :-) However I have 2 board running now and both exhibit the same problem, a constant extra load of 1 which i guess is due to some process stuck on I/O but i can't identify the issue: : Err: 0 [root@cubie ~]# uname -a Linux cubie 3.4.24+ #6 Tue Jan 15 22:57:26 CET 2013 armv7l armv7l armv7l GNU/Linux [root@cubie ~]# This is up2date Fedora 18, with Hans experimental kernel (note a yum update upgrades the kernel and the Cubies won't boot again, one need to reinstall kernel and associated modules). There is no Fedora kernel to update for the a10. This rootfs image was borrowed from another platform, so when you yum update, it updates the kernel for whatever platform the rootfs was made. That kernel, of course, will not boot on an a10 board. You'll need to modify the yum repo definitions to exclude the kernel package to avoid this. The proper fix will be to use a kernel installed via rpm (typically through yum) and a remix image for the specific board (i.e., Cubieboard), which has a cubie-release package that excludes the non-a10 kernel and points to the yum repo that has the Cubie specific packages (kernel, release, etc.). Then yum update should Just Work(tm). d.marlin === ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Status on Cubie/All Winner A10
On 01/10/2013 03:46 AM, Hans de Goede wrote: Hi, On 01/10/2013 10:24 AM, Peter Robinson wrote: On Thu, Jan 10, 2013 at 8:57 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/10/2013 04:55 AM, Daniel Veillard wrote: Hi everybody, following some problems with the Raspi, I have been looking at the Cubie as a possible replacement for my own project. I saw Hans mails about adding support in December and wondered what the status is currently. Anything I could try/test/debug when I have time ? I'm still working on this. After fixing a use-after-free bug in the sunxi kernel tree cgroup code (caused by an android specific patch), I now have a pretty stable and working setup. I hope to be able to publish Fedora-18 A10 images in a couple of days. As said I've everything ready, I just need to write a compose script so that I can create reproducable images, and provide easy instructions for others to reproduce my work. So hopefully I'll have something ready in a couple of days ... I suggest using the ARM installer stuff that dmarlin has been working on, with that you should be able to use a kickstart and live media creator. It would be good to get some feedback on the process too. http://fedoraproject.org/wiki/Architectures/ARM/Installer I'm sorry, but the most work for the A10 stuff atm is building the kernel + gazillion different u-boot + spl + fex (A10 variant of devicetree info file) files, after that I just take the panda images and drop everything in. I think I've a good enough kernel build now (I had to fix the sunxi hdmi code to teach it to talk to dvi monitors and to do EDID instead of a hardcoded resolution, after that I hit a memory corruption bug ...), so now all I really need is some shell scripts to be able to do reproducable kernel + uboot builds and then some more shell scripts to patch up a panda image to become an a10 image. I understand that patching the panda image is a hack and not a proper compose, but just getting all the a10 stuff to work is enough work without also adding real distro-composing into the picture. Are you packaging the kernel as an RPM? If so, what kernel version are you basing on? As mentioned before, Fu Wei has done some work on the A10 kernel as well, so maybe you could coordinate efforts. Also, if you have the kernel package in a yum repository, we should be able to generate images relatively easily using livemedia-creator and a kickstart. The only 'trick' would be getting the U-Boot configuration set up correctly. I could help set up the kickstart file, if you provide the U-Boot configuration information, and would like to pursue that. d.marlin === Regardsm Hans ___ 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
Re: [fedora-arm] Status on Cubie/All Winner A10
On 01/10/2013 12:55 PM, Hans de Goede wrote: Hi, On 01/10/2013 06:17 PM, David A. Marlin wrote: On 01/10/2013 03:46 AM, Hans de Goede wrote: snip I understand that patching the panda image is a hack and not a proper compose, but just getting all the a10 stuff to work is enough work without also adding real distro-composing into the picture. Are you packaging the kernel as an RPM? Currently no, I'm cross-compiling directly from git. I've already discussed coordinating my work with Fu Wei and part of the plan is for him to eventually turn my work into a proper rpm. If so, what kernel version are you basing on? I'm currently contributing to, and basing my work on the sunxi-3.4 branch of: https://github.com/linux-sunxi/linux-sunxi Very good. I believe that is the same branch Fu Wei is using. He already has this building natively and has a good start on packaging this as an RPM. As mentioned before, Fu Wei has done some work on the A10 kernel as well, so maybe you could coordinate efforts. Also, if you have the kernel package in a yum repository, we should be able to generate images relatively easily using livemedia-creator and a kickstart. The only 'trick' would be getting the U-Boot configuration set up correctly. I could help set up the kickstart file, if you provide the U-Boot configuration information, and would like to pursue that. I agree kickstart is the way to go in the semi-long run. For now I just want to get something out there, without just dropping an img file no-one can reproduce. Having something out there will also make discussing this easier, as then you will see that the A10 is special in some respects ... Sounds like a plan. I'll look at the image once you make it public. Thank you, d.marlin === Regards, Hans ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Git causing kernel lockup
On 12/24/2012 06:09 AM, Quentin Armitage wrote: I'm using F18-beta-rc3 on a Dreamplug and experiencing kernel soft lockups when I do a git clone. I first noticed this happening with the 3.6.3-3.f18.armv5tel.kirkwood kernel (it may occur on earlier versions too), but it is still occurring with 3.6.10-6.fc18.armv5tel.kirkwood. I get the following output on the console: [ 3531.311277] BUG: soft lockup - CPU#0 stuck for 22s! [git:678] [ 3531.317052] Modules linked in: 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_mangle ip6_tables xt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ledtrig_timer snd_usb_audio vfat fat snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm btmrvl_sdio btmrvl snd_page_alloc snd_timer snd soundcore libertas_sdio bluetooth libertas cfg80211 rfkill leds_gpio mv643xx_eth mmc_block sata_mv mvsdio mmc_core mv_cesa usb_storage [ 3531.364479] [ 3531.365971] Pid: 678, comm: git [ 3531.370604] CPU: 0Not tainted (3.6.10-6.fc18.armv5tel.kirkwood #1) [ 3531.377259] PC is at __dma_page_dev_to_cpu+0x68/0xcc [ 3531.382247] LR is at dma_async_memcpy_pg_to_pg+0x150/0x1dc [ 3531.387758] pc : [c000fa44]lr : [c0236274]psr: 6013 [ 3531.387758] sp : deb2dcf0 ip : 0001ee9d fp : [ 3531.399282] r10: c09f9880 r9 : 0fda r8 : 1ee9d07c [ 3531.404524] r7 : 0001 r6 : 007c r5 : 0026 r4 : c0b563a0 [ 3531.411073] r3 : c064e03c r2 : r1 : 007c r0 : c0b563a0 [ 3531.417622] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 3531.424790] Control: 0005397f Table: 1eb4 DAC: 0015 [ 3531.430571] [c000edac] (unwind_backtrace+0x0/0x124) from [c0074d40] (watchdog_timer_fn+0xe8/0x13c) [ 3531.439929] [c0074d40] (watchdog_timer_fn+0xe8/0x13c) from [c003aa18] (__run_hrtimer+0xb0/0x1d4) [ 3531.449109] [c003aa18] (__run_hrtimer+0xb0/0x1d4) from [c003b22c] (hrtimer_interrupt+0x104/0x250) [ 3531.458383] [c003b22c] (hrtimer_interrupt+0x104/0x250) from [c0016024] (orion_timer_interrupt+0x24/0x34) [ 3531.468259] [c0016024] (orion_timer_interrupt+0x24/0x34) from [c00754cc] (handle_irq_event_percpu+0x38/0x23c) [ 3531.478572] [c00754cc] (handle_irq_event_percpu+0x38/0x23c) from [c0075700] (handle_irq_event+0x30/0x40) [ 3531.488445] [c0075700] (handle_irq_event+0x30/0x40) from [c0077d30] (handle_level_irq+0xcc/0xdc) [ 3531.497616] [c0077d30] (handle_level_irq+0xcc/0xdc) from [c0074ef8] (generic_handle_irq+0x28/0x38) [ 3531.506965] [c0074ef8] (generic_handle_irq+0x28/0x38) from [c0009b64] (handle_IRQ+0x68/0x8c) [ 3531.515796] [c0009b64] (handle_IRQ+0x68/0x8c) from [c0444af4] (__irq_svc+0x34/0x78) [ 3531.523843] [c0444af4] (__irq_svc+0x34/0x78) from [c000fa44] (__dma_page_dev_to_cpu+0x68/0xcc) [ 3531.532847] [c000fa44] (__dma_page_dev_to_cpu+0x68/0xcc) from [c0236274] (dma_async_memcpy_pg_to_pg+0x150/0x1dc) [ 3531.543416] [c0236274] (dma_async_memcpy_pg_to_pg+0x150/0x1dc) from [c02377a8] (dma_memcpy_pg_to_iovec+0xf0/0x180) [ 3531.554161] [c02377a8] (dma_memcpy_pg_to_iovec+0xf0/0x180) from [c03835d0] (dma_skb_copy_datagram_iovec+0x100/0x1d4) [ 3531.565092] [c03835d0] (dma_skb_copy_datagram_iovec+0x100/0x1d4) from [c03a9c3c] (tcp_recvmsg+0x630/0xac0) [ 3531.575143] [c03a9c3c] (tcp_recvmsg+0x630/0xac0) from [c03c9138] (inet_recvmsg+0x48/0x5c) [ 3531.583713] [c03c9138] (inet_recvmsg+0x48/0x5c) from [c035bcfc] (sock_aio_read+0x100/0x120) [ 3531.592460] [c035bcfc] (sock_aio_read+0x100/0x120) from [c00e5524] (do_sync_read+0x98/0xd4) [ 3531.601204] [c00e5524] (do_sync_read+0x98/0xd4) from [c00e5e98] (vfs_read+0xb4/0x184) [ 3531.609416] [c00e5e98] (vfs_read+0xb4/0x184) from [c00e5fa4] (sys_read+0x3c/0x70) [ 3531.617281] [c00e5fa4] (sys_read+0x3c/0x70) from [c0008c60] (ret_fast_syscall+0x0/0x2c) [ 3559.310637] BUG: soft lockup - CPU#0 stuck for 22s! [git:678] [ 3559.316404] Modules linked in: 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_mangle ip6_tables xt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ledtrig_timer snd_usb_audio vfat fat snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm btmrvl_sdio btmrvl snd_page_alloc snd_timer snd soundcore libertas_sdio bluetooth libertas cfg80211 rfkill leds_gpio mv643xx_eth mmc_block sata_mv mvsdio mmc_core mv_cesa usb_storage [ 3559.365324] Pid: 678, comm: git [ 3559.369957] CPU: 0Not tainted (3.6.10-6.fc18.armv5tel.kirkwood #1) [ 3559.376611] PC is at __dma_page_dev_to_cpu+0x60/0xcc [ 3559.381600] LR is at __kunmap_atomic+0x7c/0x110 [ 3559.386152] pc : [c000fa3c]lr : [c0012910]psr: 6013 [ 3559.386152] sp : deb2dcf0 ip : 00014044 fp : [ 3559.397676] r10: c09f9880 r9 : 0fda r8 : 1ee9d07c [ 3559.402918] r7 : 0002 r6 : 0fda r5 : 0026 r4 : c09f9880 [ 3559.409467] r3 :
[fedora-arm] Fedora ARM F18 Beta VFAD - Today
Please join us today (20 DEC 2012) in #fedora-arm on Freenode for another Fedora ARM VFAD. A number of pre-created F18 ARM Beta TC3 images are available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU), and Kirkwood (GuruPlug). Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc3/ Please help us track the results by adding your findings to: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-20-VFAD-Fedora_18_Beta All help is appreciated and we look forward to your participation. Thank you, d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora-ARM Team Shirts
On 12/20/2012 12:43 PM, Scott Sullivan wrote: On 12/20/2012 01:32 PM, Sean Omalley wrote: You could do a block diagram of a V8 chip, and say I want a v8. :) [...] On 12/20/2012 01:20 PM, Chris Tyler wrote: We talked about this a long time back, but since a number of us will be together in one spot at FUDCon, maybe we should revive the idea of a Fedora ARM team shirt. (Fedora Logo) + ARM We know that its how you use it that counts. I though the issue last time was getting permission to use the logos (trademarks). d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 06:57 PM, Sean Omalley wrote: Update your uBoot? http://loginroot.com/installing-uboot-to-guruplug-server-plus/ While updating U-Boot is always an option, the images we make _should_ work with existing firmware. We need to look for better ways to make the images. d.marlin === *From:* Derek Atkins warl...@mit.edu *To:* David A. Marlin dmar...@redhat.com *Cc:* Fedora ARM arm@lists.fedoraproject.org *Sent:* Thursday, December 13, 2012 5:02 PM *Subject:* Re: [fedora-arm] F18 ARM Beta Test Candidate 2 David, David A. Marlin dmar...@redhat.com mailto:dmar...@redhat.com writes: projects/LinuxCellPhone There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU) and Kirkwood. Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/ I just tried the Kirkwood image and it didn't work because the 1st partition is EXT and not FAT. UBoot on my GuruPlug doesn't support that. Also note that I suspect I'm also running into a known kernel bug with the F17 release: https://bugzilla.kernel.org/show_bug.cgi?id=42680 Unfortunately I don't know if there is a workaround for this, especially considering that uImage-kirkwood reports that it is not compressed: /media/boot/uImage-kirkwood: u-boot legacy uImage, 3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 0x8000, Entry Point: 0x8000, Header CRC: 0xCDB8004D, Data CRC: 0x6C6E299A Any ideas? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.edu mailto:warl...@mit.edu PGP key available ___ arm mailing list arm@lists.fedoraproject.org mailto: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
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 04:02 PM, Derek Atkins wrote: David, David A. Marlin dmar...@redhat.com writes: There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU) and Kirkwood. Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/ I just tried the Kirkwood image and it didn't work because the 1st partition is EXT and not FAT. UBoot on my GuruPlug doesn't support that. Ok, we'll have to look at this image some more. Thank you for testing. d.marlin === Also note that I suspect I'm also running into a known kernel bug with the F17 release: https://bugzilla.kernel.org/show_bug.cgi?id=42680 Unfortunately I don't know if there is a workaround for this, especially considering that uImage-kirkwood reports that it is not compressed: /media/boot/uImage-kirkwood: u-boot legacy uImage, 3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 0x8000, Entry Point: 0x8000, Header CRC: 0xCDB8004D, Data CRC: 0x6C6E299A Any ideas? -derek ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F18 ARM Beta Test Candidate 2
There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU) and Kirkwood. Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/ Please read the release notes: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/f18-beta-tc2-release-notes.txt for information on installing/testing these images. Please download and test any images you are interested in. A VFAD (Virtual Fedora Activity Day) will be scheduled later to officially validate the images. Thank you for testing, d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 10:01 AM, Derek Atkins wrote: Hi, David A. Marlin dmar...@redhat.com writes: There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU) and Kirkwood. Are there instructions for Kirkwood? In particular, what uboot commands/environment do I need to set up? The release notes don't mention kirkwood, and I was having trouble with the F17 on my Guruplug Server (not Plus) so figured I'd try F18 to see if it was better. Jon Masters tested the first image (TC1) and posted some notes on it: http://lists.fedoraproject.org/pipermail/arm/2012-December/004609.html I guess we should add that to the release notes, unless we come up with a better approach. Please post if you have suggestions. Thanks, d.marlin === Thanks, -derek ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 09:58 AM, Jerry James wrote: On Thu, Dec 13, 2012 at 8:36 AM, David A. Marlin dmar...@redhat.com wrote: Please download and test any images you are interested in. A VFAD (Virtual Fedora Activity Day) will be scheduled later to officially validate the images. I have a package that is failing to build on F-18 ARM (but not F-17), so I grabbed the Versatile Express image to try to track down the problem. The very first boot attempt did this: [ OK ] Started udev Kernel Device Manager. [8.727567] systemd-udevd[96]: starting version 195 Starting dracut pre-trigger hook... [ OK ] Started dracut pre-trigger hook. Starting udev Coldplug all Devices... [ OK ] Started udev Coldplug all Devices. Starting Show Plymouth Boot Screen... Starting dracut initqueue hook... [ 12.353831] amba mb:mmci: Driver mmci-pl18x requests probe deferral [ 12.413569] scsi0 : pata_platform [ 12.416519] ata1: PATA max PIO0 no IRQ, using PIO polling mmio cmd 0x1001a000 ctl 0x1001a100 [ 12.436697] amba mb:mmci: Driver mmci-pl18x requests probe deferral [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Basic System. dracut-initqueue[142]: Warning: Could not boot. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Basic System. dracut-initqueue[142]: Warning: Could not boot. dracut-initqueue[142]: Warning: /dev/mmcblk0p3 does not exist Entering emergency mode. Exit the shell to continue. Type journalctl to view system logs. dracut:/# We are looking into this issue. d.marlin === Regards, -- Jerry James http://www.jamezone.org/ ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting minutes 2012-11-28
On 11/29/2012 03:53 AM, Peter Robinson wrote: On Wed, Nov 28, 2012 at 10:22 PM, Paul Whalen pwha...@redhat.com wrote: Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-28/fedora-meeting-1.2012-11-28-21.00.log.html A couple of things: 1) Who has the action item to deal with the texlive build? This is a beta blocker. 2) Mirror sync missing packages: do we have examples? Might be a tagging issue. The issue I was seeing was unsigned packages on the mirrors, i.e., Package kernel-tegra-3.6.7-5.fc18.armv7hl.rpm is not signed For a normal install, I can work around it (--nogpgcheck), but it causes image creation using livemedia-creator to fail. I saw some missing packages on mirrors a weeks or so ago, but that seems to be resolved. It was probably just a transient issue (caught the mirrors in the middle of a sync). d.marlin === 3) For F18 the kernel will remain as it is (ie there will be no unified kernel) but that doesn't preclude people from testing the F-19 unified kernels on F-18. 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
Re: [fedora-arm] ARMv8 Bootstrap Project
On 11/27/2012 11:28 PM, Jon Masters wrote: On 11/27/2012 06:00 PM, Al Stone wrote: Or, perhaps we can standardize on a location ... ? /srv/nfs-root or something? Please do generate an image assuming something like that. /srv is the FHS location and we should encourage standards at all costs. I would recommend the subpath being something like fedora-armv8-bootstrap or similarly obnoxiously specific, but I won't bikeshed it too much :) Please keep in mind that we (in GES) will need to be able to set this up in the farm, so we probably need to include $USER in the path, or some other way to make it user-specific so we don't step on each other. d.marlin === Then, we can do some generic instructions using a bind mount or whatever folks prefer to have that location point to wherever they actually have the bits stashed. Jon. ___ 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
Re: [fedora-arm] building F18 Kirkwood images
On 11/01/2012 10:52 AM, Derek Atkins wrote: David, I would be happy to help, however I have been unable to get the F17-GA image to run on my Guruplug.. If I could get that running then I could attempt to help with the F18 work. Thank you for offering to help. I was looking at the F17-GA test results: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-06-18-VFAD-Fedora_17_Test_Day#Overall_Test_Results_and_Board_Assignment and the Kirkwood image was tested on GuruPlug. Perhaps you can ping one of the testers of that image for help getting it working on your Guruplug. Thanks again, d.marlin === -derek David Marlin dmar...@redhat.com writes: It was brought to my attention that the F18 Alpha lacked a Kirkwood image, which we had for F17. We have been creating images for F18 using livemedia-creator (anaconda and lorax), where the F17 images were manually created using a custom script. The process we use is described on the wiki: http://fedoraproject.org/wiki/Architectures/ARM/Installer All the builders we have used for creating the F18 images are F17 armv7hl (hard-fp) systems. I personally have no experience with the Kirkwood devices, so I don't know what is needed to set up the image or configure the bootloader. We would appreciate volunteers running F17 on Kirkwood devices to help in creating an F18 image for those devices. The only development involved would be customizing the kickstart file to 1) include any special packages required for the device, and 2) set up any bootloader specific files/scripts needed for the device. The remainder of the effort would be to build and test the image. The hardware requirements include an ARMv5 device running F17-GA or later with access to external storage (requires space for the packages being installed and the resulting image) and swap (requires 1GB total memory). We have created v7hl images using a Trim Slice (1GB memory plus 500MB swap) with external (USB) hard drive, so something similar would probably work. I am willing to provide assistance and answer questions about using the tools and modifying the kickstart config file, but I have no ARMv5 hardware on which to build or test these images. Thank you, d.marlin ___ 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] 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] Who's using Kirkwood?
Jon Masters wrote: Hi Folks, I'm interested to know who is using Kirkwood, and who would miss it if it went away. Just to get a rough gauge of interest, perhaps we should look at the download stats for the F17 images. That won't tell us the number of actual 'users', but will at least give us an idea of how many people even looked at Fedora on Kirkwood (and other platforms). Just a thought, d.marlin For now, we won't kill off ARMv5 because it is used in the official rPi builds but that doesn't mean I'm not interested to know whether we should put testing effort into Kirkwood for F18. My thought is that the latest plugs are moving to ARMv7, and so as the cutting edge Linux distro, we should make plans for deprecating support over the coming releases. This is not a call to drop support today. If I can get numbers on how many people care, that will help. Jon. ___ 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
Re: [fedora-arm] New Fedora-ARM Kernel Built -- Check it out and test it!
Brendan Conoboy wrote: On 09/13/2012 07:04 PM, jon.chiappe...@senecacollege.ca wrote: [ http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=93466 kernel-3.6.0-0.rc4.git2.1.fc18 ] Boots with some soft lockups on my trimslice using sda, original uboot and modified (higher up) uInitramfs load address. Full log: http://fpaste.org/pQaq/ Please try booting it from SDCard, as that is where the problems started (and have continued to be). Boot commands: setenv bootargs mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M video=tegrafb console=ttyS0,115200n8 ro root=/dev/sda2 nohdparm rootwait earlyprintk ext2load usb 0:1 408 uImage-tegra ext2load usb 0:1 840 uInitrd-tegra bootm 408 840 Please try 408 (kernel) and 488 (initrd). This leave 8MB for the kernel, which I believe was what came out of earlier discussions on the subject of load addresses. d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Setting host system type on ARMv5
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonat...@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type
being picked up for ARMv5 builds, especially on ARMv7 builder systems.
Here's an example output from running an OpenMPI build on Fedora 18
using the current Koji builder setup, note the armv7l target:
--- begin quote ---
checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking target system type... armv7l-unknown-linux-gnueabi
--- end quote ---
I believe that this is incorrect, at least, this is in question. The
compiler options (set elsewhere) are correct from an ABI point of view,
and the output will be a soft float ABI target, but it's not the right
architecture revision target. It will matter in a few cases. For example
when a package is choosing inline assembly or other specifics that
differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the
differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics
stuff in due course, but they have a giant mess called asmlib that
provides their own custom atomic functions (what could go wrong?) for
historical reasons. The macros used to build that are enough to make you
gouge your eyes out, but once you figure it out, it's obvious that they
do already have ARMv5 assembly code that should work, if it thinks it's
building for an armv5l system. And it's faster to just pick that up than
reworking a lot of not just code, but also other arches and build
macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think
we want to ensure that configure is picking up
armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It
should do this irrespective of the actual host architecture of the
builder. I tried just force overriding it in a test build with an
%{ifarch} armv5tel but that wasn't picked up, so I missed something,
but in general that's not the right approach anyway. We want something
at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it
and not the underlying platform without exception. The same goes with
features like NEON (and MMX/SSE on x86). I've fixed a number of these
before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi
there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set
correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are
being run on a v7 host?
Thanks,
d.marlin
=
If we figure out why this is
happening, OpenMPI should just build. Meanwhile, if you do setup a
wimpybuilder channel for v5-specific builds, you could add OpenMPI
into that channel and it ought to build if the host is ARMv5. I also
thinking we could do something to get at least one successful build
through by ensuring it runs on a system that is an ARMv5 host. Then we'd
at least have an openmpi package that had been built as a dep.
I'll ping you and others later about fixing this. Got to finish this
article on atomics now. When I'm done, we should have material others
can use to help fix issues. Not this issue, this isn't really an atomics
issue as it turns out.
Jon.
___
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] Using livemedia-creator on ARM
I have a draft of the instructions for using livemedia-creator (Anaconda/Lorax) for creating a disk image on ARM: https://fedoraproject.org/wiki/Architectures/ARM/Installer I have only tested this on the Trim Slice, and it seems to work well. This assumes you have adequate backing storage (hard disk) to hold the resulting images. If the host system does not have a hard drive, some alternate storage may need to be set up to hold the disk image (i.e., NFS or iSCSI). Although other ARM platforms should be recognized by Anaconda/Lorax, I don't have any specific U-Boot scripts or templates set up for them yet. Note: I am trying to get these changes upstream, but they will not be accepted in F17 (too late in the cycle), so I am keeping them in a separate repo for testing. Please let me know if you have any questions or have suggestions for improvement. Thank you, d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Some comments on bconoboy's trimslice images
Richard W.M. Jones wrote: In general pretty good - they work well. However there are a few problems I encountered: (1) There's no source for the boot scripts. I think you should put the source along side the binaries, in /boot/uboot. I ended up using 'strings' and reconstructing them. Agreed, the source for the script should be added. (2) The sda boot script works fine, however the mmc boot script fails. 'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places). It worked as provided for me (fatload mmc 0:1). Could this be device dependent? (3) If you have both images installed, then it boots one of them at random, because it boots from 'root=LABEL=rootfs' which picks one of the labelled root devices at random. This is not a completely stupid configuration: you need to do this if you're booting from a USB key and copying the mmc image to the internal drive. At some point you'll have a trimslice with both the sda image and the mmc image. Probably better to use UUIDs, or to have different labels. I think he was going for consistency across images (change as little as possible) and to support copying the image to an internal drive, as you mentioned. Would using UUIDs work in this scenario? If so, what would need to be done (if anything) besides transferring the image (via 'dd')? I'm working on creating disk images using lorax/anaconda, and have modeled much of the configuration from Brendan's scripts, so any tips are appreciated. d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Some comments on bconoboy's trimslice images
Richard W.M. Jones wrote: On Fri, Apr 27, 2012 at 09:42:22AM -0500, David A. Marlin wrote: Richard W.M. Jones wrote: In general pretty good - they work well. However there are a few problems I encountered: (1) There's no source for the boot scripts. I think you should put the source along side the binaries, in /boot/uboot. I ended up using 'strings' and reconstructing them. Agreed, the source for the script should be added. (2) The sda boot script works fine, however the mmc boot script fails. 'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places). It worked as provided for me (fatload mmc 0:1). Could this be device dependent? Possibly. I replaced the supplied no-brand micro SD card (4G) because it failed, with a branded Samsung 32GB card. I've no idea if this would change the numbering. Ah, I see the difference. I used the external (front) SDCard slot, and not the internal micro-SD. I think this image was intended for the external (front) slot. (3) If you have both images installed, then it boots one of them at random, because it boots from 'root=LABEL=rootfs' which picks one of the labelled root devices at random. This is not a completely stupid configuration: you need to do this if you're booting from a USB key and copying the mmc image to the internal drive. At some point you'll have a trimslice with both the sda image and the mmc image. Probably better to use UUIDs, or to have different labels. I think he was going for consistency across images (change as little as possible) and to support copying the image to an internal drive, as you mentioned. Would using UUIDs work in this scenario? If the UUIDs are different, or changed to be different (tune2fs -U ...) If so, what would need to be done (if anything) besides transferring the image (via 'dd')? The problem is I was using the sda image for my external (sda) drive, and the mmc image for my internal drive. The main issue was confusion -- why rebooting would randomly choose a different root device. Yes, that would be confusing, and not desirable. :( I'm working on creating disk images using lorax/anaconda, and have modeled much of the configuration from Brendan's scripts, so any tips are appreciated. Standard advice is to use UUIDs instead of labels or (worst of all) device paths. However if we're copying images around at all, then there's the danger of having duplicate UUIDs which is really bad. I wonder if the normal Fedora live CD generates a new random UUID after resizing the minimized image? It must do. I don't know how that works, but since it does I think it would be good to leverage that approach (whatever it is). d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Jared's long list of F15 builds
Jared K. Smith wrote:
Over the past few days, I've been trying to dive in and help out in
the F15 effort by resubmitting failed builds and helping to identify
key packages that are failing to build. I've posted my list of
packages at http://openetherpad.org/Fedora-ARM-jsmith, and will try to
keep it updated, at least in the short term.
udev
* RPM build errors
I've looked a bit at udev. The offending file entries in the .spec file
are:
# Deprecated, but keep the ownership
%ghost %dir /var/lib/udev
:
%ghost %dir %{_sysconfdir}/udev/makedev.d/
I'm not sure why these cause problems (except maybe because they don't
exist in our rootfs), but I commented them out and did a local build and
it succeeded. I then checked the latest F15 updates version of udev,
and the lines have been removed completely. I did a local build on that
version (udev-167-6) and it also succeeded.
So I think we have two options, 1) create a modified .spec file without
those lines (with a '.arm1' release), or 2) use the newer version.
d.marlin
The way I created my
list was to take the critical path packages from F15 (on x86_64,
because that's what I had handy), and the list of failed builds in F15
on ARM Koji over the last week, and anything that was in both lists
went onto my list. It's a rough list at best, but it's a start :-)
The good news is, most of the packages rebuilt just fine. There are
still a dozen or so packages that need extra attention, so please look
at my list and feel free to dive in and start helping. (Please mark
on the website that you're working on a particular package, so that we
don't step on each others' toes.)
--
Jared Smith
Fedora Project Leader
___
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
Re: [fedora-arm] U-Boot?
Gordan Bobic wrote: On 10/14/2011 07:05 PM, Brendan Conoboy wrote: On 10/14/2011 10:54 AM, Chris Tyler wrote: Note that the GuruPlug ships with a broken uboot, which uses the wrong machine identifier. To use a mainline kernel, you must munge the kernel machine ID or update the GuruPlug's uboot. Ooh, good to know. The phrase the kernel we're working with caught my eye. Which kernel are we talking about? I'm specifically thinking of David Marlin's kernel as referenced here: http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels (I've heard but have not verified that the Kirkwood and OMAP patch sets used to be pretty much mutually-exclusive; I haven't tried to build a unified kernel and hope this has been fixed). Yuck. I know David has been endeavoring to make his changes mesh easily with additional parties adding their own pet board to the SRPM. Most of our systems are omap and tegra based so we haven't seriously looked into kirkwood support. If somebody wants to add kirkwood support they should bear in mind your warning about the broken uboot. I'm pretty sure that Kirkwood support required for the SheevaPlug has been in mainline since at least 2.6.35, possibly earlier. Whether OMAP patches break this, I don't know. In fact, Kirkwood is one of the few SoCs that has complete support for all of the extras, too, in the mainline kernel, too (e.g. crypto engine). Someone built a 2.6.39 kernel for kirkwood (Dreamplug) by adding a couple of patches to one of my earlier kernel SRPMs (which was also tested on Panda/OMAP), but when we tried it on a 2.6.40 (3.0-based) kernel SRPM the resultant image failed to boot. I can probably dig up those packages if anyone who has a kirkwood system wants to work on it. d.marlin = ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Slow USB storage on A9 processors
Peter Robinson wrote: Hey All, I know it was discussed a while ago how the USB storage on PandaBoards was slow, not sure what the resolution was but saw this article on LWN that looks like our problem there for those that might not have seen the post elsewhere and are interested. https://lwn.net/Articles/457145/ I have built a kernel package for f13 and f15 using Mark's patches. They are available from the xpfa repos. http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels#Set_Up_the_Repository The f15 repo can be set up just like the f13 version by using f15 in the path, i.e.: sudo yum --nogpgcheck install \ http://dmarlin.fedorapeople.org/packages/FedoraArm/RPMS/noarch/xpfa-15-1.noarch.rpm If you install (or update) and configure the f15 grubby (grubby-7.0.16-5.01.fc15.armv7hl.rpm) it will create the U-Boot images for you (as per the instructions mentioned above). Notes: If you use grubby, be sure to configure /etc/sysconfig/uboot _before_ installing the kernel. This version of grubby has only been tested on a Panda board (omap) and on the Trim Slice (tegra). Be sure to install the correct kernel variant for your system, i.e.: sudo yum --enablerepo=xpfa install kernel-omap# for Panda sudo yum --enablerepo=xpfa install kernel-tegra # for Trim Slice d.marlin 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
Re: [fedora-arm] remaining F15 hardfp bootstrap dependencies
DJ: I'm not sure if I'm just missing something, but when I tried to build audit (source package that includes audit-libs) I encountered the following build dependencies (beyond what were already installed on the panda boards): swig python-devel tcp_wrappers-devel libcap-ng-devel openldap-devel libprelude-devel These in turn required additional dependencies of their own: cyrus-sasl cyrus-sasl-devel gnutls-devel libcap-ng-devel libgcrypt-devel libgpg-error-devel libprelude tcp_wrappers-devel While some of these are on the list (below), others are not. Do you know why some build dependencies (swig, libprelude, etc.) are not in the dependency list? Thank you, d.marlin = DJ Delorie wrote: Based on what we've got built and what we want to have built, I wrote a perl script to rpm -qp --requires all the remaining SRPMs and try to group them according to what could be built next based on resolved dependencies. Packages are groups by what can be built in parallel. There are a few circular dependencies I noted below, but even so, there is a tangle at the end that still needs to be resolved. PACKAGE DEPENDENCIES acl gawk gettext libattr libtool attr gettext libtool basesystem elfutils bison bzip2 flex gcc gettext glibc-headers xz zlib expatautoconf automake check libtool fedora-release filesystem iso-codes keyutils glibc-kernheaders less autoconf automake libtool ncurses pcre libffi libmpc gmp mpfr texinfo libsepol libutempter lua ncurses readline nspr perl db4 gdbm groff procps rsyslog systemtap-sdt tcsh zlib popt doxygen gettext graphviz redhat-rpm-configlibtool shadow-utils audit-libs libacl libattr libselinux sqlite /usr/bin/tclsh autoconf glibc ncurses readline tcl perl-version perl setupbash perl tcsh tzdata gawk glibc glibc-common java perl now build pkgconfig without glib e2fsprogslibblkid libselinux libsepol libuuid pkgconfig texinfo libidn gettext pkgconfig nss-util gawk nspr perl pkgconfig psmisc zlib now build python without openssl ca-certificates java-openjdk perl python rcs cracklib autoconf automake gettext gettext-autopoint libtool python words file python zlib libxml2 pkgconfig python zlib pam audit-libs autoconf automake bison cracklib cracklib-dicts db4 docbook-dtds docbook-style-xsl flex gettext libselinux libtool libxslt linuxdoc-tools perl pkgconfig sed w3m libcap libattr pam now build nss and nss-softokn together rpm bzip2 db4 elfutils elfutils-libelf fakechroot file gawk gettext libacl libcap libselinux libsemanage lua ncurses nss nss-softokn-freebl popt python readline redhat-rpm-config xz zlib gamin : glib2 glib2 : gamin krb5 : openldap openssl cyrus-sasl : krb5 openldap openssl openldap : cyrus-sasl krb5 openssl openssl : krb5 shared-mime-info : glib2 libssh2 : openssl audit : openldap ___ 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
Re: [fedora-arm] Fedora 13 ARM Beta3 Release
Jeffrey Bastian wrote: On 2011-05-12 10:35, Paul Whalen wrote: We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list � arm@lists.fedoraproject.org. I'm new to the Fedora ARM world; my PandaBoard just arrived a couple weeks ago and I soon had Fedora 13 Beta 2 running on it. Overall, the userspace in F13 Beta 2 has been great, and I'll be updating to Beta 3 right away! Thanks for the hard work! However, I found the process rather confusing with respect to the kernel. The root filesystem was pretty straightforward, but it wasn't clear to me where I was supposed to get a kernel from. Should I be building my own? Or is there a repository out there with ARM kernels? Some kernels support running a GUI but are short on RAM, others maximize the RAM but are limited to serial consoles. Which one should I use? After a lot of reading [1][2][3][4][5], I ended up using the kernel at http://scotland.proximity.on.ca/arm/kernel/pandaboard/ This kernel doesn't appear to support SELinux or iptables, though, so I'm going to give David Marlin's kernel[6] a try next. I've build a newer version that has HIMEM enabled: kernel-omap-2.6.38.5-24.02.fc13.armv7l.rpm http://people.redhat.com/dmarlin/packages/FedoraArm/RPMS/armv7l/kernel-omap-2.6.38.5-24.02.fc13.armv7l.rpm so if you have 1GB memory, and are _not_ using TI's binary multimedia bits (which use RAM from 463 to 511MB) you can use the full amount of memory available on the Panda Board. When using the new build, omit the mem=463M in the bootargs. Again, there has been very little testing on this kernel, so if you encounter any problems, or have suggestions for improvement, please post. d.marlin Out of curiosity, I tried Ubuntu 11.04 to compare and it was surprisingly easy to install: just dd the image to an SD card and boot. The image includes a kernel and the necessary partition layout, and it automatically resizes the root filesystem partition to fill up the SD card on first boot (which is slow, but that's the SD card's fault). Thanks again! Jeff [1] http://fedoraproject.org/wiki/Architectures/ARM/Using [2] http://pandaboard.org/content/resources/getting-started [3] http://omappedia.org/wiki/Main_Page [4] http://paulfedora.wordpress.com/ [5] http://perfectlylogical.wordpress.com/ [6] http://lists.fedoraproject.org/pipermail/arm/2011-May/001270.html ___ 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] Fedora 2.6.38 kernel for ARM-OMAP
I was looking to try a newer kernel on the beagle board and panda board
I was using (both running F13), and decided to try building 2.6.38 from
the Fedora 15 SRPM. I modified the spec file to include an option to
build for armv7l, and added an armv7l config file, as well as armv7l
support in Makefile.config. I also included one 2.6.39 upstream patch
(PandaBoard-remove-unused-power-regulators).
All the source and binary packages I built are in:
http://people.redhat.com/dmarlin/packages/FedoraArm/
I built a kernel from the following source package:
SRPMS/kernel-2.6.38.5-24.01.fc13.src.rpm
using the F13 tools on the panda board, and installed and booted it on
both the beagle and panda boards. The command I use to build it is:
rpmbuild -bb --target=armv7l SPECS/kernel.spec
Before installing the kernel binary RPM, I installed new linux-firmware
and grubby RPMs on the boards. The 2.6.38 kernel requires a newer
version of linux-firmware than is available in the F13 ARM repo, so I
rebuilt the one from F15. The new grubby package is not really
necessary, but I patched it to be armv7l aware, otherwise it defaults to
x86 (and looks for lilo or grub bootloaders). The modifications also
provide a placeholder in case I wanted to modify it further to create
the uboot images for the beagle/panda boards.
To install the kernel on the panda board I just use:
rpm -ivh kernel-omap-2.6.38.5-24.01.fc13.armv7l.rpm
It takes a while to install, since it has to install all the modules,
make an initramfs, etc.
I keep all the uboot files in /boot/uboot. To build the uboot images
for this kernel I use:
cd /boot
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000
-n 2.6.38.5-24.01.fc13.armv7l.omap -d
vmlinuz-2.6.38.5-24.01.fc13.armv7l.omap
uboot/uImage-2.6.38.5-24.01.fc13.armv7l.omap
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d
initramfs-2.6.38.5-24.01.fc13.armv7l.omap.img
uboot/uInitrd-2.6.38.5-24.01.fc13.armv7l.omap
I then reboot the board from the console, and interrupt the auto-boot
script. The commands I use to boot and test the new kernel on the panda
board are:
setenv mpurate 800
setenv bootargs console=ttyO2,115200n8 mem=463M ro rootwait
root=/dev/mmcblk0p4 mpurate=${mpurate} init=/sbin/init earlyprintk
rd_NO_PLYMOUTH
setenv bootcmd 'mmc rescan 0; mmc init; fatload mmc 0:1 0x8030
uImage-2.6.38.5-24.01.fc13.armv7l.omap; fatload mmc 0:1 0x8160
uInitrd-2.6.38.5-24.01.fc13.armv7l.omap; bootm 0x8030 0x8160'
boot
Your options may differ, depending on your flash configuration, uboot
version, etc., but these work for me.
I have not preformed extensive testing, but it does boot and seems to
work well on the F13 rootfs.
Notes:
I have only modified this to build for armv7l. Further modifications
will be necessary for other variants.
The config file I used is based on an older existing ARM config, so
I'm sure the options are not optimal.
The config file does not follow the Fedora conventions (broken down
between the generic, arch, and board config files).
I'm not sure the best way to break this out and maintain it, so
suggestions are welcome.
Please let me know if you have any questions, comments, or suggestions.
d.marlin
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
