Re: [fedora-arm] beginning of Fedora support for the Raspberry Pi 2
The firmware should be acceptable for immediate packaging in Fedora: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Binary_Firmware (I believe that page was amended explicitly to allow for the raspberry pi bootloader. It even mentions raspberry pi by name in the example.) The firmware is still required to boot, because it still provides runtime services to userspace. Eventually it may go away, but probably not in 2015. I think you would chain to u-boot if you wanted u-boot in the mix. Firmware upstream: https://github.com/raspberrypi/firmware This video contains some info about the overall open source roadmap: https://www.youtube.com/watch?v=EXDeketJNdk Ultimately it is on people's radar but far off. (But could be accelerated by motivated individuals.) Adam On Wed, Feb 4, 2015 at 10:43 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, As a follow up of the discussion that happened at the last ARM meeting (and because 3 days post announcement of it I'm sick of repeating myseld:-P ) I thought I'd outline the process for getting support for the Raspberry Pi 2 into Fedora The first phase I believe should be a remix, with the modified packages required to support the install for that remix being is a published repository, while we're awaiting all the bits to land upstream. The short term repository should only contain the following: * kernel * bootloader * firmware * mainline userspace packages that need non upstream pacakges Everything else (eg xorg drivers) should be packaged up and go through the standard package review process and be in mainline Fedora. From there we can spin a remix image for testing. BUT before we get to that we need to review all the projects/sources/packages that are needed and document what packages are needed and where the upstream is located. In the case of firmware we also need to ensure it's re-distributable. Does the GPU firmware still boot or is it now possible to use the upstream u-boot support to boot the device and then load the firmware via the kernel like other standard drivers that need firmware, or do we even need binary firmware any more? I believe Seneca has volunteered to spear head this so it would be great if they can start by documenting the above and post the details of it in response to this mail so we can work out what needs to be done and where in preparation for the remix, this will then give us a good picture as well when we might be able to just support it by the standard mainline process. Regards, Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] beaglebone power down control?
Thanks for this info on both lists! Adam On Dec 7, 2014 7:28 PM, Robert Nelson robertcnel...@gmail.com wrote: Well good to know that something else is going to push us toward getting the 3.19 kernel! ;) Or just locally backport 22 patches when rc1 hits. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] beaglebone power down control?
Hi, I've noticed that the beaglebone doesn't power off at shutdown with Fedora 21. Does anyone happen to know if support for this is in a mainline kernel (so coming soon)? Or is this a bug and not expected? If not I guess I might have to try to make a mini-remix myself. Thanks, Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] beaglebone power down control?
Yes, the cubieboards are completely different. I guess what I am looking for is the equivalent for AM335x of this: http://linux-sunxi.org/Linux_mainlining_effort Maybe I will ask on the beagleboard list. Adam On Sat, Dec 6, 2014 at 11:33 PM, Robert Moskowitz r...@htt-consult.com wrote: On 12/06/2014 10:59 PM, Adam Goode wrote: Hi, I've noticed that the beaglebone doesn't power off at shutdown with Fedora 21. Does anyone happen to know if support for this is in a mainline kernel (so coming soon)? Or is this a bug and not expected? My Cubieboards power off at shutdown. If not I guess I might have to try to make a mini-remix myself. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. Adam On Thu, Nov 13, 2014 at 7:13 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi Adam, Problem should now be fixed with -5 Can you test and provide karma so we can get it in GA. https://admin.fedoraproject.org/updates/FEDORA-2014-14716/uboot-tools-2014.10-5.fc21 On Tue, Oct 28, 2014 at 12:37 AM, Adam Goode a...@spicenitz.org wrote: This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
If you follow these instructions, you can make an SD card: https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#Scripted Adam On Thu, Nov 13, 2014 at 11:08 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: W dniu 13.11.2014 o 15:14, Adam Goode pisze: Works great for me! Thanks. Does anyone have a beaglebone white? I'm still worried that this fix will break that board. I did not followed thread but have working BBW somewhere. can you point me to SD card image which I can use to test? ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
This is still present with -3. It looks like this version of U-Boot is not capable of booting from the internal eMMC on beaglebone black. U-Boot SPL 2014.10-g4647503-dirty (Oct 24 2014 - 16:47:41) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### I found at least another thread about this issue, from version 2014.07: https://www.mail-archive.com/meta-ti@yoctoproject.org/msg04279.html Adam On Fri, Oct 24, 2014 at 1:21 PM, Peter Robinson pbrobin...@gmail.com wrote: A minor bug and is fixed in uboot-tools-2014.10-3.fc21 Peter On Sat, Oct 18, 2014 at 9:04 PM, Adam Goode a...@spicenitz.org wrote: Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] u-boot 2014.10 GA on it's way to F-21
Hopefully I did something wrong, but it's not working at all for me on the beaglebone black: Here is what I get when I try to boot from eMMC: U-Boot SPL 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear spl: mmc init failed: err - -19 ### ERROR ### Please RESET the board ### Here is what I get when I make a new SD card from the latest minimal image: U-Boot 2014.10-gc4b8756-dirty (Oct 15 2014 - 08:57:04) Watchdog enabled I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Error - No Valid Environment Area found *** Warning - bad CRC, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! When I am in the uboot command processor, I cannot select the internal eMMC at all: U-Boot# mmc dev 1 Card did not respond to voltage select! Previously, I was booting with no problems from either eMMC or SD with F21. Thanks, Adam On Wed, Oct 15, 2014 at 6:34 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Just a heads up that the u-boot 2014.10 GA is on it's way to Fedora 21. https://admin.fedoraproject.org/updates/uboot-tools-2014.10-1.fc21 This release contains numerous fixes and improvements over the currently shipping release including, but by no means limited to: * Upstream generic distro support (huge thanks to Dennis Gilmore and Steven Warren for their tireless work to get this upstream * AllWinner suppport for A10*/A13/A20 devices (huge thanks to Hans for this tireless work on this) * Numerous other improvements too long to name. New devices that we now enable in this release, in no particular order, include: AllWinner: A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino_MICRO Bananapi Cubieboard Cubieboard2 Cubietruck Mele_A1000 Mele_A1000G Mini-X Mini-X-1Gb Tegra: jetson-tk1 i.MX6 cm_fx6 (Utilite) riotboard It's not yet in nightly builds but I'm going to request it for the next Beta TC compose. Known issues: * Panda is not yet ported to generic distro support Please test and provide feedback. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] install to 4GB eMMC on the Rev C Beaglebone Black?
This is the standard F-20 release, with its standard uboot. http://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Sounds like F-21 improves this? Sounds good. Thanks, Adam On Thu, Oct 9, 2014 at 6:18 AM, Peter Robinson pbrobin...@gmail.com wrote: On Thu, Oct 9, 2014 at 5:11 AM, Adam Goode a...@spicenitz.org wrote: Thanks. I got it working via an mSD card, then transferring over. The one wrinkle is that I needed to edit a-b-c.d/19-config-adds to add 1:3 1:2 1:1 to u_devpart to get the thing booting. Maybe this is a worthwhile change to make to a-b-c? What Fedora and uboot release? With extlinux.conf support that shouldn't matter I don't believe. Peter On Tue, Oct 7, 2014 at 6:30 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi Adam, The instructions for Fedora for BBB all suggest to install to an SD card. Is it possible to install to the eMMC and not need an SD card? Any ideas? There's two possible ways of doing this. The first is to use a SD card like the standard instructions to get a system running not off the eMMC but have a copy of the image on the sd card and basically repeat it over onto the MMC, remove the sd card and reboot. I've done that with the 2gb model but it's not ideal as you do need an initial mSD card. The second way, which is untested but on my list of to look at (I was actually investigating the uboot side of things over the weekend) is to use the USB DFU functionality of the usb-otg port. AFAICT all the bits are there on the uboot side, and there's dfu-util package but the documentation I've managed to find is, at best, poor and I've not had time to play and work out all the bits, like how to update the uboot too. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] install to 4GB eMMC on the Rev C Beaglebone Black?
Thanks. I got it working via an mSD card, then transferring over. The one wrinkle is that I needed to edit a-b-c.d/19-config-adds to add 1:3 1:2 1:1 to u_devpart to get the thing booting. Maybe this is a worthwhile change to make to a-b-c? Adam On Tue, Oct 7, 2014 at 6:30 AM, Peter Robinson pbrobin...@gmail.com wrote: Hi Adam, The instructions for Fedora for BBB all suggest to install to an SD card. Is it possible to install to the eMMC and not need an SD card? Any ideas? There's two possible ways of doing this. The first is to use a SD card like the standard instructions to get a system running not off the eMMC but have a copy of the image on the sd card and basically repeat it over onto the MMC, remove the sd card and reboot. I've done that with the 2gb model but it's not ideal as you do need an initial mSD card. The second way, which is untested but on my list of to look at (I was actually investigating the uboot side of things over the weekend) is to use the USB DFU functionality of the usb-otg port. AFAICT all the bits are there on the uboot side, and there's dfu-util package but the documentation I've managed to find is, at best, poor and I've not had time to play and work out all the bits, like how to update the uboot too. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] install to 4GB eMMC on the Rev C Beaglebone Black?
Hi, The instructions for Fedora for BBB all suggest to install to an SD card. Is it possible to install to the eMMC and not need an SD card? Any ideas? Thanks, Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
I seem to remember some kind of koji diff report that would come out periodically. Is there an automated run of this? I would love a dashboard or NxN matrix of diffs between all the arches. A timeseries would be perfect (to see the trends Matthew is referring to). Aha, found what I was thinking of: https://lists.fedoraproject.org/pipermail/arm/2013-February/005336.html Can this be rolled into automation in a more official way? Even something per-package like what Debian does is a start: https://packages.debian.org/wheezy/mlton-compiler vs. https://apps.fedoraproject.org/packages/mlton Thanks, Adam On Tue, Jun 10, 2014 at 5:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote: What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Is it? Where's your proof? From the patches and dealings with it personally that's not my understanding and if it is the case it's not due to the ARM team but because packagers aren't following the packaging process and in this case we actively fix them when we're made aware of the incident. In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. And if they engage with us about that experience we do our best to deal with them where possible. There's a few cases where I'm aware of that we don't package because the HW is actively not supported on ARM or similar style cases. In those cases I would argue that it's better not to build the packages as arguably no experience is better experience than a bad experience especially if there's potential of issues that offer a worse experience, hardware breakage or data corruption. The fact is that the x86 and ARM use cases don't match up 100% and I don't see the point in trying to glue those together 100% for the sake of a check box. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Well why didn't you say that from the start rather than coming in and bullying the people actively involved and make them feel like the massive effort myself and many others have been putting in is useless and a waste of time. Don't be a Magpie Board Member and fly in and shit over everything and than fly awau with no concept of what's happening below. Every time you've had any attempt at opinion that's the way you've done it and all you do is get all our backs up and make the problem worse rather than better. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? I'm not sure I agree with your outline here, you've given no real concrete examples here. I agree there's no real incentive but there's over 15,000 source packages in Fedora and there's less than 100 (last time I looked, unfortunately there's no easy way off checking this without downloading the entire src.rpms or checking out all 15K git repos) or so excluded from ARM and the vast majority of those are due to HW support. There's some like D where upstream has yet to port the stack. I'm sure there's others I'm unaware of but it's not
Re: [fedora-arm] KVM on Samsung Chromebook A15
Was there ever a resolution to this? I am happy to file a bug in the chromium tracker to get this looked at, if needed. Adam On Fri, Jul 5, 2013 at 12:16 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Jul 05, 2013 at 11:30:01AM -0400, Jon Masters wrote: On 07/05/2013 05:07 AM, Richard W.M. Jones wrote: On Wed, Jul 03, 2013 at 11:59:28AM -0500, Jon wrote: I'm pleased to announce the availability of Fedora 19 for the 2012 Samsung Chromebook featuring ARM Exynos dual core A15 processor. Sorry to slightly hijack this thread. I will try your remix later. Reading the comments on https://lwn.net/Articles/557132/#Comments it seems as if the news on KVM on the Chromebook is not good. It doesn't boot into HYP mode, and there's no way to make it boot into HYP mode, so KVM won't be supported. Is that right? That's roughly what I'd expect to be the case. There might be a signed U-Boot someone has hacked that does enable HYP mode, but otherwise I suspect you're out of luck. I'll ask around during Linaro Connect. I asked about this on #kvm-arm earlier today and got this long reply: 11:58 rwmjones I'm reading a comment here: 11:58 rwmjones https://lwn.net/Articles/557561/ 11:58 rwmjones which suggests that KVM on the Samsung Chromebook 2012 (ARM A15 version) isn't possible because the bootloader doesn't boot into HYP mode 11:58 rwmjones is this true? if so is there a way around it? 11:59 pm215 IIRC the bootloader gets control in secure-SVC 11:59 pm215 it is from there possible to get to NS-HYP 11:59 pm215 it's just that the stock bootloader doesn't do this before booting the kernel 11:59 rwmjones so what's involved in making it work? 11:59 pm215 somebody needs to write some code and get it into the bootloader 12:00 rwmjones ok, and the bootloader can be replaced (next comment down suggests this requires soldering)? 12:01 pm215 I believe this to be true, though I don't have a chromebook 12:01 pm215 I think you get the google bootloader to chain boot some other bootloader which you do have control of, and then that can actually boot your os 12:02 suihkulokki or maybe we could just prepend some code in front of the kernel zimage that switches to HYP mode? 12:02 pm215 nope 12:02 suihkulokki damn 12:02 pm215 we spent quite a long time being very firm that the ABI here is bootloader's job to get this right 12:03 pm215 there are some u-boot patches currently going through code review to do the go-to-hyp-mode thing properly for arndale 12:03 pm215 hopefully if they get upstream it will be more straightforward to say ok, I have $other-board and it needs to do this too 12:05 apritzel which would require that the Chromebook u-boot support is upstream as well 12:05 apritzel AFAIK this is not the case currently [There's more of this, but that seems to cover the main points] Reading around this, it does seem as if it's possible to get from secure SVC to HYP (although not easy). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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] KVM on Samsung Chromebook A15 (was: Re: Announcing Fedora 19 (Schrödinger's cat) for the 2012 Samsung Chromebook)
Is there a bug in the chromium tracker for this? If not, could someone with the details create one at http://crbug.com/new ? Thanks, Adam On Fri, Jul 5, 2013 at 2:28 PM, John Dulaney j_dula...@live.com wrote: On Wed, Jul 03, 2013 at 11:59:28AM -0500, Jon wrote: I'm pleased to announce the availability of Fedora 19 for the 2012 Samsung Chromebook featuring ARM Exynos dual core A15 processor. Sorry to slightly hijack this thread. I will try your remix later. Reading the comments on https://lwn.net/Articles/557132/#Comments it seems as if the news on KVM on the Chromebook is not good. It doesn't boot into HYP mode, and there's no way to make it boot into HYP mode, so KVM won't be supported. Is that right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ This is correct as of right now. On my todo list is to try to figure out a way to make it work. Xen, however, does work, and I have done it with the 3.10 kernel. John. ___ 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] Expected latency of arm shadowbuild?
On Sat, May 4, 2013 at 5:30 PM, Adam Goode a...@spicenitz.org wrote: On Thu, May 2, 2013 at 2:01 PM, Peter Robinson pbrobin...@gmail.com wrote: It was blocked, now fixed. keep and eye out. So mlton-20100608-17.fc20 and mlton-20100608-17.fc19 built fine. I don't see anything successful for f18 or f17 though. I am consistently getting build failed messages for the now-ancient mlton-20100608-1.fc14. Is there some way to clear this out so the new build can go through? Thanks, Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Expected latency of arm shadowbuild?
On Thu, May 2, 2013 at 2:01 PM, Peter Robinson pbrobin...@gmail.com wrote: It was blocked, now fixed. keep and eye out. It's looking good so far! Thanks. Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Expected latency of arm shadowbuild?
Hi, I built a new release of mlton that finally will work on arm and armhfp. I built it in the main koji system, but have been waiting for days to see it on the arm builder. http://koji.fedoraproject.org/koji/buildinfo?buildID=414787 Is there something special I need to do? I also have mlton builds for f17,f18,f19 that are pushed to testing, but have seen no activity in the arm builder either. Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] can't init fedora-18-arm mock buildroot from armhfp device?
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. Log below. Thanks, Adam ERROR: Command failed: # ['/usr/bin/yum', '--installroot', '/var/lib/mock/fedora-18-arm/root/', 'groupinstall', 'buildsys-build'] Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: /bin/sh Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: perl(Getopt::Long) Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: zip Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: dwz = 0.4 Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: /usr/bin/perl Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: coreutils Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: /bin/bash Error: Package: redhat-rpm-config-9.1.0-37.fc18.noarch (fedora) Requires: rpm = 4.8.0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ___ 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?
But I believe it would work if I unpacked a softfloat root filesystem and did a chroot into it. At that point, only the kernel is involved, and it doesn't care what kind of binaries you're running. I understand it is not a supported thing, and I am ok with this. Yum and mock work a certain way and rely on the host's yum. Changing that seems like a lot of work for little gain. Adam On Wed, Apr 24, 2013 at 8:13 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 Apr 2013 15:54:20 -0400 Adam Goode a...@spicenitz.org 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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Anyone know status of support for ODROID (Exynos 4412) ?
Hi, I am looking to buy some ARM hardware for Fedora, and really like the ODROID-U2. I know it is not supported yet by Fedora. Does anyone have an idea if the support is close? I am not seeing too much in the way of active kernel upstreaming, but I could be wrong. Also, it seems to require a some Samsung-provided binary blobs for booting, as well as a signed bootloader. http://dev.odroid.com/projects/4412boot/#s-3 https://github.com/hardkernel/u-boot/tree/odroid-v2010.12/sd_fuse Are these blobs compatible with the Fedora firmware guidelines, or would this board be forever doomed to live as a remix? Thanks, Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] D2Plug?
Hi, I'm thinking of getting a D2Plug. Has anyone had any experience with Fedora on it? It seems like a great bit of hardware for the armv7hl port. http://www.plugcomputer.org/development-kits/d2plug.html Adam ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] hardfp support
On 10/25/2010 07:31 PM, Dennis Gilmore wrote: Id like to have us look at what we need to do to support both software floating point and hardware floating point support. I had been under the impression that all we would need to do is to build glibc with hardfp support. however that may not be the case. and we may need to build everything with hardfp support. this is just to get discussion rolling See this thread for a little context: http://cygwin.com/ml/libc-ports/2009-04/msg00020.html Basically, soft floating point on ARM is done with helper functions. By default, these are statically linked in, but they do not need to be. If you dynamically link in the aeabi floating point helper code (basically libgcc) and have a multilib glibc, then there is the ability to have softfp binaries that can take advantage of hardfp when available. These binaries will be slower than real hardfp binaries though. And it is not clear that multilib alone is sufficient, it may be that the new IFUNC stuff is really needed for good performance across different VFP variants. Adam signature.asc Description: OpenPGP digital signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
