Hello Peter,
Thank you for your response.
I meant no offense to you or the work you have done for both the ARM
community and the Odroid community. On the contrary, I applaud it. I am
fully aware that most people that provide help and services in the
"Linux World", including the ARM portion of that, are volunteers
providing support/expertise on their OWN time. I myself have provided
help to the community in the past on various things and continue where I
can, when I can.
However, when both you and Dennis are the primary people responding to
user requests for help, to whom else are users to turn for help? At
least, with this posting of yours, we now know where your (and perhaps
others on the team) priorities lie. So, I thank you for that as well.
No apologies necessary on your behalf.
Stewart
On 10/12/2017 04:30 PM, Peter Robinson wrote:
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
