[fedora-arm] Re: Summary of Fedora on Odroid XU4

Discussion:

Stewart Samuels

2017-08-30 14:59:32 UTC

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

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.

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
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".
----------------------------------------------------------------
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 -- ***@lists.fedoraproject.org
To unsubscribe s

Dennis Gilmore

2017-08-30 18:35:42 UTC

Permalink

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
A. The initramfs image file must be rebuilt. The simplest way is
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
chroot /mnt dracut --add-drivers='pwrseq_emmc mmc_block'
/boot/initramfs-4.11.8-300.fc26.armv7hl.img 4.11.8-300.fc26.armv7hl

mmc_block is not needed to be added.
you should drop a config snippet in a file such as
/etc/dracut.conf.d/pwrseq_emmc.conf
contents being
add_drivers+=" pwrseq_emmc "

with that dracut will always include the modules when making
initramfs's

Dennis

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".
----------------------------------------------------------------
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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@list

Stewart Samuels

2017-08-31 03:06:57 UTC

Permalink

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

Post by Stewart Samuels
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

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.

Post by Stewart Samuels

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
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".
----------------------------------------------------------------
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 -- ***@lists.fedoraproject.org
To unsubscr

Stewart Samuels

2017-08-31 04:27:11 UTC

Permalink

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

Stewart

Post by Stewart Samuels
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

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.

Post by Stewart Samuels

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
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".
----------------------------------------------------------------
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

Peter Robinson

2017-09-19 09:11:09 UTC

Permalink

Post by Stewart Samuels
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
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

Post by Stewart Samuels
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
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
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.
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
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".
----------------------------------------------------------------
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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to

Stewart Samuels

2017-10-02 00:41:23 UTC

Permalink

Hello Peter,

Post by Peter Robinson

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

Please let me know when you have a kernel or release available with the
patch and from where to download it. I would be happy to test it.

Thanks.

Stewart

Post by Peter Robinson

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@li

Peter Robinson

2017-10-02 09:07:15 UTC

Permalink

Post by Stewart Samuels
Hello Peter,

Post by Peter Robinson

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

Please let me know when you have a kernel or release available with the
patch and from where to download it. I would be happy to test it.

When it's accepted for upstream and I notice it I'll land it. All the
rest depends on my time, if someone else notices feel free to poke
here

Post by Stewart Samuels

Post by Peter Robinson

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to

Stewart Samuels

2017-10-12 19:19:27 UTC

Permalink

Hello Peter,

I have downloaded and installed the F27 Beta Mate Spin for arm. It
seems 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
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.

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.

Kind regards,
Stewart

Post by Peter Robinson

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

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an em

Peter Robinson

2017-10-12 23:30:00 UTC

Permalink

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

Post by Peter Robinson

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

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to ar

Richard Ryniker

2017-10-13 02:40:28 UTC

Permalink

Post by Peter Robinson
This is where I put my grumpy hat on.

Not grumpy, and it is no slur to call you realistic.
(I would even venture to think you optimistic.)

Thank you for cogent words about the Peter Robinson world.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-leav

Stewart Samuels

2017-10-13 02:52:54 UTC

Permalink

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

Post by Peter Robinson

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.

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.

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
* 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.
* 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

Post by Peter Robinson

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

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-lea

Peter Robinson

2017-10-13 12:27:07 UTC

Permalink

I have to wait that all missing parts, (USB3, cpuidle, ...) are done
upstream (Kernel) when I want to use Fedora on Odroid XU4 or Odroid HC1
(I've tested Fedora 27 beta on it ) or I have to use Ubuntu.

The device isn't broken without cpuidle, but USB3 has been broken
since 4.8 and the silicon vendor has done nothing to fix it, I feel
this shows their commitment, personally I would prefer an upstream
actively maintained kernel for CVEs and such vs the Ubuntu variant
where it tends to be use the board vendor kernel and do rare an
infrequent patches for CVEs and security, at least with Fedora you
know exactly which bit is broken. Ultimately I have never recommended
any of the odroid or exynos devices for exactly this reason, they
don't care.

Thanks for the clarification of fact by Peter.
I want to provide help to the cummunity where I can.
Andreas
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedor

Gerald Henriksen

2017-10-13 21:21:45 UTC

Permalink

Post by Peter Robinson

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.
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.

I appreciate the work you do, which given the attitude of many of
these ARM vendors is pretty close to an impossible task.

But in fairness to the original poster I think it worth pointing out
that the Beta is not what most people would call ancient having only
been released 10 days ago (Oct 3).

I certainly wouldn't expect after now only 8 work days of the beta to
be expected to check out a nightly build.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

Peter Robinson

2017-10-14 10:22:56 UTC

Permalink

Post by Gerald Henriksen

Post by Peter Robinson

I have downloaded and installed the F27 Beta Mate Spin for arm. It seems

I appreciate the work you do, which given the attitude of many of
these ARM vendors is pretty close to an impossible task.
But in fairness to the original poster I think it worth pointing out
that the Beta is not what most people would call ancient having only
been released 10 days ago (Oct 3).
I certainly wouldn't expect after now only 8 work days of the beta to
be expected to check out a nightly build.

It froze weeks prior to that on 9th Sept and given F27 only branched
in early August in relative terms it is ancient and in the terms of
early boot stuff on ARM there's been a lot of changes since Beta.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedorapr

Stewart Samuels

2017-10-14 22:29:46 UTC

Permalink

So, Peter,

I've got a question for you. If a user performs a "dnf -y update"
subsequent to installing a "finalized" and published image, Beta or
otherwise, does that update include the "latest" (daily published) up to
that point in time updates? My assumption/belief is that it does, so I
just want to get clarification of the process.

Thanks,
Stewart

Post by Peter Robinson

Post by Gerald Henriksen

Post by Peter Robinson

I have downloaded and installed the F27 Beta Mate Spin for arm. It seems

I appreciate the work you do, which given the attitude of many of
these ARM vendors is pretty close to an impossible task.
But in fairness to the original poster I think it worth pointing out
that the Beta is not what most people would call ancient having only
been released 10 days ago (Oct 3).
I certainly wouldn't expect after now only 8 work days of the beta to
be expected to check out a nightly build.

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Peter Robinson

2017-10-15 08:08:25 UTC

Permalink

Post by Stewart Samuels
So, Peter,
I've got a question for you. If a user performs a "dnf -y update"
subsequent to installing a "finalized" and published image, Beta or
otherwise, does that update include the "latest" (daily published) up to
that point in time updates? My assumption/belief is that it does, so I just
want to get clarification of the process.

Yes, and if you do it with a pre-release it'll also add
updates-testing by default too

Post by Stewart Samuels
Thanks,
Stewart

Post by Peter Robinson

Post by Gerald Henriksen

Post by Peter Robinson

I have downloaded and installed the F27 Beta Mate Spin for arm. It seems

I appreciate the work you do, which given the attitude of many of
these ARM vendors is pretty close to an impossible task.
But in fairness to the original poster I think it worth pointing out
that the Beta is not what most people would call ancient having only
been released 10 days ago (Oct 3).
I certainly wouldn't expect after now only 8 work days of the beta to
be expected to check out a nightly build.

_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fe

Peter Robinson

2017-10-15 08:54:07 UTC

Permalink

Post by Peter Robinson

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

So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!

PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not _THAT_ nice, oh and the
proper HC1 support will land with that too.

[1] http://www.spinics.net/lists/arm-kernel/msg611632.html
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t

Stewart Samuels

2017-10-15 16:50:16 UTC

Permalink

Post by Peter Robinson

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

So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!
PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not _THAT_ nice, oh and the
proper HC1 support will land with that too.
[1] http://www.spinics.net/lists/arm-kernel/msg611632.html

Yes, I was reading through the developer threads regarding this topic so
I knew they were close to releasing patches. Not to continue this
conversation (because we already have your response), but that is part
of the reason I started this thread to begin with...to get an idea of
the timing and if it would be possible to get them in the F27 release.

Thanks.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

Peter Robinson

2017-11-15 10:18:20 UTC

Permalink

Any Updates ?
with actuell Fedora 27 no USB3 is working.

Well I pushed the proposed upstream patch quite some time ago, I
replied on this thread actually, and never heard anything so I assumed
that it worked because I never heard anything to the contrary. So if
that hasn't fixed it I have no idea where to go from here so someone
is going to have to engage with upstream to deal with this issue.

Peter

Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
armv7l armv7l armv7l GNU/Linux
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps
Ethernet adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:0 0 14,9G 0 disk
├─mmcblk1p1 179:1 0 29M 0 part
├─mmcblk1p2 179:2 0 488M 0 part /boot
├─mmcblk1p3 179:3 0 488M 0 part [SWAP]
└─mmcblk1p4 179:4 0 14G 0 part /
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
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
So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!
PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not _THAT_ nice, oh and the
proper HC1 support will land with that too.
[1] http://www.spinics.net/lists/arm-kernel/msg611632.html
Yes, I was reading through the developer threads regarding this topic so I
knew they were close to releasing patches. Not to continue this
conversation (because we already have your response), but that is part of
the reason I started this thread to begin with...to get an idea of the
timing and if it would be possible to get them in the F27 release.
Thanks.
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@

Stewart Samuels

2017-11-15 16:53:00 UTC

Permalink

I was under the impression that the fix was going to be released into
kernel 4.15 based on this response from you Peter.Â And based on your
schedule, I was also under the impression that any of these fixes likely
would not go into earlier releases, so I haven't tested them.Â As this
was the last set of communications we have had regarding these issues, I
was not aware that you had actually pushed the upstream patch.Â Now that
I know you have, I will retest them by downloading the latest updates to
F27.

Regards,

Â Â Â Â Stewart

Post by Peter Robinson

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

So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!

PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not_THAT_ nice, oh and the
proper HC1 support will land with that too.

[1]http://www.spinics.net/lists/arm-kernel/msg611632.html

Post by Peter Robinson

Post by Stewart Samuels
Any Updates ?
with actuell Fedora 27 no USB3 is working.

Post by Stewart Samuels
Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
armv7l armv7l armv7l GNU/Linux
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps
Ethernet adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:0 0 14,9G 0 disk
ââmmcblk1p1 179:1 0 29M 0 part
ââmmcblk1p2 179:2 0 488M 0 part /boot
ââmmcblk1p3 179:3 0 488M 0 part [SWAP]
ââmmcblk1p4 179:4 0 14G 0 part /
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
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
So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!
PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not _THAT_ nice, oh and the
proper HC1 support will land with that too.
[1] http://www.spinics.net/lists/arm-kernel/msg611632.html
Yes, I was reading through the developer threads regarding this topic so I
knew they were close to releasing patches. Not to continue this
conversation (because we already have your response), but that is part of
the reason I started this thread to begin with...to get an idea of the
timing and if it would be possible to get them in the F27 release.
Thanks.
_______________________________________________

_______________________________________________

Stewart Samuels

2017-11-15 22:02:58 UTC

Permalink

So, to follow up with my last transmission, I did indeed down load the
latest updates to both F26 & F27.Â The kernel I just tested on F27 is
4.13.12-200.Â It appears Andreas is correct in that USB 3 still does not
respond from what I can see.

Regards,
Â Â Stewart

Post by Stewart Samuels
I was under the impression that the fix was going to be released into
kernel 4.15 based on this response from you Peter.Â And based on your
schedule, I was also under the impression that any of these fixes
likely would not go into earlier releases, so I haven't tested them.Â
As this was the last set of communications we have had regarding these
issues, I was not aware that you had actually pushed the upstream
patch.Â Now that I know you have, I will retest them by downloading
the latest updates to F27.
Regards,
Â Â Â Â Stewart

Post by Peter Robinson

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

So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!
PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not_THAT_ nice, oh and the
proper HC1 support will land with that too.
[1]http://www.spinics.net/lists/arm-kernel/msg611632.html

Post by Peter Robinson

Post by Stewart Samuels
Any Updates ?
with actuell Fedora 27 no USB3 is working.

Post by Stewart Samuels
Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
armv7l armv7l armv7l GNU/Linux
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps
Ethernet adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:0 0 14,9G 0 disk
ââmmcblk1p1 179:1 0 29M 0 part
ââmmcblk1p2 179:2 0 488M 0 part /boot
ââmmcblk1p3 179:3 0 488M 0 part [SWAP]
ââmmcblk1p4 179:4 0 14G 0 part /
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
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
So today must be your lucky day, while waiting for images to download
I was browsing the ARM kernel list and noticed the exynos pull request
for 4.15 [1] and low and behold there's a fix headed upstream for the
usb3 issues and it applied cleanly to 4.13/4.14 so that should be
fixed in 4.13.7 which might make F-27 GA because I'm such a nice
individual. Only took them 7 kernel releases to fix it!
PS there's a bunch of other interesting stuff for those devices but
that'll have to wait for 4.15 because I'm not _THAT_ nice, oh and the
proper HC1 support will land with that too.
[1]http://www.spinics.net/lists/arm-kernel/msg611632.html
Yes, I was reading through the developer threads regarding this topic so I
knew they were close to releasing patches. Not to continue this
conversation (because we already have your response), but that is part of
the reason I started this thread to begin with...to get an idea of the
timing and if it would be possible to get them in the F27 release.
Thanks.
_______________________________________________

_______________________________________________

Stewart Samuels

2017-11-28 04:33:49 UTC

Permalink

Hello Andreas

Sorry it took me so long to get back. I have just tested kernel
4.15.0-0.rc0.git7.2.fc28.armv7hl and can confirm that indeed, USB 3
devices are now recognized as is the onboard gigabit ethernet port.
However, the system still requires the "cpuidle.off=1" argument on the
"append" line of the extlinux.conf file to boot.

Regards,
Stewart

Post by Stewart Samuels
So, to follow up with my last transmission, I did indeed down load the
latest updates to both F26 & F27. The kernel I just tested on F27 is
4.13.12-200. It appears Andreas is correct in that USB 3 still does not
respond from what I can see.
Regards,
Stewart

Post by Stewart Samuels
I was under the impression that the fix was going to be released into
kernel 4.15 based on this response from you Peter. And based on your
schedule, I was also under the impression that any of these fixes
likely would not go into earlier releases, so I haven't tested them.
As this was the last set of communications we have had regarding these
issues, I was not aware that you had actually pushed the upstream
patch. Now that I know you have, I will retest them by downloading
the latest updates to F27.

Hello together,
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153
Gigabit Ethernet Adapter
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA
Technology Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 118G 0 disk
├─sda1 8:1 0 680M 0 part
└─sda2 8:2 0 6,1M 0 part
mmcblk1 179:0 0 14,9G 0 disk
├─mmcblk1p1 179:1 0 29M 0 part
├─mmcblk1p2 179:2 0 488M 0 part /boot
├─mmcblk1p3 179:3 0 488M 0 part [SWAP]
└─mmcblk1p4 179:4 0 14G 0 part /
Now the onboard network and the ssd is working on my Odroid HC1. Next
test is the Odroid Xu4.
Thanks to everybody who made work.
Andreas
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-

Peter Robinson

2017-11-28 09:25:59 UTC

Permalink

Good.

Post by Stewart Samuels
system still requires the "cpuidle.off=1" argument on the "append" line of
the extlinux.conf file to boot.

Why is this a problem?

Post by Stewart Samuels
Regards,
Stewart

_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject.

Stewart Samuels

2017-11-28 20:11:09 UTC

Permalink

Post by Peter Robinson

Good.

Post by Stewart Samuels
system still requires the "cpuidle.off=1" argument on the "append" line of
the extlinux.conf file to boot.

Why is this a problem?

It is not necessarily a problem IF it is understood that this is (or
will be) the normal intended behavior by the developers for getting this
device to boot. If this is the case, then it should be documented as
such so users knows they must add it.

However, IMHO, if the intended behavior is such that the system should
boot out-of-the-box without any user modification other than perhaps
installing the correct u-boot information and images, then either this
argument should be added via the install procedure(s) or it should be
added implicitly to the kernel. But as this argument is probably not
necessary for other ARM devices, the preference would be to add it via
the install procedure(s).

The other possibility is that the reason the argument needs to be
provided to begin with is because perhaps there is a bug or it avoids
some other issues that really need to be addressed, in which case, this
is only a temporary work-around. Again, IMHO if this is the case, then
the install procedure(s) should insert the argument until the issue(s)
are remedied, at which time the argument can then be removed.

Post by Peter Robinson

Post by Stewart Samuels
Regards,
Stewart

_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproj

Peter Robinson

2017-11-30 08:37:47 UTC

Permalink

Post by Peter Robinson

Good.

Post by Stewart Samuels
system still requires the "cpuidle.off=1" argument on the "append" line of
the extlinux.conf file to boot.

Why is this a problem?

Sure, and we have a wiki basically anyone can edit, and even pages to
make notes for particular SoCs:

https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices

However, IMHO, if the intended behavior is such that the system should boot
out-of-the-box without any user modification other than perhaps installing
the correct u-boot information and images, then either this argument should
be added via the install procedure(s) or it should be added implicitly to
the kernel. But as this argument is probably not necessary for other ARM
devices, the preference would be to add it via the install procedure(s).

Define "intended", the "intended" use case is a good out of the box
experience but the _FACT_ of the matter is this is a community project
and you can't expect a few key members to make all of the 100s of
possible SBCs, and their 1000s of attached devices/drivers to work out
of the box flawlessly. People have devices, projects, stacks etc
they're personally interested in, in some cases companies care about
particular devices and will pay people to work on certain SoCs or
devices.

The other possibility is that the reason the argument needs to be provided
to begin with is because perhaps there is a bug or it avoids some other
issues that really need to be addressed, in which case, this is only a
temporary work-around. Again, IMHO if this is the case, then the install
procedure(s) should insert the argument until the issue(s) are remedied, at
which time the argument can then be removed.

Right, but that ends up special casing stuff, and you need to the
exact details _BEFORE_ hand for the install procedure to deal with
that, IE devices X/Y/Z have issue BLAH and you have to do ZYX to make
it boot properly, and frankly it would be less work to actually fix
the bug if people are interested in that particular device. As I've
stated before I am NOT interested in Exynos devices. The other option
is people like yourself who have the device and can verify the issue,
and verify when it's fixed, could do a small amount of documentation
so others are aware of what needs to be done.

If this was a product you were paying for and not a community lead
project your requests would be completely valid, but even though we
have 100s of people that contribute to Fedora ARM directly, and even
more I and others interact with in the upstream communities I am not
their manager and people will work on the things they want to work on
or they're employer is paying them to work on (or a combination of the
two).

From my point of view the Exynos devices are "best effort", I
personally don't have any devices to test, the Odroid manufacturers
generally don't give a shit about anything upstream and no one in the
community has stepped up to be the maintainer of the devices. So
basically from my point of view if there's a specific patch that can
be applied to fix a problem I will do so, and I did for F-27 for the
USB patch, but clearly no one tested it in a reasonable amount of
time, and I have no way of testing it myself so when I do that I have
to rely on people to test and report back yes/no, I don't have the
time to track and chase up each of the 1000s of the things I deal with
like this constantly so the people that care have to follow up.

It's very easy to say "I think this is what should happen" when you're
not the one that has to do the work. If you want to do the work and
step up and maintain the Exynos devices I'll happily assist, until
that point I'm sorry your experience isn't perfect but you do now have
a device that works.

Peter
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@list

R P Herrold

2017-11-30 15:59:34 UTC

Permalink

Post by Peter Robinson
Sure, and we have a wiki basically anyone can edit, and even pages to
https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices

I put an initial starter in place; my initial work-plan is to
simply work down through the RPi wiki-page and 'flesh it out'
as to the XU4, etc

https://fedoraproject.org/wiki/Architectures/ARM/exynos

Post by Peter Robinson
It's very easy to say "I think this is what should happen" when you're
not the one that has to do the work. If you want to do the work and
step up and maintain the Exynos devices I'll happily assist

I have both ODroid XU4 and HC1 kit, and know that I have hit
something of an issue running without an SD card, and rather
booting natively from the SATA interface. Another friend and
I are working through this issue, as the price point on the
(fanless, but with HUGE heat sink) HC1 hard to resist when
putting together a silent operation device

As I recall there was also a problem on the eMMC adapter, but
that is not my present focus (there are both a sub-adapter to
run through the SD card slot, as well as a native on-board
connector for just the eMMC card)

-- Russ herrold
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject.o

R P Herrold

2017-11-30 19:43:40 UTC

Permalink

Post by R P Herrold

Post by Peter Robinson
Sure, and we have a wiki basically anyone can edit, and even pages to

https://fedoraproject.org/wiki/Architectures/ARM/exynos

that looks fine. I have also both devices and I'm very interested
running fedora on it. If there is something I can help, please ask.

Hi, Andreas (and others watching via the mailing list):

If I was not sufficiently clear, _please_ join in, and help
'populate' that page. I have no desire to do all the work
single-handed ;)

1. Open in edit mode (so you may easily scrape
and paste from pre-marked-up content at:
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi

2. As applicable, transfer that scrap4ed content, stanza by
stanza, to:
https://fedoraproject.org/wiki/Architectures/ARM/exynos

3. Amend the content as needed. If something needs
verification or such, prefix that assertion sentence with:
FIXME: need to verify the frammish conflates into the
nebbish, and is fully functional

and note the need at a newly added stanza at the bottom of
the document, called:
= Open Issues =

4. As each stanza is completed. A stanza as used here is
that section within:
= Success report =

until the next:
= Open Issues =

5. Continue back to step 1, above, and move to the next
stanza, doing so until one exhausts that RPi page noted

---------------

6. Examine each successive vendor or SoC specific page after
the RPi one, and as new content or approaches are seen,
incorporate them into the 'Samsung EXYNOS based devices' page

7. Once step 6 is done, make sure all FIXME's in the
'Samsung EXYNOS' page are:
a. documented as to a solution
b. as applicable, filed as a bug in the Red Hat
Fedora Arm tracker, and the bug link noted in
the FIXME
c. as applicable, research in other venue, including
asking here, and leave notes as to 'work in process' near the
FIXME

8. Periodically, update status into this mailing list

-- Russ herrold
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedo

Peter Robinson

2018-01-08 08:25:18 UTC

Permalink

Post by R P Herrold

Post by Peter Robinson
Sure, and we have a wiki basically anyone can edit, and even pages to
https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices

I put an initial starter in place; my initial work-plan is to
simply work down through the RPi wiki-page and 'flesh it out'
as to the XU4, etc

It would be great if you could use the SoC device template for that,
the RPi FAQ is kind of special case and will also move over to that
template.

Post by R P Herrold
https://fedoraproject.org/wiki/Architectures/ARM/exynos

Often you'll need a small SD card to run u-boot and then from there
u-boot can boot the OS from the usb/sata interfaces

Post by R P Herrold
As I recall there was also a problem on the eMMC adapter, but
that is not my present focus (there are both a sub-adapter to
run through the SD card slot, as well as a native on-board
connector for just the eMMC card)
-- Russ herrold

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a

R P Herrold

2018-01-08 20:29:09 UTC

Permalink

Post by Peter Robinson
It would be great if you could use the SoC device template for that,
the RPi FAQ is kind of special case and will also move over to that
template.

to avoid chasing down the wrong alley, what is the specific
URL of the 'template' desired?

Post by Peter Robinson
Often you'll need a small SD card to run u-boot and then from there
u-boot can boot the OS from the usb/sata interfaces

* nod *

also, no worries about a preference for more hands over mote
hardware -- just wanted to make sure I was working to relieve
the correct constrained resource

Thanks

-- Russ herrold
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe sen

Stewart Samuels

2017-11-30 18:56:17 UTC

Permalink

Post by Peter Robinson

Good.

Post by Stewart Samuels
system still requires the "cpuidle.off=1" argument on the "append" line of
the extlinux.conf file to boot.

Why is this a problem?

Sure, and we have a wiki basically anyone can edit, and even pages to
https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices

Right, but that ends up special casing stuff, and you need to the
exact details _BEFORE_ hand for the install procedure to deal with
that, IE devices X/Y/Z have issue BLAH and you have to do ZYX to make
it boot properly, and frankly it would be less work to actually fix
the bug if people are interested in that particular device. As I've
stated before I am NOT interested in Exynos devices. The other option
is people like yourself who have the device and can verify the issue,
and verify when it's fixed, could do a small amount of documentation
so others are aware of what needs to be done.
If this was a product you were paying for and not a community lead
project your requests would be completely valid, but even though we
have 100s of people that contribute to Fedora ARM directly, and even
more I and others interact with in the upstream communities I am not
their manager and people will work on the things they want to work on
or they're employer is paying them to work on (or a combination of the
two).
From my point of view the Exynos devices are "best effort", I
personally don't have any devices to test, the Odroid manufacturers
generally don't give a shit about anything upstream and no one in the
community has stepped up to be the maintainer of the devices. So
basically from my point of view if there's a specific patch that can
be applied to fix a problem I will do so, and I did for F-27 for the
USB patch, but clearly no one tested it in a reasonable amount of
time, and I have no way of testing it myself so when I do that I have
to rely on people to test and report back yes/no, I don't have the
time to track and chase up each of the 1000s of the things I deal with
like this constantly so the people that care have to follow up.
It's very easy to say "I think this is what should happen" when you're
not the one that has to do the work. If you want to do the work and
step up and maintain the Exynos devices I'll happily assist, until
that point I'm sorry your experience isn't perfect but you do now have
a device that works.
Peter

Peter,

You asked me a simple question regarding whether or not adding the
cpuidle.off=1 argument was a problem, and I responded. I was not
expecting and I am not interested in a flame war or getting another
bashing and lecture as to your personal interests, as you have already
made everyone quite aware in a recent post. As I stated previously, I
try to help with things I can, when I can. And, I am grateful for the
community for any help provided. Period!

Stewart
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a

Gerald Henriksen

2017-12-01 14:04:51 UTC

Permalink

Post by Stewart Samuels
You asked me a simple question regarding whether or not adding the
cpuidle.off=1 argument was a problem, and I responded. I was not
expecting and I am not interested in a flame war or getting another
bashing and lecture as to your personal interests,

In fairness to Peter, I don't believe his intention (nor did I
perceive it as such) was for a flame war.

Nor was it a lecture about his personal interests.

Please also remember that in a lot of cases a reply is not just aimed
at you, but to the "silent" masses who are reading the mailing list
but not actively participating.

In shorter form, what I understood was:

a) given the lack of followed standards, and the attitudes of the SOC
vendors, these small ARM boards are a mess - not news to most people
who have been following the situation, but likely new information for
some.

b) pointing out that there is no paid person working for Fedora with a
lab full of all of these different boards - again, likely new
information to some.

c) that the Fedora ARM experience is directly connected with how much
effort the Fedora ARM community puts into it. In this case, yes that
cpuidle requirement likely should be documented, but ideally by
someone who actually has that SOC and thus can be sure that it is
actually required and (in an ideal world) periodically test any future
updates to see if it is still required and update the wiki if
necessary. As Peter does not have an Odroid, he is not the best
person to be doing that even if he did have the available time.

Thus, in general, and again not necessarily aimed at you:

I am sure that Peter would like the Fedora ARM experience to be
better, but if the community wants things to improve then it will be
necessary for the community to put in the effort in testing,
debugging, and documenting.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.f

R P Herrold

2017-12-01 16:27:26 UTC

Permalink

Post by Gerald Henriksen
necessary. As Peter does not have an Odroid, he is not the best
person to be doing that even if he did have the available time.

long ago, Red Hat staffers solicited help from a group called
'testers-list' of PCI IDs of video cards. The then maintainer
was:

Date: Fri, 19 Jan 2001 00:59:08 -0500 (EST)
From: "Mike A. Harris" <***@redhat.com>
Subject: Request #2: PCI device ID's for various cards

and I recall, at the time, sending a balky video card, itself,
to Mike, with no expectation of its return, so he could have
'hands on' to run down what was happening

Similarly during the Alpha port, Alan Cox (then at Red Hat)
received, with the understanding that hardware was never
returned once sent off, a box from Digital, for the porting
effort

Peter, if lack of a 'hands on testing candidate' as to the
ODroid HC1 (which seems to be a 'problem super-set' of the XU4)
is a problem, please let me know off list, and I can work out
getting one dispatched to you under a similar understanding.
I recall 'passing on taking delivery' of the then-hard to
obtain early RPi I was awarded by chance at the Blacksburg
Fedora event several years ago to a RH staffer in similar
fashion

-- Russ herrold
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t

Peter Robinson

2018-01-08 08:22:34 UTC

Permalink

Post by R P Herrold

Post by Gerald Henriksen
necessary. As Peter does not have an Odroid, he is not the best
person to be doing that even if he did have the available time.

long ago, Red Hat staffers solicited help from a group called
'testers-list' of PCI IDs of video cards. The then maintainer
Date: Fri, 19 Jan 2001 00:59:08 -0500 (EST)
Subject: Request #2: PCI device ID's for various cards
and I recall, at the time, sending a balky video card, itself,
to Mike, with no expectation of its return, so he could have
'hands on' to run down what was happening
Similarly during the Alpha port, Alan Cox (then at Red Hat)
received, with the understanding that hardware was never
returned once sent off, a box from Digital, for the porting
effort
Peter, if lack of a 'hands on testing candidate' as to the
ODroid HC1 (which seems to be a 'problem super-set' of the XU4)
is a problem, please let me know off list, and I can work out
getting one dispatched to you under a similar understanding.

While I appreciate the offer I would much prefer someone else taking
up the mantle and maintaining the device, I have more than I can deal
with already. Even better would be hardkernel or someone from samsung
actually testing upstream linus kernels on their devices and getting
fixes upstream there for the benefit of the entire community.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an e

Vince Geze

2017-12-06 14:36:14 UTC

Permalink

Post by Stewart Samuels
Hello Andreas
Sorry it took me so long to get back. I have just tested kernel
4.15.0-0.rc0.git7.2.fc28.armv7hl and can confirm that indeed, USB 3
devices are now recognized as is the onboard gigabit ethernet port.
However, the system still requires the "cpuidle.off=1" argument on the
"append" line of the extlinux.conf file to boot.
Regards,
Stewart

Dears,
Although I can confirm a working odroid XU4 system using rawhide, I still see some issues:
- ethernet is connected to USB 2
- USB 3 devices have a tendency being detected as USB 2 (usually need to unplug/reconnect several times to have it connect as USB 3)
- there seems to be a kernel bug during boot (check dmesg) which I suspect to be linked to cpu code
Can anyone check with "lsusb -t" how the ethernet is connected?
As a side note, the latest hardkernel image with kernel 4.14 seems not to have these issues, so they must have patched a bit differently...
Best regards,
Vince
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject

searider74

2017-09-19 11:32:07 UTC

Permalink

Wonderful! Â Thanks Peter.
Stewart

Sent from my T-Mobile 4G LTE Device

-------- Original message --------
From: Peter Robinson <***@gmail.com>
Date: 9/19/17 2:11 AM (GMT-08:00)
To: Stewart Samuels <***@gmail.com>
Cc: ***@rirasoft.de, ***@lists.fedoraproject.org, Dennis Gilmore <***@ausil.us>
Subject: Re: [fedora-arm] Re: Summary of Fedora on Odroid XU4

Post by Stewart Samuels
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
https://bugzilla.redhat.com/show_bug.cgi?id=1487006

Post by Stewart Samuels
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
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
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.
Â Â Â Â Â Â Â 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
Â Â Â Â Â Â Â 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".
----------------------------------------------------------------
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
_______________________________________________