[fedora-arm] Fedora 22 Beta RC3 Docker base image for arm
Hi all, https://ausil.us/fedora-arm/22_Beta_RC3/Docker/armhfp/ contains a updated docker base image that matches the Fedora 22 Beta RC3 compose. which is the F22_Beta final image. Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot plans for Fedora 22 ?
Hi, > I have to take this back, it seems that this build is appending: > > " console=ttyS0,115200" > > To the kernel cmdline, I've just double-checked and this is not upstream > behavior, is this being done by Fedora specific patches ? > > This breaks kernel output and systemd status messages output on > tty0 / the hdmi output, resulting in a blackscreen until gdm > starts. > > As discussed a while back, the proper way to do is set > stdout-path in the devicetree to the serial console, then the > kernel will automatically make it a second console, next to tty0 > and output messages on both, and systemd will output messages > and spawn gettys on both too. This in my testing is not working unless i add console=ttySO,115200 to the bootargs I get nothing out at all on the serial port, though in u-boot it had stdin as serial and stdout as vga. what are all the possible options and how should things just work? the current patch is not a regression for Fedora. I want to make things just work for all. > Upstream u-boot is already setting stdout-path for all sunxi > devices, so from a sunxi pov the appending of " console=ttyS0,115200" > is a regression. If this is done for some other boards, it would > be better to either patch those boards dts files to set stdout-path, > or u-boot to set stdout-path rather then appending " console=ttyS0,115200" > and breaking video output. If you can tell me which specific boards > need work here I can whip up a patch (for others to test). We should patch all boards to be the same. but it needs to work. Regards Dennis > Regards, > > Hans > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] depmod error can't find System.map-module-info
On Wednesday, May 06, 2015 04:39:25 PM jefby wrote: > Hello,everyone. > > When i use mock build the DVD iso for AACH64,it prints this error,do > you know how to fix it and why ?? > Thanks very much! how are you running pungi? all fedora composes happen in mock chroots of the target os. > depmod: FATAL: could not load > //work/Fedora/aarch64/yumroot/boot/System.map-module-info: No such > file or directory > Traceback (most recent call last): > File "/usr/bin/pungi", line 300, in > main() > File "/usr/bin/pungi", line 171, in main > mypungi.doBuildinstall() > File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line > 1414, in doBuildinstall > workdir=workdir, outputdir=outputdir, volid=volid) > File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 285, in > run rb.generate_module_data() > File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line > 152, in generate_module_data > runcmd(["depmod", "-a", "-F", ksyms, "-b", root, kver]) > File "/usr/lib/python2.7/site-packages/pylorax/executils.py", line > 411, in runcmd > return execWithRedirect(cmd[0], cmd[1:], **kwargs) > File "/usr/lib/python2.7/site-packages/pylorax/executils.py", line > 179, in execWithRedirect > raise subprocess.CalledProcessError(ret, [command]+argv) > subprocess.CalledProcessError: Command '['depmod', '-a', '-F', > '//work/Fedora/aarch64/yumroot/boot/System.map-module-info', '-b', > '//work/Fedora/aarch64/yumroot', 'module-info']' returned non-zero > exit status 1 > > jefby > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Pidora -
On Friday, May 08, 2015 12:03:57 PM Clive Messer wrote: > On Thu, 2015-05-07 at 18:35 +1000, Adrian wrote: > > Clive's FC21 images at www.digitaldreamtime.co.uk/images/Fidora/21 > > are fantastic , > > > > & looking forward to build the PI2 F22 images here on that base in the > > near future. > > > > The minimal images running systemd D-Star repeater services are the most > > stable we have ever seen. > > Adrian, > > Not sure whether I'll be able to post them this weekend, but I'd > appreciate you (and anyone else who wants to) testing my Pi2B F22 BETA > remix images when I upload them. > > While I look forward to "official" F22 support for Pi2B, I have > concerns. Don't know exactly what and how they intend to do it, but > suspect it will be mostly paying lip service using upstream uboot and > kernel, so there will still be "space" for a remix, which actually works > the way users want it to work, rather than "it barely boots". (AFAIK, > there is still no support for bootable overlay support if you chain-load > upstream uboot and if kernel support is based on mainline upstream plus > the bcm2836 patches Eric Anholt submitted to the linux-arm mailing list > last month, saying you support the Pi2B but only using one CPU core of > it and not the 4 cores the hardware provides is going to result in > someone needing to don the flame-proof overalls!) > > Regards > > Clive Clive, Fedora ARM has never paid lip service to any platform. We have always taken the harder/longer road by ensuring that we get things upstream and use what is upstream. We were the first distro to adopt a multi-platform kernel and to adopt devicetree , why because it was the right things, it did mean that things were a bit rough as things were hashed out and fixed. but in the long term it is the right things for Fedora as well as all other distros. we have the Pi 2 enabled in rawhide's u-boot and will be enabling the kernel support as it gets upstream. where all distros can easily support it and have things working. I am not sure what you mean by bootable overlay support. Hardware Vendors are getting much better about having their systems supported upstream than they used to be because they see a value proposition in doing so. A big part of that is because of the work we have done in Fedora. Is it perfect? no, but it is much better and getting better all the time. There is no reason we will not support all the hardware in the Pi, but it is going to take people getting the support upstream. saying we will pay lip server is very rude and disrespectful. Regards Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora 22 Docker Base image for arm
Hi All, I have built and posted a Fedora 22 Docker base image for ARM that matches the one on x86_64. it can be found https://ausil.us/fedora-arm/22/Docker/armhfp/ enjoy Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 22 Docker Base image for arm
On Tuesday, June 02, 2015 09:11:08 AM Adam Miller wrote: > On Tue, Jun 2, 2015 at 9:05 AM, Dennis Gilmore wrote: > > Hi All, > > > > I have built and posted a Fedora 22 Docker base image for ARM that matches > > the one on x86_64. it can be found > > https://ausil.us/fedora-arm/22/Docker/armhfp/ > First and foremost, this is awesome! Thanks for doing this. :) > > Second > > Is this something that could be pushed up to the Docker hub under the > Fedora namespace? Just slap a armhfp (or $similar) tag on it with > appropriate documentation that it's meant to be used for ARM? I am sure we can, there is a bunch of arm images up there already, we would just need to do it. I am not 100% sure how to do so. Dennis > Or maybe even open up a new "namespace" in the Docker hub that's > specific to Fedora ARM? > > Just a thought, but I think it'd be cool to have this officially out > in the hub so people can easily 'FROM fedora:armhfp' or 'FROM > fedora-arm:latest' in their Dockerfiles. > > -AdamM > > > enjoy > > > > Dennis > > ___ > > 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 signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Installation of Fedora 22 on my ARM based board
On Wednesday, June 17, 2015 05:57:00 PM Andrew Wing wrote:
> Thank you again. That's got me a little further.
>
> I notice from looking at the sd card it uses ext3 for the boot partition,
> ext4 for the root file system, so the dd to the mmc must preserve that.
> Unfortunately the boot loader only has an ext2load and ext4load. Consulting
> with a colleague and Mr google, I shouldn't expect an ext3load to be
> available but ext2load might well load ext3 with a little bit of luck.
>
> I duly proceeded under that assumption and got the following results:
>
> U-Boot# setenv bootargs console=${console} root=LABEL=_/ ro rootwait
> U-Boot# saveenv
> Saving Environment to MMC...
> Writing to MMC(1)... done
> U-Boot# ext2load mmcblk 0:1 0x8030 vmlinuz-4.0.4-301.fc22.armv7hl
> mmc_send_cmd: timeout: CTO
> mmc_send_cmd: timeout: CTO
> 5645832 bytes read in 660 ms (8.2 MiB/s)
>
>
>
> U-Boot# ext2load mmcblk 0:1 0x8030 vmlinuz-4.0.4-301.fc22.armv7hl
> 5645832 bytes read in 661 ms (8.1 MiB/s)
> U-Boot# ext2load mmcblk 0:1 0x8160 uInitrd-4.0.4-301.fc22.armv7hl
> 27397171 bytes read in 3184 ms (8.2 MiB/s)
> U-Boot# ext2load mmcblk 0:1 0x8930 hub.dtb
> 31710 bytes read in 14 ms (2.2 MiB/s)
> U-Boot# bootz 0x8030 0x8160 0x8930
> ## Loading init Ramdisk from Legacy Image at 8160 ...
>Image Name: initramfs
>Image Type: ARM Linux RAMDisk Image (uncompressed)
>Data Size:27397107 Bytes = 26.1 MiB
>Load Address:
>Entry Point:
> ## Flattened Device Tree blob at 8930
>Booting using the fdt blob at 0x8930
>Loading Ramdisk to 9e404000, end 9fe24bf3 ... OK
>Using Device Tree in place at 8930, end 8930abdd
>
> Starting kernel ...
>
>
Is there a defined console environment variable?
assuming that your u-boot is configured correctly you can replace ext2load or
ext4load with load. ext4load is actually an alias for ext2load. It's all using
the same code paths under the hood. two suggestions from me. move the kernel
to somewhere higher, perhaps the decompressor is clobbering the uncompressed
kernel as it decompresses. make sure that the console is set right. then next
thing would be to look at the dtb.
Dennis
> A colleague who is looking into using another well-known ARM linux distro
> found that the dtb file used with Angstrom needed some minor modification
> before it could be with that distro (and would otherwise hang), so that is
> an area of investigation. I guess it would be good to nail down whether I
> am getting problems because of the ext2/ext3 or get some clues as to where
> it is bombing out.
>
> I do have access to the u-boot source.
>
> Andrew
>
> On 17 June 2015 at 11:42, Peter Robinson wrote:
> > Hi Andrew,
> >
> > > It's using a TI AM3352 OMAP family SoC. Overall it looks like a
> >
> > BeagleBone
> >
> > > Black, but no EEPROM on i2c, different DDR RAM (and no sd card socket).
> > >
> > > I do have a device tree. I have full access to all the bits and pieces
> >
> > put
> >
> > > together to make this boot under Angstrom, just don't know how to
> >
> > re-arrange
> >
> > > them to make it boot under Fedora!
> >
> > So if you've copied the DT onto the boot partition (partition 1) you
> > should be able do something along the lines of the bits below to get
> > it booting. I'm making the assumption here that it's got eMMC for the
> > onboard flash and it's identified as mmc0, update as appropriate. You
> > might need to swap ext4 for ext2, obviously update the name of the
> > dtb.
> >
> > setenv bootargs console=${console} root=LABEL=_/ ro rootwait
> > ext4load mmc 0:1 0x8030 vmlinuz-4.0.4-301.fc22.armv7hl
> > ext4load mmc 0:1 0x8160 uInitrd-4.0.4-301.fc22.armv7hl
> > ext4load mmc 0:1 0x8930 blah-blah.dtb
> > bootz 0x8030 0x8160 0x8930
> >
> > Let me know how you get on.
> >
> > Do you have access to the u-boot source?
> >
> > Peter
signature.asc
Description: This is a digitally signed message part.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Is support for Utilite envisioned?
env default -f -a On July 3, 2015 2:26:29 PM CDT, Steven Falco wrote: >On 07/03/2015 03:05 PM, Steven Falco wrote: >> On 07/03/2015 01:53 PM, Steven Falco wrote: >> So the next challenge is to figure out why I'm getting the >"unrecognized >> filesystem type". > >This appears to be caused by the u-boot environment, which I assume >is still the original Utilite one. It is trying to fatload, but >Fedora uses ext3 for /boot. > >Is there a recommended way to update or reset the environment? > > Steve > > >___ >arm mailing list >arm@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/arm -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora 22 Updated Docker Base image for arm
Hi All, I have built and posted an updated Fedora 22 Docker base image for ARM that matches the one on x86_64. it can be found at https://ausil.us/fedora-arm/22_Updates/Docker/armhfp/ enjoy Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM release-blocking desktop changed to Xfce
It worked in f22 but was a bit slow. Plasmashell is segfaulting and the bug filing process does not work. Dennis On August 8, 2015 10:54:48 AM CDT, Rex Dieter wrote: >Adam Williamson wrote: > >> ). For those not at >> the meeting and who don't want to read through the whole log, this >has >> been changed on the basis that KDE 5 requires 3D acceleration and >does >> not fully work with llvmpipe (software rendering), and we don't have >> hardware 3D support for any of our supported ARM platforms at this >> time, so it no longer makes any sense for KDE to be the blocking >> desktop for ARM. > >This should have been the case already for Fedora 22 as well. Did it >work >there and something (recently) regressed or am I missing something? > >-- Rex > >___ >arm mailing list >arm@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/arm -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] System time
On Tuesday, September 01, 2015 01:03:03 PM Robert Moskowitz wrote: > On 09/01/2015 12:14 PM, Robert Nelson wrote: > > On Tue, Sep 1, 2015 at 11:10 AM, Robert Moskowitz wrote: > >> How is system time set? Is ntpdate run after the network is ready? How > >> long does it retry waiting for the network to be available? > >> > >> I have seen a number of challenges becuase the system time is bac at the > >> epoch start as there is no battery rtc. And I wonder how many armv7 > >> boards have a battery to maintain time across boots? > >> > >> Minimally, a process could right the time, in the proper format, to a > >> file, > >> say /etc/currenttime every 5 min and at shutdown. > >> > >> Then date can be run early in the boot process, piping this file in. It > >> would not be perfect and does not help, much for new installs, but better > >> than epoch start. > >> > >> Plus /etc/currenttime can be at least set to the image build date/time so > >> not even firstboot will be at epoch start. > > > > systemd v215+ has a nice feature to take care of this: > > > > systemctl enable systemd-timesyncd.service > > Thanks! I see that this DOES work even when no network. It would be > good if the images came with this enabled and with the time set to the > build date/time, so we had a better starting time a firstboot. Without a battery backed RTC its really not that useful. Picture 6 or 10 months after a release, does it matter if the time is half a year to a year off or 35 years off? I am just trying to understand what problem you think this solves. chronyd or timesyncd should fix up the time as soon as you get a network connection. Regards Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Not working as advertised - Re: System time
On Wednesday, September 02, 2015 03:46:55 PM Miroslav Lichvar wrote: > On Wed, Sep 02, 2015 at 08:51:17AM -0400, Robert Moskowitz wrote: > > OH?!? I am running F22 with Xfce, last updated Aug 23. So whatever is in > > there wrt systemd-timesyscd and chronyd is what was in the image orginally > > plus whatever happened when I did the date/time config in the graphic > > configurator as part of the install (I go in and change my city from NYC > > to > > Detroit). A quick check shows: > > > > So it seems both are present, but only chronyd is running. > > The chrony package is installed by default and the time configuration > tool is enabling/disabling the chronyd service (via timedatex). To > start timesyncd on boot you can either run "systemctl disable chronyd" > and "systemctl enable timesyncd", or uninstall the chrony and > timedatex packages and disable and enable the NTP checkbox again in > the time config. > > > I made these changes. In /etc/chrony.conf I now have: > > > > # Enable kernel synchronization of the real-time clock (RTC). > > #rtcsync > > rtcdevice /dev/nonexist > > > > I commented out the rtcsync line, given you told me to add the nonexist > > line. Hope that is correct. > > That shouldn't matter, if there is no battery for the RTC, there is > probably no point in trying to keep the RTC synchronized. > > > Perhaps these settings should be standard in our armv7 builds? Or an easy > > option to set them. A check box for 'no rtc' on that configurator? > > Maybe anaconda could do that. How common is to have a Fedora ARM > machine without an RTC and how common it is to have an RTC, but no > battery? Every arm device I have used has a rtc, but a very large number of them have no battery. some have two rtc devices and teh battery backed one ends up on /dev/rtc1 > There is also a possibility to restore the time from a file in a > separate service, without having to run an NTP client. On Debian, > it's done by the fake-hwclock service. For Fedora there seems to be a > Copr repo with it. I didn't try it. > > https://copr.fedoraproject.org/coprs/jorti/fake-hwclock/ chronyd in my use has always set the time correctly as soon as it has a working network connection. any attempt to set the time based on something in the filesystem is going to result in the time being off. if it is something baked in at compose or image creation time the drift will get bigger over time. if it is some service that sets it on shutdown the drift will be small. network is required to get it accurate. I would really like to know the use cases where chronyd is not sufficient and the problems that people are trying to solve. Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] System time
On Wednesday, September 02, 2015 04:45:33 PM Till Maas wrote: > On Tue, Sep 01, 2015 at 01:38:21PM -0500, Dennis Gilmore wrote: > > Without a battery backed RTC its really not that useful. Picture 6 or 10 > > months after a release, does it matter if the time is half a year to a > > year > > off or 35 years off? > > If a system needs to use something TLS-protected, then the system clock > must not be too much off because a certificate might not be valid > otherwise. At least in debian there is also a fake hwclock package that > reduces the offset to the time that passed since the system was last > booted: Sure, but is there uses for TLS without the network having come up? at which point chronyd would have set the time correctly. Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Not working as advertised - Re: System time
On Wednesday, September 02, 2015 04:43:19 PM Miroslav Lichvar wrote: > On Wed, Sep 02, 2015 at 09:29:27AM -0500, Dennis Gilmore wrote: > > any attempt to set the time based on something in the filesystem is going > > to result in the time being off. if it is something baked in at compose > > or image creation time the drift will get bigger over time. if it is some > > service that sets it on shutdown the drift will be small. network is > > required to get it accurate. > > > > I would really like to know the use cases where chronyd is not sufficient > > and the problems that people are trying to solve. > > I think the purpose of saving and restoring system time from a file is > to have monotonic time on machines that don't have a network > connection or only have an intermittent connection, so messages in > logs can be sorted, make doesn't complain timestamps are in future, > etc. Okay, in this case setting a time at image creation, or image installation is not sufficient. There would need to be some service that saves the time on poweroff and restores on powerup. though there will be a short period of time still where in many cases the logs have the epoch date/time l the service resets the time when there is no battery backed rtc. I think that this should be an optional thing so to not interfere with battery backed rtc's Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 23 for aarch64 is here!
On Wednesday, November 04, 2015 05:13:58 AM Clive Messer wrote: > On Tue, 2015-11-03 at 17:38 +, Peter Robinson wrote: > > Fedora 23 for aarch64 released > > At the risk of incurring your wrath.. > > If I understand this correctly, the two "supported" platforms are > > a) AMD Seattle 1100 > b) Applied Micro X-Gene > > Now, please correct me if I am wrong, (it's been a while since I > looked), but ISTR that the AMD dev kit costs $3000 and the X-Gene, a > mere, $2500. > > I understand why RedHat might want to target those "business" class > solutions, but surely the 64 bit hardware that Fedora, (Fedora distro, > not RedHat disto), needs to be targeting with "official" out-of-the-box > support are the 96Boards, ie. HiKey and Dragonboard Hardware that > is actually accessible to "ordinary" people to tinker with, at $100 a > pop! We want to support the hikey etc boards, support for them is still not yet upstream. then there is the issues that without nand, spi, etc flash for uefi/u-boot you get in a place where to support it you need to go a custom route because the standard tools will not work. > Every single person I have spoken to in the last few months, and by > that I mean ordinary users on ordinary salaries, (not people getting > given expensive hardware for free, or earning high-end salaries that > can afford to buy $2500 boards), who are starting to look at 64 bit ARM > hardware are buying one of the two 96Boards solutions, not the $$$ > "business class" development kits. > > I am just stating this as an observation. I have no axe to grind or > financial interest in any of the above. biggest issue with 96boards is the lack of upstream and standards support, which is ironic when they aim to be a standard. for Fedora to support systems they need to get support for their hardware upstream. Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: F23 works great on PCDuino3 Nano Light
On Monday, December 21, 2015 05:21:55 PM Troy Dawson wrote: > Hi All, > Yep, it's my report on the worst named arm computer, that runs good :) > > Anyway I have two reports. > ** 1st report ** > From all my tests, the PCDuino3 Nano Light "just works". I installed > the F23 XFCE image, followed the uboot instructions with just one > change, I used the PCDuino3 Nano uboot, cuz Lite is supposed to be the > exact same. > The graphical first-boot came up, I set it up, and XFCE came up. Not > a bit of extra twiddling on my part. > > I am currently updating the system to see if it will automatically > boot into the newer kernel. Since the regular PCDuino3 Nano > automatically boots into the newer kernel, I am 99% confident this > will too. But I don't like to say it will without testing it. > > echo "deltarpm=False" >> /etc/dnf/dnf.conf > > Use that to speed up your update by at least 20 minutes. > > ** 2nd report ** > PCDuino3 Nano Light is currently $15 on amazon. > > http://smile.amazon.com/pcDuino-pcDuino3-Nano-Lite/dp/B00ZEPZGQO/ref=lp_9348 > 557011_1_1?srs=9348557011&ie=UTF8&qid=1450738901&sr=8-1 > > CPU: AllWinner A20 SoC, 1GHz ARM Cortex A7 Dual Core > DRAM: 1GB > Full size HDMI port > 1000 Mb/sec ethernet (take with a grain of salt, but it is faster than > 100 Mb/sec) > SATA port (no cables) > SD card slot. Says it only handles 32Gig, I run mine with 64Gig sd cards > No on board flash - The big difference between Nano and Nano lite. > > Sorry that I sound like an ad. It's just that it's a decent arm > computer that runs straight F23, for only 15 dollars. The lite has no nand and no ir receiver. Otherwise they are the same. I got one also, but so far no luck booting it with rawhide. Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: 32 bit ARM guest on aarch64 host
On Saturday, February 27, 2016 03:44:04 PM Richard W.M. Jones wrote: > On Sat, Feb 27, 2016 at 01:33:26PM +, Richard W.M. Jones wrote: > > Should I try a newer guest? I am going to try updating to Fedora 23. > > Same thing. > > Attached is the qemu command line. In this run I'm using some > hand-constructed XML, not 'virt-install --import' as before, but AFAIK > all important options are the same. > > Rich. It is currently not possible to boot a 32 bit arm vm without an external kernel and initrd. I have played with having a u-boot that will work. But right now you would need to construct the guest to match the specs hardcoded into u-boot. It is a problem that needs to be solved Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: 32 bit ARM guest on aarch64 host
On 2016-02-27 11:59, Richard W.M. Jones wrote: On Sat, Feb 27, 2016 at 10:45:55AM -0600, Dennis Gilmore wrote: On Saturday, February 27, 2016 03:44:04 PM Richard W.M. Jones wrote: > On Sat, Feb 27, 2016 at 01:33:26PM +, Richard W.M. Jones wrote: > > Should I try a newer guest? I am going to try updating to Fedora 23. > > Same thing. > > Attached is the qemu command line. In this run I'm using some > hand-constructed XML, not 'virt-install --import' as before, but AFAIK > all important options are the same. > > Rich. It is currently not possible to boot a 32 bit arm vm without an external kernel and initrd. I have played with having a u-boot that will work. But right now you would need to construct the guest to match the specs hardcoded into u-boot. It is a problem that needs to be solved Thanks Dennis. When you say you've played with u-boot, does that mean booting with an external u-boot binary? That would be a considerable improvement over external kernel. Rich. Yes I have used u-boot as a kernel. its very rough and not really a good experience, at least in that you have to configure the vm the same as u-boot was built. ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: Fedora-Minimal-armhfp-24-20160308.0
On Wednesday, March 9, 2016 7:43:05 PM CST David Jones wrote: > Hi > > Installed > > Fedora-Minimal-armhfp-24-20160308.0-sda.raw > > Is arm-boot-config still being used? if so it was missing from the image. > > Regards > > David No it has been removed from fedora. it is expected that you have extlinux.conf support in u-boot. What is your device? and u-boot version Dennis signature.asc Description: This is a digitally signed message part. ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] builder changes
Hi all. in the sprit of transparency. I have made some changes to the builders that are currently online to /etc/sysctl.conf ive added vm.min_free_kbytes = 65000 vm.swappiness = 0 and ive made sure all builders have a swap file at /swap1 Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [F15 PATCH 0/6] ARM: Add support for pata_imx (for Genesi Smarttop)
El Wed, 28 Dec 2011 17:54:25 + Niels de Vos escribió: > Hi there! > > This patchset contains only cherry-picked patches from Linus' current > tree. Without these patches, the Genesi Smarttop does not recognize > the onboard SSD-chip. The required driver (pata_imx) is already > included in the ARM verion of the kernel, only the bindings with the > board are missing. > > Instead of sending all patches in separate emails, I'm attaching them > numbered and all for easy inclusion in the F15 kernel. I have done > local testing and can happily report that the 2.6.41.6-1 kernel can > use the onboard SSD when appying these patches. > > I (and other Fedora ARM owners of a Smarttop) appreciate it if these > patches can be included in a next release. Many thanks, > Niels > > --- > Arnaud Patard (4): > imx51: add pata device > imx51: add pata clock > imx: efika: Enable pata. > Fix pata imx resource > > Fabio Estevam (1): > ARM: imx: Add PATA resources for other i.MX processors > > Uwe Kleine-König (1): > ARM: mx5: fix remaining inconsistent names for irqs > > arch/arm/mach-mx5/Kconfig |1 + > arch/arm/mach-mx5/clock-mx51-mx53.c |7 +- > arch/arm/mach-mx5/devices-imx51.h |4 + > arch/arm/mach-mx5/devices.c | 10 +- > arch/arm/mach-mx5/mm.c |8 +- > arch/arm/mach-mx5/mx51_efika.c |2 + > arch/arm/plat-mxc/devices/Kconfig |3 + > arch/arm/plat-mxc/devices/Makefile |1 + > arch/arm/plat-mxc/devices/platform-pata_imx.c | 59 > arch/arm/plat-mxc/include/mach/devices-common.h |8 + > arch/arm/plat-mxc/include/mach/mx35.h |2 +- > arch/arm/plat-mxc/include/mach/mx51.h | 162 > +++--- 12 files changed, 175 insertions(+), 92 > deletions(-) create mode 100644 > arch/arm/plat-mxc/devices/platform-pata_imx.c > Ill get them applied. Im looking to pull the frame buffer bits into the kernel also so that the smarttop and smartbook will both work in f15 and up. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Koji - RPM naming
El Sat, 31 Dec 2011 13:26:00 -0700
escribió:
> As i have come across the builds of rpm's in koji i noticed that some
> packages have something like dist_0.src.rpm or dist_1.src.rpm instead
> if dist.src.rpm. This causes koji to spit them out due to version
> mismatch errors, how is this addressed by the fedora team?
> Do ou have to modify the main tag or?
we make the srpms from a git checkout on primary arches. %{?dist} is
set to whats expected inside the buildroot used to make the srpms. the
srpms we feed into secondary arches have matching fedora-release
installed and get the right values. without specifics about what your
talking about or doing there is no way to help you.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Koji - RPM naming
El Sun, 01 Jan 2012 01:43:17 +
Gordan Bobic escribió:
> On 01/01/2012 01:16 AM, Dennis Gilmore wrote:
> > El Sat, 31 Dec 2011 13:26:00 -0700
> > escribió:
> >> As i have come across the builds of rpm's in koji i noticed that
> >> some packages have something like dist_0.src.rpm or dist_1.src.rpm
> >> instead if dist.src.rpm. This causes koji to spit them out due to
> >> version mismatch errors, how is this addressed by the fedora team?
> >> Do ou have to modify the main tag or?
> >
> > we make the srpms from a git checkout on primary arches. %{?dist} is
> > set to whats expected inside the buildroot used to make the srpms.
> > the srpms we feed into secondary arches have matching fedora-release
> > installed and get the right values. without specifics about what
> > your talking about or doing there is no way to help you.
>
> I believe what Don is talking about is that some src.rpm packages are
> called dist_.src.rpm instead of dist..src.rpm, and
> what we have found is that koji seems to choke on this. But if you:
>
> rpm -ivh mypackage-1.2.3.dist_1.src.rpm
> cd ~/rpmbuild/SPECS
> rpmbuild -bs mypackage.spec
>
> you end up with mypackage-1.2.3.dist.1.src.rpm
>
> If you feed the original file with the underscore to koji, it chokes
> on it. If you feed it the newly generated src.rpm with the . in the
> name instead of _, it works fine.
>
> What Don and I are wondering about is where did these _ named
> packages come from and why.
im guessing then your talking about rhel rpms. the dist value would be
set to whats in the srpm at its build time.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Koji - RPM naming
El Sun, 01 Jan 2012 02:34:33 +
Gordan Bobic escribió:
> On 01/01/2012 02:28 AM, Dennis Gilmore wrote:
> > El Sun, 01 Jan 2012 01:43:17 +
> > Gordan Bobic escribió:
> >> On 01/01/2012 01:16 AM, Dennis Gilmore wrote:
> >>> El Sat, 31 Dec 2011 13:26:00 -0700
> >>>escribió:
> >>>> As i have come across the builds of rpm's in koji i noticed that
> >>>> some packages have something like dist_0.src.rpm or
> >>>> dist_1.src.rpm instead if dist.src.rpm. This causes koji to spit
> >>>> them out due to version mismatch errors, how is this addressed
> >>>> by the fedora team? Do ou have to modify the main tag or?
> >>>
> >>> we make the srpms from a git checkout on primary arches. %{?dist}
> >>> is set to whats expected inside the buildroot used to make the
> >>> srpms. the srpms we feed into secondary arches have matching
> >>> fedora-release installed and get the right values. without
> >>> specifics about what your talking about or doing there is no way
> >>> to help you.
> >>
> >> I believe what Don is talking about is that some src.rpm packages
> >> are called dist_.src.rpm instead of dist..src.rpm,
> >> and what we have found is that koji seems to choke on this. But if
> >> you:
> >>
> >> rpm -ivh mypackage-1.2.3.dist_1.src.rpm
> >> cd ~/rpmbuild/SPECS
> >> rpmbuild -bs mypackage.spec
> >>
> >> you end up with mypackage-1.2.3.dist.1.src.rpm
> >>
> >> If you feed the original file with the underscore to koji, it
> >> chokes on it. If you feed it the newly generated src.rpm with
> >> the . in the name instead of _, it works fine.
> >>
> >> What Don and I are wondering about is where did these _ named
> >> packages come from and why.
> >
> > im guessing then your talking about rhel rpms. the dist value
> > would be set to whats in the srpm at its build time.
>
> Yes we are talking about the RHEL6 rpms, but the problem isn't in the
> dist part - the problem seems to be that something has ended up
> creating the src.rpms with the _ separator after the dist part for
> some reason.
thats part of the dist tag
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Koji - RPM naming
El Sun, 01 Jan 2012 02:55:46 +
Gordan Bobic escribió:
> On 01/01/2012 02:53 AM, Dennis Gilmore wrote:
> > El Sun, 01 Jan 2012 02:34:33 +
> > Gordan Bobic escribió:
> >> On 01/01/2012 02:28 AM, Dennis Gilmore wrote:
> >>> El Sun, 01 Jan 2012 01:43:17 +
> >>> Gordan Bobic escribió:
> >>>> On 01/01/2012 01:16 AM, Dennis Gilmore wrote:
> >>>>> El Sat, 31 Dec 2011 13:26:00 -0700
> >>>>> escribió:
> >>>>>> As i have come across the builds of rpm's in koji i noticed
> >>>>>> that some packages have something like dist_0.src.rpm or
> >>>>>> dist_1.src.rpm instead if dist.src.rpm. This causes koji to
> >>>>>> spit them out due to version mismatch errors, how is this
> >>>>>> addressed by the fedora team? Do ou have to modify the main
> >>>>>> tag or?
> >>>>>
> >>>>> we make the srpms from a git checkout on primary arches.
> >>>>> %{?dist} is set to whats expected inside the buildroot used to
> >>>>> make the srpms. the srpms we feed into secondary arches have
> >>>>> matching fedora-release installed and get the right values.
> >>>>> without specifics about what your talking about or doing there
> >>>>> is no way to help you.
> >>>>
> >>>> I believe what Don is talking about is that some src.rpm packages
> >>>> are called dist_.src.rpm instead of
> >>>> dist..src.rpm, and what we have found is that koji seems
> >>>> to choke on this. But if you:
> >>>>
> >>>> rpm -ivh mypackage-1.2.3.dist_1.src.rpm
> >>>> cd ~/rpmbuild/SPECS
> >>>> rpmbuild -bs mypackage.spec
> >>>>
> >>>> you end up with mypackage-1.2.3.dist.1.src.rpm
> >>>>
> >>>> If you feed the original file with the underscore to koji, it
> >>>> chokes on it. If you feed it the newly generated src.rpm with
> >>>> the . in the name instead of _, it works fine.
> >>>>
> >>>> What Don and I are wondering about is where did these _ named
> >>>> packages come from and why.
> >>>
> >>> im guessing then your talking about rhel rpms. the dist value
> >>> would be set to whats in the srpm at its build time.
> >>
> >> Yes we are talking about the RHEL6 rpms, but the problem isn't in
> >> the dist part - the problem seems to be that something has ended up
> >> creating the src.rpms with the _ separator after the dist part for
> >> some reason.
> >
> > thats part of the dist tag
>
> I think I just twigged what you actually mean. There must have been a
> builder with a broken dist tag setting?
its set in the buildroot. so you have two choices. 1) make sure you set
it to match the srpms you feed in. 2) rebuild the srpms to match what
you are using.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder changes
El Wed, 28 Dec 2011 12:06:39 -0600 Dennis Gilmore escribió: > Hi all. > > in the sprit of transparency. I have made some changes to the builders > that are currently online > > to /etc/sysctl.conf ive added > vm.min_free_kbytes = 65000 > vm.swappiness = 0 > > > and ive made sure all builders have a swap file at /swap1 > > Dennis Today i changed the build time out to 7 days. we got 3 days into openoffice.org in f14 and the build got cancelled due to timing out. so we are trying again. hopefully 7 days is long enough :) Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder changes
El Sun, 01 Jan 2012 21:51:44 -0700 escribió: > where did you change the build timeout :) > > Just hit that with gcc and ppl > > EXCEPTION: Timeout(86400) expired for command: > > Original Message > Subject: Re: [fedora-arm] builder changes > From: Dennis Gilmore > Date: Sun, January 01, 2012 6:22 pm > To: arm@lists.fedoraproject.org > its set in kojis __init__.py on f15 its at /usr/lib/python2.7/site-packages/koji/__init__.py by default is is one day 86400 seconds > El Wed, 28 Dec 2011 12:06:39 -0600 > Dennis Gilmore escribió: > > Hi all. > > > > in the sprit of transparency. I have made some changes to the > > builders that are currently online > > > > to /etc/sysctl.conf ive added > > vm.min_free_kbytes = 65000 > > vm.swappiness = 0 > > > > > > and ive made sure all builders have a swap file at /swap1 > > > > Dennis > > Today i changed the build time out to 7 days. we got 3 days into > openoffice.org in f14 and the build got cancelled due to timing out. > so we are trying again. hopefully 7 days is long enough :) > > Dennis > ___ > 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] builder io isue
El Sat, 24 Dec 2011 23:25:56 -0600 Dennis Gilmore escribió: > When we were testing build were happening really fast, once we loaded > up the build jobs things have become really slow > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=238672 started > at 1:19 utc and at 5:18 utc four hours later the buildrequires are > still being installed. australia is completely io bound. i think we > need to see how we can spread the io load. ~30 hosts reading and > writing to the 4 spindles just saturates the disk io. i guess options > are find a way to add more spindles. move /var/lib/mock to sdcard, see > if we can get some kind of san that has alot of smaller fast disks. > get some 2.5" usb drives one for each builder. some other idea? is > there anyway we could add 4-8 more disks to australia. the size of the > matters little. gaining more iops by adding more spindles would help. > > Just throwing out what im seeing. lets see what ideas we can come up > with. performance is better than before. and seneca has done a great > job and put a lot of hard work into the reorg and im thankful for > that. We just have another bottleneck to address. > ___ > arm mailing list > arm@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=245410 has been running 10 hours now. its inited the chroot and installing the srpm. it is a big srpm but still. performance on the hfp builders while not great is better. when looking at a sfp builder the mock process is using 100% cpu and in a D state. there is one of two issues here. the hfp builders are running a slightly older kernel. so it could be a kernel ext3 nfs or loop device issue, upgrading a hfp builder for testing would confirm it. or its some issue with decompresion of the rpms. I do think that disk io on the nfs server is partly to blame. the box sits at a load of 9 all the time with 30% or so io wait. Id like to take a layer or 2 of the complexity out. switching over to nfsv4 we should be able to run mock on it. im going to do some compression tests with the latest 2.6.41.6 kernel. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] builder io isue
El Mon, 2 Jan 2012 12:55:09 -0600 Dennis Gilmore escribió: > El Sat, 24 Dec 2011 23:25:56 -0600 > Dennis Gilmore escribió: > > When we were testing build were happening really fast, once we > > loaded up the build jobs things have become really slow > > > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=238672 > > started at 1:19 utc and at 5:18 utc four hours later the > > buildrequires are still being installed. australia is completely io > > bound. i think we need to see how we can spread the io load. ~30 > > hosts reading and writing to the 4 spindles just saturates the disk > > io. i guess options are find a way to add more spindles. > > move /var/lib/mock to sdcard, see if we can get some kind of san > > that has alot of smaller fast disks. get some 2.5" usb drives one > > for each builder. some other idea? is there anyway we could add > > 4-8 more disks to australia. the size of the matters little. > > gaining more iops by adding more spindles would help. > > > > Just throwing out what im seeing. lets see what ideas we can come up > > with. performance is better than before. and seneca has done a > > great job and put a lot of hard work into the reorg and im thankful > > for that. We just have another bottleneck to address. > > ___ > > arm mailing list > > arm@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/arm > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=245410 has been > running 10 hours now. its inited the chroot and installing the srpm. > it is a big srpm but still. performance on the hfp builders while not > great is better. when looking at a sfp builder the mock process is > using 100% cpu and in a D state. there is one of two issues here. the > hfp builders are running a slightly older kernel. so it could be a > kernel ext3 nfs or loop device issue, upgrading a hfp builder for > testing would confirm it. or its some issue with decompresion of the > rpms. I do think that disk io on the nfs server is partly to blame. > the box sits at a load of 9 all the time with 30% or so io wait. Id > like to take a layer or 2 of the complexity out. switching over to > nfsv4 we should be able to run mock on it. im going to do some > compression tests with the latest 2.6.41.6 kernel. further followup ive inited chroots on my pandaboard. ive used 2 sdcards both are 32gb transcend class 10 cards both with the same mock configs with caching disabled. like koji. [dennis@fedora-armhfp ~]$ time mock -r fedora-15-armhfp --init INFO: mock.py version 1.1.18 starting... State Changed: init plugins INFO: selinux enabled State Changed: start State Changed: lock buildroot State Changed: clean INFO: chroot (/var/lib/mock/fedora-15-arm) unlocked and deleted State Changed: unlock buildroot State Changed: init State Changed: lock buildroot Mock Version: 1.1.18 INFO: Mock Version: 1.1.18 INFO: calling preinit hooks State Changed: running yum State Changed: unlock buildroot INFO: Installed packages: State Changed: end real8m14.626s user2m8.930s sys 0m21.234s [dennis@panda01-sfp ~]$ time mock -r fedora-15-arm --init INFO: mock.py version 1.1.18 starting... State Changed: init plugins INFO: selinux enabled State Changed: start State Changed: lock buildroot State Changed: clean INFO: chroot (/var/lib/mock/fedora-15-arm) unlocked and deleted State Changed: unlock buildroot State Changed: init State Changed: lock buildroot Mock Version: 1.1.18 INFO: Mock Version: 1.1.18 INFO: calling preinit hooks State Changed: running yum State Changed: unlock buildroot INFO: Installed packages: State Changed: end real10m37.586s user2m13.969s sys 0m20.406s so i think its pretty safe to assume that compression is working ok. so it comes down to ext3, loopback device, kernel, or something else. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Arm repo status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, so when we do the branched report and now the rawhide report we are syncing the bits shortly after to the primary mirrors. I thought i grab a few tidbits bits of data and get them out there the arm (soft floating point) repo in koji has 15664 binary rpms in them and 12649 of those have been built in koji, which leaves us with 3015 binary rpms coming from the moji repo. the armhfp (hard floating point) repo in koji has 16761 binary rpms in them and 12634 of those have been built in koji, which leaves us with 4127 binary rpms coming from the stage4 repo. this just means we had slightly more built in stage4 than moji. with the last of the recent changes we are building faster than we ever have, we also do not have all the builders up so we are looking to be in good shape to follow primary arch into f17. biggest issue is to get the gcc builds completed. Dennis [1] i got the numbers from http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=251177 which was the most recent f15 repo when composing this email. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk8LT7EACgkQkSxm47BaWfeMkwCfWym2QmmaVlf3HNY+aYO1wJbB dnsAnjwkTT4mQIzJgtzDlwPaQG46w1hj =TZq7 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Arm repo status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 9 Jan 2012 14:35:56 -0600 Dennis Gilmore escribió: > > Hey all, > > so when we do the branched report and now the rawhide report we are > syncing the bits shortly after to the primary mirrors. > > I thought i grab a few tidbits bits of data and get them out there > > the arm (soft floating point) repo in koji has 15664 binary rpms in > them and 12649 of those have been built in koji, which leaves us with > 3015 binary rpms coming from the moji repo. > the armhfp (hard floating point) repo in koji has 16761 binary rpms > in them and 12634 of those have been built in koji, which leaves us > with 4127 binary rpms coming from the stage4 repo. > > > this just means we had slightly more built in stage4 than moji. with > the last of the recent changes we are building faster than we ever > have, we also do not have all the builders up so we are looking to be > in good shape to follow primary arch into f17. biggest issue is to > get the gcc builds completed. > > Dennis > > [1] i got the numbers from > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=251177 which > was the most recent f15 repo when composing this email. the in koji numbers include the noarch only packages that we imported directly into koji. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk8LfkMACgkQkSxm47BaWffMXACgnSLRBTRJ4GHwS/pteq9c1Oil I/QAn3ZAqSOVcran0p7Kg5gd6mgEOS2q =QepU -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Arm repo status
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Mon, 9 Jan 2012 17:54:43 -0600
Dennis Gilmore escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> El Mon, 9 Jan 2012 14:35:56 -0600
> Dennis Gilmore escribió:
> >
> > Hey all,
> >
> > so when we do the branched report and now the rawhide report we are
> > syncing the bits shortly after to the primary mirrors.
> >
> > I thought i grab a few tidbits bits of data and get them out there
> >
> > the arm (soft floating point) repo in koji has 15664 binary rpms in
> > them and 12649 of those have been built in koji, which leaves us
> > with 3015 binary rpms coming from the moji repo.
> > the armhfp (hard floating point) repo in koji has 16761 binary rpms
> > in them and 12634 of those have been built in koji, which leaves us
> > with 4127 binary rpms coming from the stage4 repo.
> >
> >
> > this just means we had slightly more built in stage4 than moji. with
> > the last of the recent changes we are building faster than we ever
> > have, we also do not have all the builders up so we are looking to
> > be in good shape to follow primary arch into f17. biggest issue is
> > to get the gcc builds completed.
> >
> > Dennis
> >
> > [1] i got the numbers from
> > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=251177 which
> > was the most recent f15 repo when composing this email.
>
> the in koji numbers include the noarch only packages that we imported
> directly into koji.
some more data
[dennis@adria util (master)]$ koji latest-pkg --all --quiet dist-f15|wc -l
10721
[dennis@adria util (master)]$ arm-koji latest-pkg --all --quiet dist-f15|wc -l
7656
[dgilmore@hongkong scripts]$ rpm -qp --qf "%{buildhost}\n"
/mnt/koji/tree/releases/15/Everything/source/SRPMS/*rpm|grep
fedoraproject.org|wc -l
warning:
/mnt/koji/tree/releases/15/Everything/source/SRPMS/0x-0.3.9-5.fc15.src.rpm:
Header V3 RSA/SHA1 Signature, key ID 3ad31d0b: NOKEY
4485
so of the builds in arm koji 4485 were directly imported
10721-4485
6236
6236-3065
3171
3065 is the builds left to get parity with primary. so we have built
just over 50% of what we need to
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk8LszYACgkQkSxm47BaWfdqEgCgrmYSL11KbUTkghcNxxrEs51O
xs4AniSjfAZN74k1Qmxf7NwuFUpQQcx5
=JER2
-END PGP SIGNATURE-
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Small ARMv5 Update
El Tue, 17 Jan 2012 18:35:23 -0500
Jon Chiappetta escribió:
> Hey everyone,
>
>
> I brought up the 5-{1..5}, 6-{1..5} and 7-{1..5} machines as ARMv5
> builders. I condensed my mailing list stats email into one message.
> Jordan is working on bring the guru's up on F15.
> Max is working on bringing up more createrepo hosts.
>
>
> Let us know if you guys/gals need anything else done,
> Thanks for your time,
> Jon Chiappetta.
>
>
since we are not planning to build, follow or ship f16 perhaps we could
drop it from the status email.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] supported hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i think we need to come up with a list of supported hardware. something like https://wiki.linaro.org/Boards and http://www.linaro.org/low-cost-development-boards/ i think we should support the linaro boards if the make sense. in addition we should support raspberry pi and trimslice and of course the olpc XO. while we can not ship binary blobs etc for video. we should work to make the experience the best possible. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk8ayWMACgkQkSxm47BaWfeibQCgwGDRAhrfzm5/uuJwCNe6ydr5 Y20AoJGrzpxBqlfQTJRL7QrDUCP6Sw+w =h+w4 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Possible File Formats for a Fedora ARM release
El Thu, 02 Feb 2012 17:22:06 -0500
Jonathan Chiappetta escribió:
> I would like to discuss (or learn about previous discussions)
> regarding the file format for future possible fedora-arm releases. I
> believe we should have one file which should provide all the data
> necessary to make a final bootable fedora-arm device.
>
> Are there any suggestions on how the file should be laid out? For
> example:
>
> Fedora-20-ARMv5-Guru.tgz = { ARMv5.guru.boot.tgz ,
> Fedora-20-ARM.root.tgz } Fedora-20-ARMv5-Panda.tgz =
> { ARMv5.panda.boot.tgz , Fedora-20-ARM.root.tgz }
> Fedora-20-ARMv7-Panda.tgz = { ARMv7.panda.boot.tgz ,
> Fedora-20-ARM.root.tgz } ...
>
> The only problem I don't understand is that it doesn't seem to be as
> simple as just choosing a general ARMv5 kernel for an ARMv5 device as
> an ARMv5 Guru differs from a ARMv5 Smarttop which differs from an
> ARMv5 Panda, etc...
>
> I'm sure most of you have a better idea of how this should work but
> the user should only have to download one file at the end of the day
> right?
>
> Thanks,
> Jon.
>
>
I think that what we likely need to do is to ship something that is a
disk image. a sparsified file say 2 or 4g that we setup with MLO
installed first, a vfat first partition. and a / partition. that we
can just dd onto a sdcard. then extend the filesystem to the size of
the disk. this way things like a guruplug, panda etc just work.
for a trimslice we likely want to a anaconda install image that can be
booted and will run anaconda.
in the first case we should have a minimal install, XFCE, gnome, KDE,
LXDE, and SoaS at the least. anaconda can follow later. we could
always boot the live sdcards on a trimslice or a smartop/smartbook
where you have the possibility of running anaconda. as well as future
server class hardware. its something that needs o be on the road map.
but doesnt need to be now. Im not sure that we should ship just
tarballs of root filesystems. a card deployment tool could use qemu and
yum to install the right kernel for the system onto a sdcard. once we
have dd'ed on the drive.
What im getting at is we need to have a packaged format like a disk
image, something that is simple to deploy. isos do not really make any
sense for ARM, but we should have live images, install images, etc.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] f17 status
Hi all,
I ran Dan Horák's koji-compare.py script from
http://fedora.danny.cz/tmp/koji-compare.py against arm koji for f17 we
got at the end
statistics: {'older': 1979, 'local_only': 11, 'remote_only': 1428,
'same': 7873, 'newer': 37, 'total_missing_builds': 6014}
the older builds are things that we have an older build of, local_only
are arm only builds, remote_only are things we dont have built in arm
koji but are built on primary, same is where the nvr we have matches
primary, newer means our nvr is newer than primary, and the
total_missing_builds is the count of all builds missing which means if
there are 4 newer builds of libfoo on primary we count that 4 times.
Dennis
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] heavybuilders
Hey all, Id like to propose that we setup the heavybuilders to only be the trimslices. just because the local sata disk on the usb bus is faster than the shared scratch storage. packages build quicker on the trimslices since there is much less sontention to the storage and we do have enough of them. arm-koji list-hosts |grep trimslice cdot-trimslice-13-1 Y Y0.0/2.0 arm 2012-02-27 22:04:56 cdot-trimslice-14-1-v7hl Y N6.0/2.0 armhfp 2012-02-27 22:04:51 hsv-trimslice-10-v5tel N N0.0/2.0 arm - hsv-trimslice-10-v7hlY N6.0/2.0 armhfp 2012-02-27 22:05:01 hsv-trimslice-6-v5telY Y1.0/2.0 arm 2012-02-27 22:04:47 hsv-trimslice-6-v7hl N N0.0/2.0 armhfp - hsv-trimslice-7-v5telY Y1.5/2.0 arm 2012-02-27 22:04:55 hsv-trimslice-7-v7hl N N0.0/2.0 armhfp 2012-02-07 19:17:11 hsv-trimslice-8-v5telY N2.0/2.0 arm 2012-02-27 22:04:49 hsv-trimslice-8-v7hl N N0.0/2.0 armhfp 2012-02-06 18:12:49 hsv-trimslice-9-v5telN N0.0/2.0 arm - hsv-trimslice-9-v7hl Y N2.0/2.0 armhfp 2012-02-27 22:04:45 I wanted to get others thoughs before i went and made the change Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] heavybuilders cdot-pandas
El Mon, 27 Feb 2012 18:03:01 -0500
M Abed escribió:
> Does that mean that we will remove the following machines from the
> heavybuilder channel or leave those as is?
>
> cdot-panda-10-1-v7hl
> cdot-panda-10-4-v7hl
> cdot-panda-10-5
> cdot-panda-11-4-v7hl
> cdot-panda-12-3
> cdot-panda-5-3
> cdot-panda-5-4
It would mean they are no longer heavybuilders. we could then drop the
space thats allocated to them in the scratch pool to be smaller.
Dennis
> Masihul Max Abed
> Seneca CDOT
>
>
>
> On Mon, Feb 27, 2012 at 5:36 PM, Brendan Conoboy
> wrote:
>
> > On 02/27/2012 02:25 PM, Dennis Gilmore wrote:
> > [snip]
> >
> > I wanted to get others thoughs before i went and made the change
> >>
> >
> > Just to be clear, these two systems are the same machines:
> >
> > hsv-trimslice-9-v5telN N0.0/2.0 arm -
> > hsv-trimslice-9-v7hl Y N2.0/2.0 armhfp 2012-02-27
> > 22:04:45
> >
> > We just provision them as v5 or v7 according to what it looks like
> > is needed. That's the idea anyway- we aren't doing enough builds
> > at once that we've had to balance anything.
> >
> > FYI, the HSV pandas also have dedicated sata disks on them and are
> > roughly the performance equivalent of the trimslices because of
> > it. The actual tally of heavybuilders (defined as having dedicated
> > usb-sata storage) is:
> >
> > hsv-panda-1-v5tel
> > hsv-panda-2-v5tel
> > hsv-panda-3-v5tel
> > hsv-panda-5-v5tel
> > hsv-panda-6-v5tel
> > hsv-panda-8-v5tel
> > cdot-trimslice-13-1
> > cdot-trimslice-14-1-v7hl
> > hsv-trimslice-10-{v5tel,v7hl}
> > hsv-trimslice-9-{v5tel,v7hl}
> > hsv-trimslice-8-{v5tel,v7hl}
> > hsv-trimslice-7-{v5tel,v7hl}
> > hsv-trimslice-6-{v5tel,v7hl}
> >
> > We can make all the HSV trimslices into v7 builders and that will
> > give us a 6/6 split, which seems reasonable.
> >
> > --
> > Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
> >
> > __**_
> > arm mailing list
> > arm@lists.fedoraproject.org
> > https://admin.fedoraproject.**org/mailman/listinfo/arm<https://admin.fedoraproject.org/mailman/listinfo/arm>
> >
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] An alpha ARM full of Beefy Miracle (AKA Fedora 17 on ARM alpha 1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 01 Mar 2012 11:16:25 +0100 Thomas Meyer wrote: > > Zitat von Peter Robinson : > > > Now on the missing GUI interfaces and "your favourite desktop". > > We're working as quick as we can to get all the mainline packages > > built. I would ask if you please don't just go and build random > > packages in koji. We have scripts handling the build process to > > ensure it's built identical to Mainline Fedora so everything works > > as it should but this takes time. The quickest way to get these > > appearing for use if for you to fix broken packages [1] in mainline > > Fedora. If they don't compile there they certainly won't on ARM. > > These breakages block the build process of packages higher up the > > stack as the needed dependencies aren't there. Again please just > > don't go and compile random packages in koji. > > btw. where to report bugs in packages (like I did for > accountsservice here on this list)? The package did build fine in > mainline because I guess it where build before the usr-merge/move. > now it fails. if a package is FTBFS for resons like usrmove or not ported for gcc-4.7 or just does not compile then file in bugzilla with patches prefered. if its an issue that its just not building because we dont have the deps built yet you just need to be patient, of course if you are a fedora proven packager just fix it and build it on primary, then submit it as an update. > > That being said there's been a LOT of work done by a few people to > > get us to this point so I do hope you jump in and enjoy the ride :-D > > Thanks for all the hard work. > > with kind regards > thomas > Thanks for looking at some packages :) Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9PhuwACgkQkSxm47BaWfcAbACeP9GGTe0ESsGN8gh8rGNmztN3 GO4An3V02FiqALBXsqado0zdn8MIi9ny =xZJ/ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] PNAELV 6 clone-port - now with a faster mirror available
El Tue, 06 Mar 2012 11:50:58 + Gordan Bobic escribió: > If you were leeching it from ftp.redsleeve.org, please consider > resuming your downloads from the following server: please dont email this list about this, it is off topic for fedora Thanks Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] f17 status
El Sat, 18 Feb 2012 03:15:16 -0600
Dennis Gilmore escribió:
> Hi all,
>
> I ran Dan Horák's koji-compare.py script from
> http://fedora.danny.cz/tmp/koji-compare.py against arm koji for f17 we
> got at the end
> statistics: {'older': 1979, 'local_only': 11, 'remote_only': 1428,
> 'same': 7873, 'newer': 37, 'total_missing_builds': 6014}
statistics: {'older': 591, 'local_only': 5, 'remote_only': 1064,
'same': 9619, 'newer': 82, 'total_missing_builds': 1907}
reran the script this morning much closer than we were.
> the older builds are things that we have an older build of, local_only
> are arm only builds, remote_only are things we dont have built in arm
> koji but are built on primary, same is where the nvr we have matches
> primary, newer means our nvr is newer than primary, and the
> total_missing_builds is the count of all builds missing which means if
> there are 4 newer builds of libfoo on primary we count that 4 times.
>
> Dennis
> ___
> 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 and shipping of various binary firmware / boot bits
Yes. Without the code we can not boot the machines. While we could in theory build the bits. Vendors only support the compiled bits they ship. We would likely need to pull in patches from the different vendors trees. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Tom Callaway wrote: On 03/08/2012 10:16 AM, Peter Robinson wrote: > In some cases they do and we don't need to worry about it, in other > cases like the PandaBoard they're likely just being too tight to put a > flash chip on the board to hold the FW/BIOS so you have to have a > small partition at the beginning of the SD to hold it and the SoC > basically searches for a location that is set by pin combinations for > the SoC boot code off serial/mmc/usb, So, the existing firmware exception is tightly worded, it says: "The files must be necessary for the functionality of open source code being included in Fedora." I'm not sure this BIOS/FW code actually meets that criteria, can you make that case? ~tom == Fedora Project _ 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 and shipping of various binary firmware / boot bits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Mar 2012 13:12:39 -0500 Jon Masters wrote: > On 03/08/2012 01:07 PM, Jon Masters wrote: > > > Anyway. All this means that on ARM, in some cases (won't be true on > > servers), especially inexpensive dev boards, we become the > > distributor of the U-Boot bits if we want to ship whole SD Card > > images (which we think we do - otherwise installation on Panda or > > Pi becomes harder, on servers and other systems we'll do x86-like > > Anaconda and PXE later). I think we could build U-Boot ourselves, > > especially in the case of boards where we can't brick them just by > > having a bad build. Generally, I don't want to distribute "BIOS" > > code in the longer term beyond those cases where we need to shove > > something on an SD Card image by nature of the way that the cards > > boot. In other cases, I prefer we don't build or ship something, > > e.g. for U-Boot where it is shipped in flash on the board or in > > cases where we might be able to brick a board. > > So I can get behind (reluctantly) us building e.g. a uboot package > with subpackages for e.g. OMAP boards like Panda, Beagle, etc. and > then pulling in the result. Since we're constraining the number of > "whole disk" images we want to make (these are an installation > convenience) we can keep the set of U-Boot bits we actually build > fairly small. If someone has a funky board, then can put this stuff > together. Until we get to the future bigger ARM systems, where this > is a non-issue. > > Jon. while a bit ugly http://ausil.us/packages/x-loader-1-1.fc15.src.rpm http://ausil.us/packages/x-loader.spec and a binary compiled version http://ausil.us/packages/x-loader-1-1.fc15.armv7hl.rpm ive not yet tested that the built versions will actually load uboot to boot a system it builds and packages up the MLO x-load.bin x-load.bin.ift for the supported boards from the git tree at git://gitorious.org/x-loader/x-loader.git two of the boards failed to build. likely this will need a little work still and we probably only want to build the beagle and panda board versions since they are hardware we intend to support. But the raspberry pi is a different beast and will likely need the board to grant an exception. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9ZAS0ACgkQkSxm47BaWffSTgCdFAx2m39a7LuXJ+XxzRZrSPJ7 wIIAn3fH34QdJ/52QGg32qtKjjFlK9JS =VDOa -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 8 Mar 2012 12:57:44 -0600
Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 08 Mar 2012 13:12:39 -0500
> Jon Masters wrote:
>
> > On 03/08/2012 01:07 PM, Jon Masters wrote:
> >
> > > Anyway. All this means that on ARM, in some cases (won't be true
> > > on servers), especially inexpensive dev boards, we become the
> > > distributor of the U-Boot bits if we want to ship whole SD Card
> > > images (which we think we do - otherwise installation on Panda or
> > > Pi becomes harder, on servers and other systems we'll do x86-like
> > > Anaconda and PXE later). I think we could build U-Boot ourselves,
> > > especially in the case of boards where we can't brick them just by
> > > having a bad build. Generally, I don't want to distribute "BIOS"
> > > code in the longer term beyond those cases where we need to shove
> > > something on an SD Card image by nature of the way that the cards
> > > boot. In other cases, I prefer we don't build or ship something,
> > > e.g. for U-Boot where it is shipped in flash on the board or in
> > > cases where we might be able to brick a board.
> >
> > So I can get behind (reluctantly) us building e.g. a uboot package
> > with subpackages for e.g. OMAP boards like Panda, Beagle, etc. and
> > then pulling in the result. Since we're constraining the number of
> > "whole disk" images we want to make (these are an installation
> > convenience) we can keep the set of U-Boot bits we actually build
> > fairly small. If someone has a funky board, then can put this stuff
> > together. Until we get to the future bigger ARM systems, where this
> > is a non-issue.
> >
> > Jon.
>
> while a bit ugly
> http://ausil.us/packages/x-loader-1-1.fc15.src.rpm
> http://ausil.us/packages/x-loader.spec
>
> and a binary compiled version
> http://ausil.us/packages/x-loader-1-1.fc15.armv7hl.rpm
>
> ive not yet tested that the built versions will actually load uboot to
> boot a system
>
> it builds and packages up the MLO x-load.bin x-load.bin.ift for the
> supported boards from the git tree at
> git://gitorious.org/x-loader/x-loader.git
>
> two of the boards failed to build. likely this will need a little work
> still and we probably only want to build the beagle and panda board
> versions since they are hardware we intend to support.
>
> But the raspberry pi is a different beast and will likely need the
> board to grant an exception.
>
> Dennis
also a quick hack on the uboot-tools spec to have it just build a
panda board uboot
http://ausil.us/packages/uboot-panda-2011.03-1.fc18.src.rpm
http://ausil.us/packages/uboot-panda.spec
and a scratch build of it
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578299
realistically we only need to build uboot for the dev boards where they
cheaped out and did not install some kind of nvflash storage to boot
from
so in these packages i put everything into %{_datadir}/%{name}/
im envisioning then that the the compose tool would make a empty vfat
filesystem at the start of its rawdisk image that the deployment tool
can populate. so something like
Partition table on image:
msdos label
part 1: 256mb vfat at start of disk (created by compose tool but empty)
part 2: rest of 2gb space all packages get installed here, including
all the kernels we install
the deployment tool can then copy the right MLO if its needed sync it,
then copy u-boot.bin run mkimage on the kernel and intramfs, and write
out boot.scr onto the vfat partition, while many devices support ext3
for booting vfat is the most generic and universally supported. we
could even not format the boot partition that fstab would actually
mount at /boot/uboot/ then if the target device supports ext3 we could
use that instead and setup fstab appropriately there really is no need
for a separate /boot thats not going to be used for booting. if we
make a 2gb raw disk image, in essence its the same as a livecd but can
be dd'd onto a sdcard and just boot the filesystem can be resized to
use the whole of the card. we can sparsify it and ship it compressed.
mkimage can be run anywhere. and it doesnt need to mess with the rpmdb
on the image. we could setup something to set a flag and remove the
unused kernels from the image on firstboot. maybe also automatically
resize the / filesystem. or add swap to the end of the partition also.
i see this as a way we can ship something easily consumed that can be
supported by the dev boards, and other targets like the plugs where you
really dont want to or its not really feasable to run a t
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 8 Mar 2012 13:27:36 -0600 Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 8 Mar 2012 12:57:44 -0600 > Dennis Gilmore wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Thu, 08 Mar 2012 13:12:39 -0500 > > Jon Masters wrote: > > > > > On 03/08/2012 01:07 PM, Jon Masters wrote: > > > > > > > Anyway. All this means that on ARM, in some cases (won't be true > > > > on servers), especially inexpensive dev boards, we become the > > > > distributor of the U-Boot bits if we want to ship whole SD Card > > > > images (which we think we do - otherwise installation on Panda > > > > or Pi becomes harder, on servers and other systems we'll do > > > > x86-like Anaconda and PXE later). I think we could build U-Boot > > > > ourselves, especially in the case of boards where we can't > > > > brick them just by having a bad build. Generally, I don't want > > > > to distribute "BIOS" code in the longer term beyond those cases > > > > where we need to shove something on an SD Card image by nature > > > > of the way that the cards boot. In other cases, I prefer we > > > > don't build or ship something, e.g. for U-Boot where it is > > > > shipped in flash on the board or in cases where we might be > > > > able to brick a board. > > > > > > So I can get behind (reluctantly) us building e.g. a uboot package > > > with subpackages for e.g. OMAP boards like Panda, Beagle, etc. and > > > then pulling in the result. Since we're constraining the number of > > > "whole disk" images we want to make (these are an installation > > > convenience) we can keep the set of U-Boot bits we actually build > > > fairly small. If someone has a funky board, then can put this > > > stuff together. Until we get to the future bigger ARM systems, > > > where this is a non-issue. > > > > > > Jon. > > > > while a bit ugly > > http://ausil.us/packages/x-loader-1-1.fc15.src.rpm > > http://ausil.us/packages/x-loader.spec > > > > and a binary compiled version > > http://ausil.us/packages/x-loader-1-1.fc15.armv7hl.rpm > > > > ive not yet tested that the built versions will actually load uboot > > to boot a system > > > > it builds and packages up the MLO x-load.bin x-load.bin.ift for the > > supported boards from the git tree at > > git://gitorious.org/x-loader/x-loader.git > > > > two of the boards failed to build. likely this will need a little > > work still and we probably only want to build the beagle and panda > > board versions since they are hardware we intend to support. > > > > But the raspberry pi is a different beast and will likely need the > > board to grant an exception. > > > > Dennis > > also a quick hack on the uboot-tools spec to have it just build a > panda board uboot > > http://ausil.us/packages/uboot-panda-2011.03-1.fc18.src.rpm > http://ausil.us/packages/uboot-panda.spec > > and a scratch build of it > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578299 > to further follow up ive updated uboot to 2011.12 release from 2011.03 tools have been built on primary arches uboot-panda: http://ausil.us/packages/uboot-panda-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-panda.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578641 uboot-origen: http://ausil.us/packages/uboot-origen-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-origen.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578843 uboot-beagle: http://ausil.us/packages/uboot-beagle-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-beagle.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578937 Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9ZLDEACgkQkSxm47BaWfcY6wCdHOhCVgC4+yGiRK57oi7I7bxs VRUAnifZk+ITjHGAcJv7JuBiTlE0z1V4 =M8sj -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] rawhide report: 20120311 changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 11 Mar 2012 11:25:19 +0100
Mark Wielaard wrote:
> Hi,
>
> I noticed this "breakage" for systemtap-testsuite:
>
> On Sun, Mar 11, 2012 at 09:55:03AM +, ARM Rawhide Report wrote:
> > Compose started at Sun Mar 11 08:10:01 UTC 2012
> >
> > Broken deps for arm
> > --
> > ...
> > [systemtap]
> > systemtap-testsuite-1.6-4.fc17.armv5tel requires prelink
> > ...
> > Broken deps for armhfp
> > --
> > ...
> > [systemtap]
> > systemtap-testsuite-1.6-4.fc17.armv7hl requires prelink
>
> But this is an old package (17 Feb 2012):
> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=43459
> There is a newer version 1.7-4.fc17 (02 Mar 2012):
> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=57957
> which should have a fix for this issue (disable the prelink
> dependency temporarily for %arch{arm}).
>
> Is there anything that can/must be done to get the new package
> to be picked up?
systemtap-1.6-4.fc17 was tagged into f18 so it was overiding the newer
build in f17, ive untagged systemtap-1.6-4.fc17 from f18 and it will be
ok tomorrow
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk9coO8ACgkQkSxm47BaWfcc3gCfZEttQvgxo4STf6M89AHwWgu8
zP0AnAuX9cgWtjtjV6TZNufZhRhZEcrM
=pRc4
-END PGP SIGNATURE-
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [PATCH v2] add support for Highbank
El Mon, 12 Mar 2012 14:11:49 -0500
Mark Langsdorf escribió:
> Create a working config file for highbank and add highbank to the
> spec file.
>
> Signed-off-by: Mark Langsdorf
> ---
> Changes from v1
> Minimized config-arm-highbank to only new options
> Added highbank-export-clock-functions.patch
> Adjusted spec file to account for the added patch
>
> SOURCES/config-arm-highbank | 36
> - SOURCES/highbank-export-clock-functions.patch
> | 43 +
> SPECS/kernel.spec | 14 ++-- 3 files
> changed, 89 insertions(+), 4 deletions(-) create mode 100644
> SOURCES/highbank-export-clock-functions.patch
>
> diff --git a/SOURCES/config-arm-highbank b/SOURCES/config-arm-highbank
> index 18fc0c4..c20f104 100644
> --- a/SOURCES/config-arm-highbank
> +++ b/SOURCES/config-arm-highbank
> @@ -1,3 +1,37 @@
> -ONFIG_ARCH_HIGHBANK=y
> +CONFIG_ARCH_HIGHBANK=y
> +# CONFIG_ARM_LPAE is not set
> +# CONFIG_ARM_THUMBEE is not set
> +CONFIG_SWP_EMULATE=y
> +# CONFIG_CPU_BPREDICT_DISABLE is not set
> +# CONFIG_ARM_ERRATA_430973 is not set
> +# CONFIG_ARM_ERRATA_458693 is not set
> +# CONFIG_ARM_ERRATA_460075 is not set
> +# CONFIG_PL310_ERRATA_588369 is not set
> +# CONFIG_PL310_ERRATA_727915 is not set
> +# CONFIG_ARM_ERRATA_743622 is not set
> +# CONFIG_PL310_ERRATA_753970 is not set
> +# CONFIG_ARM_ERRATA_754322 is not set
> +# CONFIG_PL310_ERRATA_769419 is not set
> +
> +# CONFIG_THUMB2_KERNEL is not set
> +
> +CONFIG_ARM_TIMER_SP804=y
> +
> CONFIG_VFP=y
> +CONFIG_VFPv3=y
> CONFIG_NEON=y
> +
> +CONFIG_SATA_AHCI_PLATFORM=y
> +CONFIG_ATA_SFF=y
> +
> +CONFIG_ETHERNET=y
> +CONFIG_NET_VENDOR_BROADCOM=y
> +CONFIG_NET_CALXEDA_XGMAC=y
> +
> +CONFIG_GPIO_PL061=y
> +
> +CONFIG_SERIAL_AMBA_PL010=y
> +CONFIG_SERIAL_AMBA_PL010_CONSOLE=y
> +
> +# CONFIG_DVB_TDA1004X is not set
> +# CONFIG_DVB_PLL is not set
> diff --git a/SOURCES/highbank-export-clock-functions.patch
> b/SOURCES/highbank-export-clock-functions.patch new file mode 100644
> index 000..f66754d
> --- /dev/null
> +++ b/SOURCES/highbank-export-clock-functions.patch
> @@ -0,0 +1,43 @@
> +From 81a06eed2491273b7d6d274ae4be1d333c100ab0 Mon Sep 17 00:00:00
> 2001 +From: Mark Langsdorf
> +Date: Mon, 12 Mar 2012 06:28:19 -0400
> +Subject: [PATCH] highbank: export clock functions
> +
> +Signed-off-by: Mark Langsdorf
> +---
> + arch/arm/mach-highbank/clock.c |4
> + 1 files changed, 4 insertions(+), 0 deletions(-)
> +
> +diff --git diff -up
> linux-3.2-rc4.orig/arch/arm/mach-highbank/clock.c diff -up
> linux-3.2-rc4/arch/arm/mach-highbank/clock.c +index c25a2ae..cdbc575
> 100644 +--- a/arch/arm/mach-highbank/clock.c
> b/arch/arm/mach-highbank/clock.c +@@ -27,14 +27,17 @@ int
> clk_enable(struct clk *clk)
> + {
> + return 0;
> + }
> ++EXPORT_SYMBOL_GPL(clk_enable);
> +
> + void clk_disable(struct clk *clk)
> + {}
> ++EXPORT_SYMBOL_GPL(clk_disable);
> +
> + unsigned long clk_get_rate(struct clk *clk)
> + {
> + return clk->rate;
> + }
> ++EXPORT_SYMBOL_GPL(clk_get_rate);
> +
> + long clk_round_rate(struct clk *clk, unsigned long rate)
> + {
> +@@ -45,6 +48,7 @@ int clk_set_rate(struct clk *clk, unsigned long
> rate)
> + {
> + return 0;
> + }
> ++EXPORT_SYMBOL_GPL(clk_set_rate);
> +
> + static struct clk eclk = { .rate = 2 };
> + static struct clk pclk = { .rate = 15000 };
> +--
> +1.7.9.1
> +
> diff --git a/SPECS/kernel.spec b/SPECS/kernel.spec
> index e4ee511..486b7fb 100644
> --- a/SPECS/kernel.spec
> +++ b/SPECS/kernel.spec
> @@ -269,10 +269,8 @@ Summary: The Linux kernel
> %define with_tegra 0
> %define with_omap 0
> %define with_imx 0
> -%endif
> -
> -# disable highbank ARM kernels for the time being
> %define with_highbank 0
> +%endif
>
> # kernel-kirkwood is only built for armv5
> %ifnarch armv5tel
> @@ -747,6 +745,10 @@ Patch21000: arm-omap-dt-compat.patch
> Patch21001:
> arm-smsc-support-reading-mac-address-from-device-tree.patch
> Patch21004: arm-tegra-nvec-kconfig.patch
> +# highbank patches
> +# Highbank clock functions need to be EXPORT for module builds
> +Patch21010: highbank-export-clock-functions.patch
> +
> Patch21070: ext4-Support-check-none-nocheck-mount-options.patch
>
> Patch21092:
> udlfb-remove-sysfs-framebuffer-device-with-USB-disconnect.patch @@
> -1506,6 +1508,9 @@ ApplyPatch
> disable-threading-in-compression-for-hibernate.patch ApplyPatch
> unhandled-irqs-switch-to-polling.patch
> +#Highbank clock functions
> +ApplyPatch highbank-export-clock-functions.patch
> +
> # END OF PATCH APPLICATIONS
>
> %endif
> @@ -2377,6 +2382,9 @@ fi
> # ||w |
> # || ||
> %changelog
> +* Mon Mar 12 2012 Mark Langsdorf
> +- Re-enable highbank config option and add new config file to
> support it +
> * Wed Mar 07 2012 Dave Jones - 3.3.0-0.rc6.git2.2
> - Disable debugging options.
>
Ive applied this to both f17 and master branches
Dennis
__
Re: [fedora-arm] Visualizing Koji Builders
El Mon, 12 Mar 2012 23:14:37 -0400 Jonathan Chiappetta escribió: > So I've been on this mission to visualize stuff lately, I'm not sure > why... Anyway, I wrote another directed graph html5 canvas web script > to show which builders are currently building and what package it is. > The page ajaxes updates automatically and should add/remove > pkgs/hosts as they complete stuff. Anyway, I'm not sure if anyone > actually finds anything I make useful or not but here it is anyway... > > http://hongkong.proximity.on.ca/~jchiappetta/kojivis/kojivis.php > > Enjoy I guess, > Thanks, > > Jon Chiappetta Hey Jon, a nice addition would be to see the hosts checking in but not doing anything. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] changing kernel w/ uboot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Mar 2012 13:02:50 -0400 (EDT) Matthew Galgoci wrote: > > How does one change the kernel that uboot loads from mtdflash and > instead boots a kernel from an ext filesystem on an attached (uboot > supported) usb flash drive? Furthermore, is there a way to get uboot > to also load an initial ram file (disk or fs)? The hardware in > question is a guru plug and I've got the jtag and console adapter. > > Thanks in advance, > > Matt > on a guruplug you need to edit the values stored in nvram you can do it two ways, 1) interupting the boot process and using printenv setenv editenv saveenv to get set and save the variables. there is a utility in uboot-tools that should let you edit it from the running system Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9g59oACgkQkSxm47BaWfdvlACeMnvmiwWfACR9yMbq4XoUVRsH 0ZwAn1celPAoMjBftBLpNgs2abbR1S4v =i/5Z -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] changing kernel w/ uboot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Mar 2012 15:06:04 -0400 (EDT) Matthew Galgoci wrote: > > Date: Wed, 14 Mar 2012 19:49:18 +0100 > > From: Niels de Vos > > To: Matthew Galgoci > > Cc: arm@lists.fedoraproject.org > > Subject: Re: [fedora-arm] changing kernel w/ uboot > > > > On 14 Mar 2012 14:02, "Matthew Galgoci" wrote: > > > > > > > > > How does one change the kernel that uboot loads from mtdflash and > > > instead boots a kernel from an ext filesystem on an attached > > > (uboot supported) usb flash drive? Furthermore, is there a way to > > > get uboot to also load an initial ram file (disk or fs)? The > > > hardware in question is a guru plug and I've got the jtag and > > > console adapter. > > > > http://fedoraproject.org/wiki/Architectures/ARM/GuruPlug should > > probably be your starting point. > > That was an ok starting point, and actually one of the first > documents I had looked at. The problem with that guide is it doesn't > actually change the kernel, just the rootfs. > > Additionally, I've learned that the uboot that ships with the guruplug > is somewhat older and doesn't support reading files from ext > filesystems, just fat. > > This is similar to what I experienced: > > http://plugcomputer.org/plugforum/index.php?topic=1642.10;wap2 > > I was able to get uboot to see the partitions and filesystems on a usb > stick (though not the micro sd card in the onboard slot). Perhaps it > has something to do with the sd card being a 16G card. > > The issue I am at now is as follows: > > Marvell>> fatls usb 1:1 > 134819692 initrd-pae.img > 4134432 vmlinuz-pae > grub/ > 11049080 initramfs-3.3.0-0.rc4.git3.1.fc17.armv5tel.img > 3630488 vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv5tel > > 4 file(s), 1 dir(s) > > Marvell>> fatload usb 1:1 0x640 > Marvell>> vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv5tel 368 > reading vmlinuz-3.3.0-0.rc4.git3.1.fc17.armv5tel > > > 3630488 bytes read > Marvell>> bootm 0x640 > Wrong Image Format for bootm command > ERROR: can't get kernel image! > Marvell>> > > > Obviously the -PAE i686 kernels don't apply, I am not trying to load > one of those. > > Does anyone see anything patently wrong with what I did above? > > I suppose I could try using the stock uboot to load a newer uboot. > > Thanks, > > Matt > you have to run mkimage on the vmlinuz image for uboot to recognise it Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9g8YgACgkQkSxm47BaWfcRJACfXSPMNN4ZtcaiyjDPXeHlBd3P vzEAniDZG9TdYErIFLlhNZAa6TEAERWT =bA9O -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Diagnosing instruction set or EABI mismatch with proprietary binary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 16 Mar 2012 16:21:33 -0400 Martin Langhoff wrote: > Hi ARM list! > > I am working with Peter on putting the final touches on the OS that > goes on these 60K laptops [0]. The OS is based on F-14 armv5tel. Old, > I know, but we'll release a build of F17 mid-2012 to attune for our > outmoded ways :-) > > One of the side projects we have is to make Skype run on these > XO-1.75s, using SkypeKit [1] (they give you the runtime, and a > unixsockets API, you build the UI). The SDK contains 3 binaries: > ARMv5, ARMv6, ARMv7. > > So on F14-armv5tel, I am trying to run the ARMv5 binary. It starts up > and remains spinning. > > On a pre-alpha build of F17-armv7hl, the ARMv5 binary runs (buggy); > the ARMv7 binary spins doing nothing. > > I am still debugging this, but I strongly suspect an EABI or compiler > options mismatch. Is there any reasonable approach to test those two > theories? > > Thanks, and apologies for the off-topic post, What does readelf show about the objects. I suspect that they are not compiled for hardware floating point so for F17 you will need to either get hardware floating point versions or use a armv5tel build where they require skype does strace give anything useful? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9jskYACgkQkSxm47BaWfcL5ACfS//jbPLgm5ZjgddunKan8ixd 58QAnAwTKhYLoIHT6eMFt6//CrBVvTWW =yThe -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Soliciting Infrastructure feedback on Fedora ARM primary arch proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody. This Monday FESCo did an initial review of the ARM team's ARM PA Feature proposal. As part of that review, they requested we get in touch with affected groups including Infrastructure. What we need is to get feedback on what's been written and what still needs to be written as it pertains to Infrastructure. I know we have had some brief discussions already but id like to get everything together in one place to make sure we capture all of the requirements from infra, and that we have a workable, scalable, manageable solution. I do realise some of its a bit hard right now as we are not 100% sure how the hardware will look and work in practice. The feature page in question is: https://fedoraproject.org/wiki/Features/FedoraARM As you might have already ready on devel@, this is a work in progress and has some known deficits. We'll keep updating it based on the feedback we receive until we have a plan that works for all the stakeholders. If you have some feedback that you haven't already shared on devel@, or that you want to share again because it's really important and infra related please reply to this message and let us know. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9ra2oACgkQkSxm47BaWfeY9QCfRAahzvzOa10Z4nCwG0AuW77c j4gAoIYJ/N6bQPR3KEOfmAc8DeNjQwWa =dsfC -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Soliciting feedback on Fedora ARM primary arch proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 16:58:03 -0700 Brendan Conoboy wrote: > Hi everybody. > > This Monday FESCo did an initial review of the ARM team's ARM PA > Feature proposal. As part of that review, they requested we get in > touch with affected groups including releng. While Dennis Gilmore > has some specific plans in mind and was even involved in creating the > feature page, I'd like to solicit your (including Dennis) feedback on > what's been written and what still needs to be written as it pertains > to release engineering. > > The feature page in question is: > > https://fedoraproject.org/wiki/Features/FedoraARM > > As you might have already ready on fedora-devel, this is a work in > progress and has some known deficits (EG, That multiple-kernel > koji-flag thing is going away). We'll keep updating it based on the > feedback we receive until we have a plan that works for all the > stakeholders. If you have some feedback that you haven't already > shared on fedora-devel, or that you want to share again because it's > really important and releng related please reply to this message and > let us know. > > Thanks! > - From my point of view, we need to be able to take the same inputs, into the same tools and get the expected outputs. So for things like a livesdcard image we would feed the same spins kickastart into media-creator and get the raw disk image out, I really dont see us making a dvd install equivalant image. but i do see us making a boot.iso equivalant. as well as install trees for network installs. mash today does the right things. we need to be able to make the images in koji like we do on x86. we need a very clear definition of what releng will deliver for QA to test. Right now i think thats the biggest thing missing, today arm is producing repos and adhock creating root filesystems. the tooling to make a delievrable product needs to happen and we need to make sure we are very clear on what we are delivering and how we deliver it. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9rbxMACgkQkSxm47BaWfdS5QCfeQgO0yotJyK9GRBljjB9y/0W dpIAn07p46MKEzdxq07AztSRXl5bAKnH =wxno -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 Build Times For All Pkgs Built By Trimslices (x86 vs x64 vs sfp vs hfp)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Mar 2012 14:45:43 -0400 Jonathan Chiappetta wrote: > So I'm sorry if some of the columns are blank, I'm not sure why > some of the x86 and x64 columns are missing as they should have all > their logs. Maybe its my script and curl is failing somewhere? I'm > sorry about the formatting here but if there are is anyone out there > who was a data analyzer in a past life maybe someone could help > average out our total times vs theirs? Anyway, I'm sure someone might > find something useful in the data below assuming all my numbers are > correct... > > So here are the build times for various pkgs from our > cdot-trimslices: I think you would find it easier to write the script in python and use kojis api "koji list-api" gives the python info. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9rgzIACgkQkSxm47BaWfc4hQCbBtQLfXNYfuMeSpKJU/9Zt5Fr qh0AoJlYq6OhZvOdCRT/YLmpKsJmI6nS =n8T/ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Mar 2012 18:20:17 -0700 Brendan Conoboy wrote: > On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote: > > It's great that you're doing this, but I don't think dding > > partition + filesystems is a good idea. > > It's definitely tricky to get right. The number of possible > configurations makes it tricky to do an efficient selection of > images. I may end up doing a combination tegra+omap+etc image to cut > down the waste. > > > We found that various "8GB" SD cards have different absolute > > numbers of available sectors, it can lead to eventual filesystem > > corruption if your image is slightly large than someone else's card. > > Well, the image is being created out of a sparse file with 8000 > 1048576 byte sectors. If that proves too many it would be little > trouble to drop it down to 7900 or something. We'll see how it goes > in practice. i think we should only make the image 2 gb using domething like "dd if=/dev/zero of/raw/disk bs=1M count=2048" cound could be 2000 also then it should work everywhere. > > If someone's going to try this they're probably OK running fdisk and > > using tarballs. the idea is to get to a point where its simple to deploy lower the barrier of entry. > Yeah, the uboot enabled kernel tarball will probably be the most > universally useful. I personally had plenty of trouble marking > working uboot files so leveraging David Marlin's work on grubby will > hopefully spare others that trouble. Meanwhile, a number of people > have asked for images they can dd, so I'm trying to fulfill both > needs. > > > I've been using Peter's F17 alpha1 image and following progress with > > updates, it's been very good. It's stuck as of last week with > > gnome-shell problems though. But generally package completeness has > > been increasing really well last few weeks, great job. > > What are the gnome-shell problems? Perhaps they're well known but > I'm not acquainted with them. If we're missing a package that will > help things out let me know and I'll put it in the next snapshot. > there is gnome 3.4.0 in testing on primary now there is a change it will get pushed to stable for beta on monday if not its probably 2 weeks away. What we need to do is come up with a set of F17 beta deliverables and work really hard in the next 2 weeks to deliver a F17 Beta. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk93GjwACgkQkSxm47BaWffvhwCgg3VtFwVUF2FVBWPL0tMMA6Ik yJ4AoJEKuHTrJCBlyv7JZgGf5LAqYxWE =MCFP -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] yum repo for arm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 02 Apr 2012 19:39:15 +0400 Lubimov Alexey wrote: > 02.04.2012 19:18, Peter Robinson пишет: > > On Mon, Apr 2, 2012 at 4:15 PM, Lubimov > > Alexey wrote: > >> Is the way to install packages for arm via yum from fedora17? > > Yes, it's exactly the same as you would with mainline x86. The > > /etc/yum.repos.d works exactly the same as with primary arches. > > > > Peter > yes, but my question is right url for baseurl parameter. > > I can download rootfs from > (http://blc.fedorapeople.org/fedora-arm/f17/) and I can download > packages from Koji separately (for example, > http://arm.koji.fedoraproject.org/packages/mc/4.8.1/3.fc17/armv7hl/) , > but no repo for yum? ___ the repos as defined in fedora-release just work since they use https you do need to make sure that the system time is close to correct Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk95yncACgkQkSxm47BaWfcuOwCguqK8fPIS79nTYQ2HMHwH0UYt OJQAn0jlzs9HEc9uHFd7QkB6hGxPszcA =7DCV -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding The Koji Compare Script & Excl* Archs...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 19 Apr 2012 09:37:08 +0100
Peter Robinson wrote:
> On Thu, Apr 19, 2012 at 4:04 AM, Jon Chiappetta
> wrote:
> > So I missed the Fedora ARM meeting today because it's exam week and
> > I *should* be studying and Paul
> > notified me about displaying some stats about which packages are
> > not built yet because they are
> > exclusive or excluding the arm arch. I took the python based Koji
> > Compare script from here:
> >
> > http://fedora.danny.cz/tmp/koji-compare.py
> >
> > I added a simple function where in which you give it a koji session
> > object and a package ENVR name
> > and it will tell you if it's spec file has the arch excluded or
> > not. I'm not sure which packages should be
> > checked for example, I'm checking the ones in primary arch koji and
> > not our fedpkg.
> > My version of the script can be found here:
> >
> > http://142.204.133.82/jon/tmp/koji-compare.py
> >
> > I'm not sure where in the script yet if it checks for packages that
> > have been attempted for build but
> > have failed (I assumed that was in the case of "remote only" which
> > is where I put the arch check). Here's
> > an example of the output:
> >
> > statistics: {'older': 416, 'local_only': 4, 'remote_only': 85,
> > 'same': 10545, 'excluded_pkgs': 500, 'newer': 35,
> > 'total_missing_builds': 779}
>
> Those packages below might not yet be built on ARM but most of them
> definitely aren't ExcludeArch or ExclusiveArch packages.
>
> Peter
indeed
./srpm-exlcuded-arch.py -a "armv5tel armv7hl"
--path=/pub/fedora/linux/development/17/source/SRPMS/*/
acpid alleyoop amtu adobe-source-libraries apmd apmud aunit athcool berusky2
blktap bunny biosdevname cmospwd cmucl compat-gcc-296 coredumper cabal-dev
cpuid darktable dssi-vst dmidecode eclipse-changelog edac-utils edb efibootmgr
eclipse-cdt fedora-ksplice frysk firmware-addon-dell florist febootstrap
flashrom GtkAda ghc-ForSyDe ghc-hamlet ghc-parameterized-data ghc-type-level
ghdl gprbuild gnu-efi gnatcoll gpart gprolog gnome-boxes grub groonga i8kutils
ibmasm imvirt infiniband-diags ioport iprutils ipw2100-firmware
ipw2200-firmware java-1.7.0-openjdk ksplice latrace libbsr libipathverbs
librtas libsmbios lightning lrmi ltrace memtest86+ mactel-boot matreshka mcelog
maxima microcode_ctl mkbootdisk mono-debugger msr-tools nspluginwrapper numactl
numad openmpi openalchemist openni openni-primesense openscada pcc perftest
pvs-sbcl perl-threads-tbb picprog planets pmtools powerpc-utils
powerpc-utils-papr ppc64-utils ps3-utils q4wine qperf rubygem-virt-p2v srptools
s3switch syslinux sbcl semantik sgabios sks spicctrl spice spice-xpi
stripesnoop sugar-tamtam superiotool svgalib sysprof system-config-boot seabios
spice-gtk tbb tboot unetbootin v8 virt-v2v virt-what vrq wraplinux x86info xen
xorg-x11-drv-neomagic xorg-x11-drv-intel xorg-x11-drv-geode
xorg-x11-drv-openchrome xorg-x11-drv-vmmouse xorg-x11-drv-vmware yaboot
zeromq-ada
are the things in primary that are set to not build on arm,
and looking at that now we have built v8 java-1.7.0-openjdk
febootstrap the versions supporting arm were not in stable as of last
night
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk+QHksACgkQkSxm47BaWfdS7ACdGlllV9yM5yWYvVHSH/xKa7zs
jtcAnRxSspiJ8v99AvUBqML1ygx7E4v4
=+Bbc
-END PGP SIGNATURE-
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 11 May 2012 20:36:35 -0400 DJ Delorie wrote: > > > Right- followup question: Is Firefox what we want in the X images? > > What's the default browser for x86 ? xfce live image ships with firefox and midori. you should look at the spins-kickstarts package for what in the various live images. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+tuxcACgkQkSxm47BaWfe6VQCfdeYsWUlfUD+ClLGQDlJP0oKv eXwAoMB5Cjy0NnSMocWhtvjK/avAYDwy =9fh7 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Using livemedia-creator on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 16 May 2012 09:26:57 + (UTC) Jiri Kastner escribió: > On Mon, 14 May 2012 07:55:15 -0500, David A. Marlin wrote: > > > 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 > > hi, > what about to use spacewalk for kickstarting arm devices with > installer images, as kickstarting works without pxe when executed > rhn_check or automatically via rhnsd? maybe not all will be working > for first time. when spacewalk propperly supports arm it should be possible at some point down the road. spacewalk uses koan and cobbler for provisioning. they would need to have arm support. but that is different from making live images or fedora install media. there we will use the standard tools used to create fedora. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+zuTkACgkQkSxm47BaWfdphgCgoL3l3300WTRM/ziOFWgu1f1Y 3JEAoKNReYRFurq1eiiVAwE0zfgQMLDf =PANc -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] vexpress kernel config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 16 May 2012 23:01:08 +0100 "Richard W.M. Jones" escribió: > (That is, all virtio-* modules that can compile on ARM/vexpress.) > > Rich. > all the virtio modules are built. they get inherited from the generic kernel config. it just needs testing. it would be great to get things just working in libvirt/virt-manager took me a few hours today to do a "yum install totem" on the X image. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+0ZEQACgkQkSxm47BaWfc67gCfQ/iXJNXU461sQX115hnJtsnT eekAn0nIqffcpqVzHgMT7p50uTWWi3E6 =sF/c -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Unable to boot 3.3.6-3.fc17.armv5tel with qemu-system-arm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 May 2012 14:54:59 -0500 Alex Villacís Lasso wrote: > I am currently able to boot kernel-3.3.4-3.fc17.armv5tel with the > following qemu commandline: > > [palosanto@virthost fedora-17]$ KERNELVER=3.3.4-3.fc17.armv5tel > [palosanto@virthost > fedora-17]$ /home/palosanto/programa/qemu-build/arm-softmmu/qemu-system-arm > -nographic -m 256 -M versatilepb -kernel boot/vmlinuz-$KERNELVER > -initrd boot/initramfs-$KERNELVER.img -append "root=LABEL=rootfs > console=ttyAMA0 audit=0" -hda fedora-17-arm.vmdk > > If I just replace KERNELVER to 3.3.6-3.fc17.armv5tel , the boot > process just hangs. > > If I specify -M vexpress-a9, I can sort of boot the kernel. However > no block device matching the disk image appears anywhere, so the boot > process drops to an debug shell, like this: use -sd for your disk not -hda and you have to use -M vexpress-a9 so something like /home/palosanto/programa/qemu-build/arm-softmmu/qemu-system-arm - -nographic -m 256 -M versatilepb -kernel boot/vmlinuz-$KERNELVER - -initrd boot/initramfs-$KERNELVER.img -append "root=LABEL=rootfs console=ttyAMA0 audit=0" -sd fedora-17-arm.vmdk -M vexpress-a9 should work it does with the qemu binarries shipped in Fedora 17 Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+79AYACgkQkSxm47BaWfdzyACdGMdbFPAJuABsBxyUO9jjKeJN +RcAmwWNervHKZAcsuDdimDUJUnY/TA3 =PoN8 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Daily Koji Compare Stats
Right. I forgot to send out an email yesterday saying that I had pushed out the first lot of updates for fedora 17. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Peter Robinson wrote: Jon, Can we add f17-updates to this report? Peter On Mon, May 28, 2012 at 2:14 PM, wrote: > Mon May 28 09:05:01 EDT 2012 > > f17 : arm vs PA > > Same |Newer |Older |Local | Remote | > Missing | >_ >11107 | 19 | 85 |1 | 446 | > 213 | > > http://142.204.133.82/jon/koji/kc.17.diff.html > > > f18 : arm vs PA > > Same |Newer |Older |Local | Remote | > Missing | >_ >10711 | 12 | 676 |1 | 438 | > 1127 | > > http://142.204.133.82/jon/koji/kc.18.diff.html > > ARM Build Status Wiki: > https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide > > Mon May 28 09:14:14 EDT 2012 >_ > 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] TI Pandaboard ES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 29 May 2012 07:32:37 +0200 Michal Toman escribió: > 2012-05-28 23:59, Peter Robinson wrote: > > The release with the "issue" works fine, I'm using it on my > > PandaBoard ES. The issue is that we're having to ship a F-15 kernel > > because the F-17 kernel crashes on boot. I doubt either Debian or > > Ubuntu ship a 3.3 kernel yet. > > Actually the upstream kernel works. I was trying with a minimalistic > system (kernel 3.3 + busybox, both build from upstream sources) and > even the framebuffer seemed to work fine. which kernel driver? omapfb or omapdrm? in the fedora config the kernel doesnt boot though on a panda Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/EYP8ACgkQkSxm47BaWfc+fACfeY+ts3jyv9+ug+vf9HmOY7Xm ES0An1JvIJgByIpxVNkkESKq64Q9h1mX =efgB -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 30 May 2012 17:00:58 -0400 Rich Mattes escribió: > On Wed, May 30, 2012 at 2:52 PM, Paul Whalen > wrote: > > > We have built 96% of F17, with > > approximately 85 packages missing and 188 missing builds (this > > including many > > packages that have 1 or more builds in between what we have versus > > PA). Here is the full list: > > http://arm.koji.fedoraproject.org/status/f17-missing-2012-05-30.cgi > > > > > Is this an apples-to-apples comparison of packages between the arm > repositories and the f17 "fedora" repository? Or are you taking into > account packages that don't build for arm due to > exclusivearch/excludearch, and all of the packages that depend on > them? that list is packages that we have built on arm in the past but the current version on pa is not built on arm for some reason. there is another list http://arm.koji.fedoraproject.org/status/koji-missing-packages.cgi that are packages never built on arm. some of those are ExcludeArch/ExclusiveArch that is set to not build on arm Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/GmQoACgkQkSxm47BaWfcVkwCeJ/eI7f2sxdQjCQr70BmlCHsX HIsAnRg9fxdZCJrMHF/LP7wGOkOHCbJx =XyMC -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 30 May 2012 14:52:20 -0400 (EDT) Paul Whalen escribió: > Good day all, > > As many of you are aware we are not holding the Fedora ARM meeting > this week, but shall return to our regular time next Wednesday June > 6th. > > Congratulations to the primary architectures for their GA release of > Fedora 17 on May 29th. With the successful release of the Fedora 17 > Beta for ARM last week, its now time to turn our attention to the GA > release and what is currently blocking our progress. We have built > 96% of F17, with approximately 85 packages missing and 188 missing > builds (this including many packages that have 1 or more builds in > between what we have versus PA). Here is the full list: > http://arm.koji.fedoraproject.org/status/f17-missing-2012-05-30.cgi > > Work is still under way on the kernel for the Pandaboard, but all > other release criteria from our Alpha and Beta have been met. Please > take a moment to review the criteria for the final here: > http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Final_Release_Criteria > > Let's begin the discussion on the list - What do you foresee blocking > us from our final release of F17? As i see it for ga release we need to have the 85 older builds built at the same or newer nvr as primary. we need to have a working kernel on pandaboard, ideally that includes working omapdrm. all blocker bugs resolved and qa test matrices to be complete. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/GmhMACgkQkSxm47BaWfcKegCcCaK6kG1fkmSFiPsRjVAcHeOt KK0AoIMBv3jCsckw+JAlokjZDuQkpn6b =P9iD -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [PATCH] arm: fixes for Calxeda ECX-1000 from testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Jun 2012 08:25:29 -0500 Mark Langsdorf wrote: > This patch is intended for the fc17 3.3 kernel branch. Most of the > patches are in the process of being upstreamed. > > I'm preparing a separate patch for the fc18 3.4 kernel branch. > f17 is about to go to 3.4 likely today. and f18 is on 3.5 already Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/IyG4ACgkQkSxm47BaWfcFugCfe8R2F6k92FkTye8uubl7g9ei jBgAnRiC4Poo3ezgj8Jr4G5UbcEg6Of/ =N1B3 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Daily Koji Compare Stats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Sun, 10 Jun 2012 09:22:50 -0400
jon.chiappe...@senecacollege.ca escribió:
> Sun Jun 10 09:05:01 EDT 2012
> f17-updates : arm vs PA
>
> Same |Newer |Older |Local |
> Remote | Missing |
> --
> 11224 |9 | 115 |2 | 405
> | 196 |
>
> http://142.204.133.82/jon/koji/kc.17u.diff.html
please update koji-compare.py to the version from releng git as i asked
days ago on irc. this really does not give a true representation of the
status of f17 updates as its including ga in the as inheritance is
turned on.
statistics: {'older': 1, 'local_only': 0, 'remote_only': 99, 'same': 774,
'newer': 0, 'total_missing_builds': 1}
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk/Utn0ACgkQkSxm47BaWfdd3gCgo/dupXYwt0TDqMCk2LuhE8Na
pPwAoJdcx5sr1zeXalL1NxwizynhPiVc
=Xun+
-END PGP SIGNATURE-
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Nexus 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 3 Jul 2012 15:13:09 +0100 "Richard W.M. Jones" escribió: > > I know we don't support tablets. That's been pretty comprehensively > covered on the list already, eg: > > https://lists.fedoraproject.org/pipermail/arm/2012-April/003107.html > > But! Suddenly a tablet appears which is both much cheaper and (in > some respects) far more powerful than the Trim Slices and BeagleBoards > that we do support. > > Is it possible to support Tegra2/3 tablets, at least in a headless > configuration until there are graphics drivers? > > Rich. > It should be doable, aboot that android devices use is different to uboot. on my ac100 ive had troubles getting an initrd loaded. i get errors about the initramfs being corrupted. its also space constrained so you have to make a host specific initramfs to fit in the 8mb limits it places on kernel and initramfs. you could possibly also just use the android kernel though im not sure if that is sufficient. I know KDE has been working on a touch interface, pretty sure gnome has also. I do expect at some point soon we will see tablet spins show up for arm and x86. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/zAFAACgkQkSxm47BaWfcltACfbvpecXgyy3rjfEzyBbrWNwZN jhsAoLzUSQEfwdwErNc8OPzGrihqXzam =jdJH -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Raspberry Pi Fedora Remix 17 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jul 2012 09:53:48 +0200 "valent.turko...@gmail.com" wrote: > On Fri, Jul 6, 2012 at 5:40 PM, Chris Tyler wrote: > > A long-overdue update on the Raspi remix... > > Will Fedora Raspberry Pi have armhf "hard float" optimizations ? > From what I can see [1] RPi distribution that support these > optimizations have much better floating point performance. no it will be sfp only we build our armhfp rpms for armv7 which means they wont run on the raspberry pi as it is armv6 while armv6 has a floating point unit it is also not compatable. armv6 has a v2 vfp and armv7 has a v3 vfp. to build a compatable hfp distro we would need to recompile everything and have a 3rd set of base arches, its really not a very practical option. other than the pi the only other devices that are v6 are phones and the via APC. while i expect there will be quite a few pis out there its not likely to be a long term sustainable port. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/9fsYACgkQkSxm47BaWff7GgCgpRNOZyC1hMkw8Puk2dgOYwoE bekAoKMzHqbsX1642BwiIFalv4ZvlDm7 =oj8b -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] omap_hsmmc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 14 Jul 2012 09:32:17 +0100 Peter Robinson wrote: > On Sat, Jul 14, 2012 at 7:53 AM, Jon Masters > wrote: > > Folks, > > > > The latest F18 kernel is configured with CONFIG_MMC_OMAP_HS=m > > (which was previously configured as a builtin driver, as it > > probably should be). While in theory this would be working, it > > doesn't actually seem to result in dracut picking up the module as > > a necessary platform device. It is best fixed by building in the > > module again, which isn't happening because some other config > > option is forcing this to be modular too. I haven't tracked down > > what the other option was yet, feel free to help. > > > Interesting because the config bits don't appear to have changed: > > CONFIG_MMC_OMAP=m > CONFIG_MMC_OMAP_HS=y > > These two bits are the same on both kernels, maybe some more generic > config that's been moved around that's causing the regression. > > > In the interim, the following dracut config fileis a workaround: > > > > # /etc/dracut.conf.d/omap_hsmmc.conf > > # Dracut is not picking up the platform device driver for the HSMMC > > # interface > > > > add_drivers+="omap_hsmmc" > > So surely that's a bug in dracut that needs to detect that the module > is needed for booting. > > Peter Right this neeeds fixed in dracut. ill get patches sent in, and applied to fedora in the mean time Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlABca0ACgkQkSxm47BaWfdASQCgllRhk+M4MTYMC1E3kTP994HQ afkAmgKpuDIKPwojTxXbGrE3DcX+9sHf =X0ip -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] omap_hsmmc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 14 Jul 2012 23:52:17 -0400 Jon Masters wrote: > On 07/14/2012 09:18 AM, Dennis Gilmore wrote: > > > Right this neeeds fixed in dracut. ill get patches sent in, and > > applied to fedora in the mean time > > It might not be an issue with Dracut. Let's dig. If you want to fix > the config, go ahead. The issue is more likely that the alias > information isn't being matched up so Dracut never picks the modules. > But who knows. Let's find out. well if omap is supposed to pull in omap_hsmmc then its likely a kernel bug. but if what we really need to modprobe is omap_hsmmc and it is supposed to also pull in omap then its a dracut but. I added to dracut most of the kernel modules i thought we needed in the initramfs its quite likely some are missing. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlACP5UACgkQkSxm47BaWffgbACgnKrvodU52opNkDBs0cSiTU6y 7WkAoKpk1GpPbUq9PPs6Egj4MhlkuvpG =cJEP -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [PATCH] arm, highbank: working config options for fc18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 09 Aug 2012 09:48:56 -0500 Mark Langsdorf escribió: > commit f7d7563112f26c0fd464a965a9dfbbd6fd0793ca > Author: Mark Langsdorf > Date: Thu Aug 9 10:37:38 2012 -0400 > > highbank: working config options for fc18 > > Fedora 18 doesn't provides support for the PL011 serial console by > default. Enable it so that highbank systems can use their serial > console. > > Also, remove the config options for a bunch of unused and unusable > hardware in hopes of speeding up the build options. > > Signed-off-by: Mark Langsdorf > > diff --git a/config-arm-highbank b/config-arm-highbank > index 40b5e6c..6730d82 100644 > --- a/config-arm-highbank > +++ b/config-arm-highbank > @@ -30,9 +30,44 @@ CONFIG_GPIO_PL061=y > > CONFIG_SERIAL_AMBA_PL010=y > CONFIG_SERIAL_AMBA_PL010_CONSOLE=y > +CONFIG_SERIAL_AMBA_PL011=y > +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y I have enabled PL011 and disabled some of the options you had disabled but the patch wenta bit far to be applied wholesale. for one we do not build ext3 at all. we build ext4 with support for ext2 and ext3. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlAks2YACgkQkSxm47BaWfciMgCdEN4Gailt/hj/ez5VgPJbJgRF IhwAnj+TCc+T3Nhe3Ek9mbi9DMaA3/QN =J6oA -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] pandaboard video output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 27 Aug 2012 13:15:43 -0500 Jon escribió: > Hello. > > > Problem statement: > Fedora 17. > Updating to recent kernel on Pandaboard ES causes HDMI to stop > working. The known good setup is the stock panda-xfce image[1] on the > fedora-arm wiki [2]. > There are some kernel parameters to mess with the video output, HDMI > or DVI-D at omapedia [3], but those do not help. > Here is what I tried in /boot/uboot/uEnv.txt: > omapfb.mode=dvi:1280x1024MR-24@60 omapdss.def_disp=dvi we use omapdrm not omapfb so none of those options will have any effect. its all auto detected and auto setup. if the edid data is not read from the monitor you will get 1024x768 only. ive not tried the 3.5 based kernels as im not at home where i have access to a monitor. you shouldn't use the xpfa repo there is no need Fedora 17 will update and work just fine with whats in Fedora 17. you could try switching which port you plug the monitor into. you would also need to look at the output of dmesg to see what is happening. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlA8BLwACgkQkSxm47BaWfejqwCZARrdqnivX0js+HPOwSTXxMSR f54An1l5tDa1Nxp7wCpsQODIodgrMGhJ =Xj1r -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] pandaboard video output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 27 Aug 2012 20:35:06 -0500 Jon escribió: > >> Here is what I tried in /boot/uboot/uEnv.txt: > >> omapfb.mode=dvi:1280x1024MR-24@60 omapdss.def_disp=dvi > > > > we use omapdrm not omapfb so none of those options will have any > > effect. its all auto detected and auto setup. if the edid data is > > not read from the monitor you will get 1024x768 only. ive not tried > > the 3.5 based kernels as im not at home where i have access to a > > monitor. > > > Thanks Dennis. > > The information about omapdrm was good, gave something to > troubleshoot. > > > On the working (3.4.2-3) kernel, you can do this: > > # cd /sys/devices/platform/omapdrm.0/drm/card0/card0-HDMI-A-1/ > > # cat modes > 1024x768 > 800x600 > 848x480 > 640x480 > > > > On the latest kernel 3.5.2-3 that sysfs path does not exist. :( > So I guess the omapdrm driver is not happy. > > The output of lsmod does not have as much stuff as the 3.4.2-3 kernel > had. > > > Here I tried to load omapdrm module: > > # > insmod > /lib/modules/3.5.2-3.fc17.armv7hl.omap/kernel/drivers/staging/omapdrm/omapdrm.ko > Error: could not insert > module > /lib/modules/3.5.2-3.fc17.armv7hl.omap/kernel/drivers/staging/omapdrm/omapdrm.ko: > Unknown symbol in module you should just do "modprobe omapdrm" not insmod the .ko as it takes care of its deps. do a lsinitrd on the initramfs file in /boot and make sure that it has the omapdrm module in it. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlA8LCkACgkQkSxm47BaWfdf8wCgpiDNySKePw33HWjNPk+5HQBr d2AAoIhCKIOR0FCSS+xHQpb5I0uNuDrO =Z3wq -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora ARM weekly status meeting minutes - 2012-09-12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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-09-12/fedora-arm.2012-09-12-20.05.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-09-12/fedora-arm.2012-09-12-20.05.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-09-12/fedora-arm.2012-09-12-20.05.log.html Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBQ+c8ACgkQkSxm47BaWfci5ACfRpv98DjtUnWjuJo9dt1rgYuu UQcAmQHSmlB8YPNHf1AaqGCjrDHS0B4W =wzLt -END PGP SIGNATURE- ___ 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!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 13 Sep 2012 19:43:08 -0700 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/ > > 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 you should just use setenv bootargs console=ttyS0,115200n8 ro root=/dev/sda2 rootwait Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBSus0ACgkQkSxm47BaWfcQFwCfRP45xt8xy8Ap2LD9ngIAgaJu 30sAn3EqchAjHZ2EyI3dw3nJckuxZNce =GsHt -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 9 Oct 2012 08:54:26 +0100 Peter Robinson escribió: > On Mon, Oct 8, 2012 at 10:56 PM, Till Maas > wrote: > > On Mon, Oct 08, 2012 at 02:53:45PM -0400, Scott Sullivan wrote: > >> On 10/08/2012 02:35 PM, Till Maas wrote: > >> >Hi, > >> > > >> >On Sat, Oct 06, 2012 at 05:43:33AM -0400, Jon Masters wrote: > >> > > >> >>I'm interested to know who is using Kirkwood, and who would miss > >> >>it if it went away. 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. > >> > > >> >I bought several Kirkwood devices with the expectation to run > >> >Fedora on them and would like to test it at least on a Seagate > >> >Dockstar, but the little instructions and installer support > >> >always scared me away. > >> > >> Till, > >> > >> I've recently updated the Fedora install instructions for the > >> Pogoplug with is in the same family of devices and leverages the > >> same uboot update process that dockstar does. > >> > >> https://fedoraproject.org/wiki/Architectures/ARM/PogoplugUSBDisk > >> > >> As long as uboot is configured correctly, the process is as simple > >> as dd the image to a USB drive. > >> > >> > > >> >It also includes instructions to update the boot loader and > >> >supports installing on USB, SD card and eSATA. The Fedora > >> >instructions only mention to dd an image on a SD card on the > >> >other hand. > >> > >> You'll note that it's not Debian directly providing that support or > >> information. It's the Debian community and specifically one user. > > > > It is at least the documentation that is directly linked at > > http://www.debian.org/ports/arm/ > > > >> The same goes for Fedora, because of the man power requirements it > >> is up to the community to support re-used consumer appliances like > >> the Dockstar/Pogoplug. If you are successful in getting Fedora on > >> your Dockstar, we would greatly appreciate a contribution of your > >> experience and instructions on the wiki. > > > > It seems that the disk image boots on the dockstar, but a first "yum > > update" got oom-killed and there seems to be no swap and not LVM on > > the image to easily change this. IMHO a problem with the Fedora ARM > > documentation is, that it is only a collection of reports from > > people how they did it. It is lacking information about why > > something was done as described or how it should be done. For > > example the Debian documentation clearly states which uboot version > > is required and how to update it. The Kirkwood documentation in the > > Fedora ARM wiki only says that the proper uboot config depends on > > the uboot version and gives an example that is supposed to work on > > a Guru Plug Server Plus. Comparing it with the Debian documentation > > it also shows that different hex values (addresses?) are used in > > the uboot config for the kernel and initramfs. But why do they need > > to be different? Or do they not need to be different? Also as far > > as I can see there are no instructions about how the images are > > created and why they have been chosen the way they are (no LVM, no > > swap, device dependent names for kernel and initramfs, vfat > > for /boot). not that it will explain everything but Debian ships uboot for the kirkwood devices and add features not found in the stock uboot. ext2 support being one of them which is why /boot is vfat we support the stock uboot and only ship uboot where we have to preferring instead that the vendors be responsible for supporting and supplying uboot binaries. we are still evolving the image creation process. in f17 it was a shell script that used yum. we are moving to use kickstarts and anaconda via livemedia-creator > Well you could always step up to help improve that documentation > rather than complain ;-) > > > From my outsider POV the ARM SIG looks not very organised which > > makes it also hard to help now and then. For example I would more > > or less reduce the wiki install contents to the difference to the > > shown Debian documentation to avoid duplicate content and trust > > that they chose sane values, for example for the uboot version and > > the uboot config. But then it is unclear whether Fedora needs a > > different uboot config. > > It's not so much a lack of organisation but rather a lack of people to > do things. There's about 6 of us that do things regularly and between > us we might make up the equivalent of 1.5 full time people. > > Those of us that are actively working on it are having a hard time > just keeping
Re: [fedora-arm] Who's using Kirkwood?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 12 Oct 2012 09:40:13 +0100 Gordan Bobic wrote: > On 10/11/2012 08:03 PM, Brendan Conoboy wrote: > > On 10/11/2012 03:10 AM, Gordan Bobic wrote: > >> Just out of interest, which packages are you referring to? I am > >> assuming it is LibreOffice + a small subset of whatever is in > >> Fedora that isn't in EL; mainly because I had no RAM/swap/CPU > >> issues building any the 2000 or so packages that overlap. Takes > >> about 3-4 weeks on a _single_ SheevaPlug. > > > > You're building 2000 packages, we're building 12000. Libreoffice is > > definitely one one of the problem packages where an armv7hl builder > > is called for. > > I readily admit that the build time of a week is excessive. > > > The koji server has a special 'heavybuilder' group which > > handles such packages. Are you using USB storage on your > > sheevaplug? It surprises me that you can get through even 2000 in 3 > > weeks unless half of them are noarch ;-) > > I use iSCSI (ext4 build area on one of the hosts for the packages > that fail self-tests on NFS) and NFS (for everything else) backed by > a reasonably beefy storage box. NFS is not sufficient. it does not support file capabilites. using recent operating systems you are unable to init a chroot onto nfs since glibc and many other core os components switched over to using file capabilits. but this chatter is all off topic on the fedora arm list. Gordon I am considering moderating your posts to this list. they have all been off topic to the list, which is Fedora ARM. there are other lists to talk about your own agenda. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlB38j0ACgkQkSxm47BaWfcYPwCfRqwTyl7lGkZO9eOlGkUNrGaD mDYAoLWpqmtWF2MWLSLkcppz6P31l8fV =VVsn -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] selinux issue on new images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 17 Oct 2012 00:14:24 -0500 "David A. Marlin" escribió: > > I've been building test images for ARM systems and have hit an issue. > > I created an image for Trim Slice today, and it failed to let me log > in. The error was: > > -- root: no shell: Permission denied > > I checked and the image had: > > SELINUX=enforcing > SELINUXTYPE=targeted > > This surprised me because in the kickstart I explicitly select: > > selinux --permissive > > and in the anaconda program log I see: > > INFO program: Running... /usr/sbin/lokkit --selinux=permissive > > but on the final image selinux is set to enforcing. I don't know > what is changing the setting. > > Oddly enough, images I created last week did not exhibit this > behavior. The final image had: > > SELINUX=permissive > SELINUXTYPE=targeted > > just as the kickstart file specified. > > I assume that some package has changed in the F18 development repos > since last week to cause this, but I have no idea which package. > > Does anyone have suggestions for tracking down this issue? > > Note: If I force a 'relabel' on the root file system and reboot, the > login works even with SELinux set to enforcing, but that does not > explain why the settings in the kickstart are not being honored. Fedora images are to have selinux enforcing. thats what really should be tested. likely its anaconda thats setting it to enforcing. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlB+Ud8ACgkQkSxm47BaWfe4QwCfe52ZdNyJr4OaKCoO7HOxav+t RYYAoIeP1fOtROkPyUg3EBa+5mAABvkD =jny+ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] fedora-arm selinux question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Silly phone not responding to the list El Thu, 08 Nov 2012 19:16:31 +1000 Dennis Gilmore escribió: > I suspect that its an issue with livemedia-creator not running > setfiles so the selinux contexts are not set at all. Booting in > permissive mode relabeling and enabling selinux will probably have it > all working as expected > > Jon wrote: > > >Hello Dan, > > > > > >I'm told you would be able to assist with our selinux issue with ARM > >arch? > > > > > >Here is an fpaste of the bootup: > >http://fpaste.org/n7xX/ > > > > > >One of the ill effects is that NetworkManager.service does not > >work during the boot sequence. Afterward NM works with a restart, so > >perhaps some context is wrong, or some race condition. Jon Masters > >was speculating that perhaps the way systemd starts things with the > >wrong context on the service, or something similar. > > > > > >The environment is a pandaboard ES (omap 3.6 kernel) running F18 > >alpha. > > > >Hopefully the above paste will provide a clue that help get us going > >in the > >right direction. > >If you desire we can provide you access to a pandaboard if that would > >be > >helpful? > > > >Any attention you can spare for this would be very appreciated! > > > > > >Thanks in advance > > > >-Jon Disnard > > > > > >irc: masta > >fas: parasense > > > > > > > > > >___ > >arm mailing list > >arm@lists.fedoraproject.org > >https://admin.fedoraproject.org/mailman/listinfo/arm > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCcS/IACgkQkSxm47BaWfdxjwCglJ8d14liuSBeYtrcJRJVZSYz LhQAoLHTxbOXCW6OqOnVD+3dthjg8BMO =rYpd -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Pandaboard ES Omap4460
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 1 Dec 2012 15:21:30 -0500 Nigel Sollars wrote: > Hi all, > > Ive installed the fc17 arm distro for my Pandaboard. Ive been using > a self built buildroot/kernel uboot combo on a different SD card. does it work using the fedora built kernel and uboot? there should be no need to self build either. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlC8uBoACgkQkSxm47BaWfcsZwCfefjhKapT/jnua0rv7c8T4yxc k8cAn0VJlFMJeDwnC5G1Ng7LyDOAa3Qp =EuiV -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Soft-float chroot on hard-float distro and vice versa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Dec 2012 10:10:08 + Gordan Bobic wrote: > Hi, > > I've been trying to google this and I haven't been able to find a > definitive answer on the subject. I seem to recall a discussion on > this list a while back, with the general conclusion being that this > is problematic, but my googling threw up a few pages about Debian > implying that it could be made to work. > > Has anybody got any words of wisdom on this subject they might care > to share? I am mainly interested in this from the point of view of > running a Fedora chroot under Android with VNC on loopback on a Nexus > 10. It is doable and works fine. we have setup rpm and yum to disallow it to ensure that people do not accidently install sfp and hfp into the same system because we do not support multilib with hfp and sfp. its more a case of trying to make sure people dont shoot themselves in the foot. if your setting up a chroot on android you should grab a rootfs tarball and away you go. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDMmlQACgkQkSxm47BaWfcXCACeNfxexiSoZiMy8WiSDdwEBMfk L+4AoMMrDWRk9ylAnhFggLez9oGitSRj =IfLB -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 beta images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Dec 2012 12:39:39 -0600 David Marlin wrote: > > Dennis: > > I have made new F18 Beta Test Candidate (TC3) images using the kernel > you built (3.6.10-6.fc18). Thank you for expediting that build. > > I have also made an install tree for testing Highbank locally. When > Beta goes out, do we have a means of providing an install tree > publicly so others can use/test Highbank? We will need to have a Fedora/ tree for the highbank install images, to make that correctly we need to use pungi not lorax directly, but there is not yet support in pungi for arm. im working on a pungi update today, I will try add arm support. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDTNZIACgkQkSxm47BaWfdhCACgg9wWlvyOSzKWwBbkP1EWkQ4d bE4AoJbg6o/kfjMEa6ouZi6sMRPLAMQx =B7qg -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [AArch64] Stage2 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 11 Jan 2013 17:23:29 -0500 Mark Salter escribió: > This week was a step back from building stage2 packages so that effort > could be focused on some of the problems encountered. Primarily, the > issue with rpm hanging in libfreebl3 was tracked down to glibc. The > aarch64 patch we were using in the glibc package had an issue with > syscall return value handling in the wrapper macros. So I updated it > with aarch64 bits from the upstream glibc tree and that problem was > solved. With the new glibc, some stability/correctness issues in bash > went away as well as the need for using rpath hacks in some package > builds. > > So with glibc being updated and those problems being solved, I decided > to clean out the workarounds for the buggy glibc we were using and > rebuild everything using the updated glibc. > > Part of this rebuild also involves a change to the busybox config. In > the current stage2 rootfs, busybox is providing /bin/sh (ash) and also > overriding a lot of utilities (sed, awk, etc) also built in stage1. So > I changed the busybox config so that it doesn't step on utilities we > are building from other sources, including bash. This eliminates the > need for the makefile hacks in glib2 and other packages with complex > automake recipes. > > With all of those changes in, I currently have a build running through > stage2 packages. I expect it to run through the weekend and hopefully > be finished with stage2 early next week. If all goes well, we'll get > the wiki and git tree updated and move on to stage3. Lets make sure we get patches into fedora packages before we get a new gcc in rawhide and end up with a mass rebuild. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlDw3PUACgkQkSxm47BaWfdxgACgmq3Wwn+js+TWb87/EMibbDhz r30AoIR5+KPLJEU4gAEnneJZC0AgBmMe =coHi -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [AArch64] Stage2 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 14 Jan 2013 11:16:11 -0500 Mark Salter escribió: > On Fri, 2013-01-11 at 21:48 -0600, Dennis Gilmore wrote: > > Lets make sure we get patches into fedora packages before we get a > > new gcc in rawhide and end up with a mass rebuild. > > > > The upstream gcc 3.8 release should have aarch64 support in it. So I > don't know that there will be any patches needed. Rawhide binutils > builds and seems to work ok without patches. > > In any case, until we get to the point of building aarch64 packages in > koji, we have rebuilds in our future no matter what. Please dont reply all, I get the mail via the list there is no need to CC me on it as well. biggest patches that we will need afaik are autoconf/automake files. we also need to make sure redhat-rpm-config and rpm have support. there is a lot more that just glibc/gcc/binutils that will beed patching. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD0PoMACgkQkSxm47BaWfenRwCcDLlAtFh4a4LSXNJHw9Gr/VYV Yp0An3G7BGegB5tSJOtJ8LrI/C7yaRLE =Lt8p -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [AArch64] Stage2 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 14 Jan 2013 12:41:14 -0500 (EST) Nicolas Pitre escribió: > On Mon, 14 Jan 2013, Dennis Gilmore wrote: > > > Please dont reply all, I get the mail via the list there is no need > > to CC me on it as well. > > It is part of the netiquette to always CC the person being replied to. > Common wisdom is to do local filtering of duplicates at your end if > they are a problem for you. > > > Nicolas thanks for being really rude and disrespectful. it breaks my filtering since i dont get the mail from the list server but rather directly. It is not at all the common netiquette that is in use on fedora lists where you just reply to list. Maybe in other communities its considered normal. but I for one find it offensive especially when i ask please don't do this and someone does exactly that. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD0WFQACgkQkSxm47BaWffgxwCgoM/0BPo+eMjDQa+XPeanNMhb q2wAni0gUwuLx1Dxw7g3BexFkUiTy3R7 =xnBJ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 22 Jan 2013 14:15:57 -0600 Jon escribió: > On Tue, Jan 22, 2013 at 1:51 PM, Paul Whalen > wrote: > > > > > Summary of discussion from #fedora-arm > > ------ > > > > Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 > > kernel, using 'make dtb' during the kernel build. > > > > The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 > > release. We will > > only be including the DTB's where needed, for Trimslice and > > vexpress which do not > > boot without a DTB. The Pandaboard will boot the 3.7 without use of > > a DTB, and Highbank > > provides it's own. > > > > For a full summary of the testing: > > > > https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.7.3-201.jcm1.fc18 > > > > Paul > > ___ > > arm mailing list > > arm@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/arm > > > > > I get DTB working on the panda by the following code: > > # wget http://ausil.us/dtb/omap4-panda.dtb -o /root/omap4-panda.dtb > > # > cat /boot/vmlinuz-3.6.10-6.fc18.armv7hl.omap /root/omap4-panda.dtb > > /root/foo.zimg > > # mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e > 0x80008000 -n "3.6.10-6-DTB" -d /root/foo.zimg /boot/uboot/uImage-dtb > > # rm -i /root/foo.zimg > > # sed -i -e 's|\(uImage\)|\1-dtb|s' /boot/uboot/uEnv.txt > > That makes an appended DTB style kernel image, and results in > /proc/device-tree > > appending the dtb seems to work fine for a pandaboard, i've never personally had a pandaboard boot when loading the dtb separately Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD+/KAACgkQkSxm47BaWffdIACeMwMqcgH55FeGACEllmJVq66w IdAAn0TzGyXXQOQB78CrL3LxqQFhEwH9 =Myby -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] arm software floating point support going forward
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. Dennis ___ 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 Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore 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. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEHT3AACgkQkSxm47BaWfdmPQCgrZULnBQfG7q+Q9pGqp08sVc0 ohUAoLfMLjzs9ldxxyCBim88zEYKSY/R =SL8q -END PGP SIGNATURE- ___ 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 escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > El Fri, 25 Jan 2013 10:22:23 -0600 > Dennis Gilmore 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] arm software floating point support going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Jan 2013 16:13:33 -0600 Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > El Mon, 28 Jan 2013 22:26:19 -0600 > Dennis Gilmore escribió: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > El Fri, 25 Jan 2013 10:22:23 -0600 > > Dennis Gilmore 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 now that we have had a hfp only compose ive disabled building armv5tel rpms in koji for f19 Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEJM9wACgkQkSxm47BaWfdWPQCgupoHyYZ6lQH78Ak31qdiLyFG 6wAAoLM4Gnzx/+yyNkwWgPiYJMhwzR0S =heWZ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Mirrorlist Broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 20 Feb 2013 17:36:45 -0600 Jim Smythe escribió: > having a problem with the mirror list: http://pastebin.com/xB445V3z > has been in our /etc/yum.repos.d for 1 year and functional > > today I started getting the error http://pastebin.com/hgNNxjA3 > > Any idea why this seems to have broken after the build transition? That is a legacy function that seneca ran to support what was done when marvell was active in developing fedora arm. none of those releases have been supported in 2 years. Please upgrade to a supported release. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEl4MQACgkQkSxm47BaWffWEACbBgmiC0SY1448WIGqsfa5FYBe XYQAniPk4t+1Q/FYY4A4PMeZaUDAW5DQ =P1lv -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] supporting boot configuration for 32 bit arm
after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them. Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb. platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file. so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere. I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up. this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] supporting boot configuration for 32 bit arm
** Resending with the right lists ** after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them. Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb. platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file. so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere. I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up. this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Patching aarch64 support into Fedora
On Mon, 04 Mar 2013 19:44:16 -0800 Brendan Conoboy wrote: > Hi everybody, > > Fedora 19 has many of the enablers for native aarch64 in core > packages such as glibc and gcc. Many more packages would compile if > config.guess and config.sub recognized aarch64 as a valid > architecture, but only the latest version of autoconf knows about > aarch64. At last week's fedora-arm meeting we talked about the > viability of automatically patching such packages. The outcome of > that discussion was that we should first identify how many packages > need such a patch, then decide what to do based on that number. > > Red Hat's Al Stone has written a script which automatically generates > patches for each package that needs it (And updates its spec file). > After a complete run we can say that ~1850 packages need such a > patch. The number may be larger, but it is definitely not smaller, as > his only considers autoconf-using packages. If another auto > configuration system is in use by a number of packages it too many > need updating (cmake?). Now that we have this number, what do we want > to do? > > I see a few options: > > 1. Do nothing, trip over this issue at least 1850 times during > bootstrap. > > 2. Mail all package owners asking for action. > > 3. Proven packager commits the patches, package owners take them out > once unnecessary. > > 4. Run autoconf during build, incurring wrath of any packager whose > package isn't compatible with the latest autoconf. > > 5. Your much more sensible idea goes here. > > What say you? > I say we need the list of packages effected. then we can evaluate how critical it is that we take action. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Patching aarch64 support into Fedora
On Mar 6, 2013, at 12:11 PM, Brendan Conoboy wrote: > On 03/06/2013 06:37 AM, Dennis Gilmore wrote: >> I say we need the list of packages effected. then we can evaluate how >> critical it is that we take action. > > Here is the initial list: > > http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs > > I think it may actually be much larger. Al and I are going back and forth on > fixing up patchify to identify more cases. Talking with the X guys they run autoreconf in %build so all of their packages are false positives. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] can't init fedora-18-arm mock buildroot from armhfp device?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 Apr 2013 15:54:20 -0400 Adam Goode wrote: > with mock-1.1.30-1.fc18.noarch > > I am running this command: > > mock -v --target=arm -r fedora-18-arm init > > > But it fails. armhfp works fine. I can't figure out what is possibly > going wrong. > you can not mix and match hard and soft floating point so rpm wont allow you to install sfp rpms on a hfp system so you cant init a softfp chroot. its plain not a supported thing. you will need to use a softfp image to build softfp Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlF4dUQACgkQkSxm47BaWfcewQCeN+hgAdbm6lR/bMPlNxSijISV kq4AoIoMQ/9/Hz8aa111FJPjz8HVyUTe =9aHA -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Heads up armv5tel users: testing required for 3.9 kernel rebase for F-18/F-17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 8 May 2013 17:10:59 +0100 Peter Robinson wrote: > Hi All, > > With the 3.9 kernel out and 3.9.1 in rc the stable Fedora releases > will be rebasing to 3.9 shortly. > > For armv7 the kernel isn't in bad shape but v5 has had little testing. > I've done a scratch build to enable testing below, armv5tel users > please test. > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1789406 Installed on my guruplug, its booted and seems ok so far, dmesg doesnt show anything to worry about for me. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGKjckACgkQkSxm47BaWffkzwCeNRYV5ndofeHE4DqOy92pawzk x7AAoJa/pEBQMHUIQhTmcZqvyZUMVBk2 =V/0k -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F19 Alpha RC5 compose
-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 > 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 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
Re: [fedora-arm] F19 Alpha RC5 compose
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 9 May 2013 16:28:02 -0500 Dennis Gilmore escribió: > > Hi all, > > there is a Release Candidate compose for Alpha at > http://armpkgs.fedoraproject.org/mash/stage/19-Alpha-RC5/ > some follow up, chrony is not installed so time may be off, root's password is empty. right now initial-setup is not running so you need to log in at a console and setup a passwd for root and create user accounts. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGMGjMACgkQkSxm47BaWffJ0ACcDSkg5gVSzHcrk+vXBTi84zhC xl4An2AunF58PuTgktRiIsinE6P+qIa3 =nPL6 -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
