> I have downloaded and installed the F27 Beta Mate Spin for arm. It seems Firstly, the Beta is ancient, there's nightly builds you should be testing with, a LOT has changed since Beta. Basically the response to "I tried beta" is for you to go and try the latest nigltly. > the basic release version suffers from all of the problems as did > F26..."cpuidle.off=1" must be added to the kernel append line, onboard > gigethernet not recognized, and neither of the two USB 3 ports is I have no doubt, I've not seen anything land upstream to indicate any of that would be fixed. As I'm mentioned before I will pull in upstream patches _ONCE_ they're accepted. They've not been, I'm not tracking this upstream but I've not noticed a new revision of the patch for the USB-3 addressing any of the problems with them. The cpu idle issue has been like that, and Dennis can likely better confirm, since at least the beginning of last year. > recognized. These were the issues and boot parameters required to boot the > Odroid-XU4 microSD card. I suspect, the same dracut drivers "pwrseq_emmc" > will be required to boot F27 on the eMMC card. Actually this is fixed, I've had confirmation from a couple of people that is the case. > Since we are still in Beta, is there anyway we can get these boot parameters > included for the F27 final release? As well, I would be happy to test the > patches for the USB 3 and gigethernet in hopes of getting them included as > well. This is where I put my grumpy hat on. Firstly we're not "still in Beta", it shipped weeks ago, we're exactly 2 working days away from final freeze, 4 if you include the weekend. A few things to note. I am the Fedora ARM kernel cat herder, it's voluntary. I am NOT a kernel developer and I primarily do it on my own time, I'm lucky enough that my employer allows me to spend some of the time at my dayjob doing this but it's not my day job. So basically this is the way it works: * I accept and review patches. This includes patches from upstream, both board and SoC vendors, and contributors * I triage, test and pull patches needed by the project, often core fixes to ARMv7 or aarch64 that affect all types of devices * I do some kernel things that my direct $dayjob (IoT) depend on * I do kernel bits around devices I'm interested in and can test myself on my own devices. This is primarily pulling in the occasional patch headed upstream or something I know I can personally test, and if I have problems know I can get a response from the vendor or the upstream maintainers. Raspberry Pi is one of these devices which I maintain myself but the wider project has interest in. * Engagement with the upstream community on general, not device specific, ARM issues that improve Fedora and the wider distro community. What I don't do: * Random requests. I'm not a low level kernel developer. I'm not a consulting service to get things fixed. You can find the schedule at the following link, swap the numbers for F-28 too if you're interested. https://fedoraproject.org/wiki/Releases/27/Schedule This is a community project, a lot of us are volunteers and in a lot of cases if we're lucky enough to get paid to do it, but for a lot it's a hobby, and for a few like myself it crosses the boundaries of both. Also yes, there's a lot more of the wider ARM community here involved assisting in making things work, from SoC vendors to device manufacturers to companies that actually use Fedora ARM. In a lot of cases I'd be able to ask vendors / SoC people to assist to get problems fixed so I can pull in a fix but unlucky for you I'm unaware of either SoC nor Vendor kernel/hardware people hanging around here to assist in fixing the problem which is why all exynos platforms and odroid devices in Fedora are not considered supported but are considered "best effort when people get time to scratch an itch" because of exactly these issues. I would apologise for it but I don't tend to do that for things completely out of my control. So what has improved for Exynos in Fedora 27? It should boot without having to mess around with initrds and other such things on the SD/mmc slots, in theory wireless might work if the device has it (no idea if this is the case. What won't change usb3 and cpuidle because I don't see a patch landing in my inbox between now and the end of my Friday which will basically be the last moment for ARM patches that wouldn't get a freeze exception. I'm sorry that I can't fall all over the place and roll out the red carpet but I personally don't have the time to deal with this myself nor the interest. I am personally going to spend my time, and that of my employer's, on the platforms/SoCs/vendors that contribute time and resources to this community, and after I've dealt with them I have little time spare. Peter > Kind regards, > Stewart > > > On 09/19/2017 02:11 AM, Peter Robinson wrote: >> >> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels <searider74@xxxxxxxxx> >> wrote: >>> >>> Andreas & Dennis, >>> >>> I have filed an upstream bug report regarding the USB3 and Ethernet >>> situation described below. You can get to the bug report using the >>> following link: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1487006 >> >> To note a bug in RHBZ is a Fedora bug not an upstream bug. >> >> That being said I was browsing through the actual upstream arm-kernel >> mailing list and it looks like others are seeing this problem and have >> actually sent patches [1]. Once there's been some review and when I >> get time I'll try to pull it int a Fedora kernel. >> >> [1] http://www.spinics.net/lists/arm-kernel/msg606525.html >> >>> On 08/30/2017 08:06 PM, Stewart Samuels wrote: >>> >>> Hello Andreas, >>> >>> I can now confirm that the onboard Ethernet for the Odroid-XU4 indeed >>> does >>> NOT work in F26. Looking at the Odroid hardware model, it looks to me >>> like >>> the onboard gigabit Ethernet port is tied to the USB3 controller. If so, >>> it >>> makes sense that because USB3 is failing, the gigabit Ethernet may also >>> fail. I will file an upstream bug report regarding both the USB3 and >>> onboard Ethernet situation. >>> >>> Regards, >>> Stewart >>> >>> On 08/30/2017 07:59 AM, Stewart Samuels wrote: >>> >>> Hello Andreas, >>> >>> Close. As I am not using the onboard ethernet, I did not test that so I >>> cannot validate yet whether or not it works. However, I can validate >>> that >>> the USB3 ports do not work. If I get a chance today sometime, perhaps I >>> will check the onboard ethernet. As a result, see my adjustment to line >>> item 2. embedded below. >>> >>> Regards, >>> Stewart >>> >>> On 08/30/2017 01:16 AM, arm_ml@xxxxxxxxxxx wrote: >>> >>> Summary of Fedora on Odroid XU4 >>> >>> 1. with Kernel 4.6.5-300.fc24 system boots without failure, but update to >>> newer kernel fails due dracut didn't build suitable intramfs >>> https://bugzilla.redhat.com/show_bug.cgi?id=1482825 >>> 2. newer kernel works only with "cpuidle.off=1" inserted into the >>> "append" >>> kernel line in the /boot/extlinux/extlinux.conf file, but all USB3 Hosts >>> failed, no onboard ethernet >>> >>> 2. Fedora 26 released kernels work but the system fails to boot >>> unless >>> "cpuidle.off=1" is inserted into the "append" kernel line in the >>> /boot/extlinux/extlinux.conf file. Additionally, the onboard USB3 ports >>> fail. >>> >>> 2. Fedora 26 released kernels work but the system fails to boot >>> unless "cpuidle.off=1" is inserted into the "append" kernel line in the >>> /boot/extlinux/extlinux.conf file. Additionally, the onboard USB3 ports >>> fail as does the onboard Ethernet port. >>> >>> >>> 3. To boot the system from the eMMC card: >>> A. The initramfs image file must be rebuilt. The simplest way is to: >>> a. Boot up using the MicroSD card; >>> b. Partition the eMMC card such that partition 1 begins on sector >>> 3072 >>> (Default starting sector from fdisk is 2048). There should be >>> 4 >>> partitions created; >>> c. Mount the Fedora image desired to be installed on the eMMC >>> card; >>> d. Copy all partition data from the mounted fedora image >>> partitions >>> (there are 4 for Fedora 26 ARM images) to the appropriate eMMC >>> partitions; >>> e. Update the UUID values on what will be the >>> /boot/extlinux/extlinux.conf file and /etc/fstab files of the eMMC card; >>> f. Assuming the eMMC partitions are mounted as such -- >>> mount /dev/mmcblk1p4 /mnt >>> mount /dev/mmcblk1p2 /mnt/boot >>> then perform the following mounts -- >>> mount -o bind /proc /mnt/proc >>> mount -o bind /dev /mnt/dev >>> mount -o bind /sys /mnt/sys >>> B. Rebuild the eMMC card's initramfs by executing the following >>> command: >>> chroot /mnt dracut --add-drivers='pwrseq_emmc mmc_block' >>> /boot/initramfs-4.11.8-300.fc26.armv7hl.img 4.11.8-300.fc26.armv7hl >>> C. Flash the boot information in the header of the eMMC card; >>> C. Shutdown the system, then remove the MicroSD card; >>> D. Boot up using the eMMC card. >>> >>> 4. If the system is to be updated using "dnf update", a new initramfs >>> image >>> must again be generated. This can be done using steps 1f - B. above >>> using >>> the new initramfs and kernel images provided by the "dnf update". >>> >>> ---------------------------------------------------------------- >>> >>> Note to the developers/maintainers of dracut: >>> The kernel modules "pwrseq_emmc" and "mmc_block" should be included in >>> dracut for the Odroid-XU3 and Odroid-XU4 such that the user need not have >>> to >>> execute this procedure each time and update to the system is performed. >>> >>> >>> >>> Is this correct and complete ? >>> >>> Andreas >>> >>> >>> >>> >>> >>> _______________________________________________ >>> arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> > _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
