Summary of Fedora on Odroid XU4

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

[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

On 08/30/2017 01:16 AM, [e-mail] wrote:
> Summary of Fedora on Odroid XU4
> 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.
> 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.
> 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

[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

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, [e-mail] wrote:
> > Summary of Fedora on Odroid XU4
> > 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.
> > 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.
> > 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

[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 
following link:

https://bugzilla.redhat.com/show_bug.cgi?id=1487006

Stewart

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, [e-mail] wrote:
> > > Summary of Fedora on Odroid XU4
> > > 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.
> > > 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.
> > > 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

[Peter Robinson]

On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels  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, [e-mail] wrote:
>
> Summary of Fedora on Odroid XU4
> 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.
> 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.
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Stewart Samuels]

Hello Peter,

On 09/19/2017 02:11 AM, Peter Robinson wrote:
> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels  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

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
> > 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, [e-mail] wrote:
> >
> > Summary of Fedora on Odroid XU4
> > 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.
> > 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.
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Peter Robinson]

On Mon, Oct 2, 2017 at 1:41 AM, Stewart Samuels  wrote:
> Hello Peter,
>
> On 09/19/2017 02:11 AM, Peter Robinson wrote:
> > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels 
> > 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
>
> 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
> > > 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, [e-mail] wrote:
> > >
> > > Summary of Fedora on Odroid XU4
> > > 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.
> > > 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.
> > > 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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]

[Stewart Samuels]

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

On 09/19/2017 02:11 AM, Peter Robinson wrote:
> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels  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, [e-mail] wrote:
> >
> > Summary of Fedora on Odroid XU4
> > 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.
> > 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.
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[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.
> 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 
> > 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, [e-mail] wrote:
> > >
> > > Summary of Fedora on Odroid XU4
> > > 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.
> > > 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.
> > > 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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]

[Richard Ryniker]

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

[Stewart Samuels]

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 
> > > 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, [e-mail] wrote:
> > > >
> > > > Summary of Fedora on Odroid XU4
> > > > 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.
> > > > 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.
> > > > 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 -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]

Summary for me:

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.

Thanks for the clarification of fact by Peter.

I want to provide help to the cummunity where I can.

Andreas

[Peter Robinson]

On Fri, Oct 13, 2017 at 12:49 PM,   wrote:
> Summary for me:
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Gerald Henriksen]

On Fri, 13 Oct 2017 00:30:00 +0100, you 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.
> 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.

[Peter Robinson]

On Fri, Oct 13, 2017 at 10:21 PM, Gerald Henriksen  wrote:
> On Fri, 13 Oct 2017 00:30:00 +0100, you 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.
> > 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.

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.

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

Thanks,
Stewart

On 10/14/2017 03:22 AM, Peter Robinson wrote:
> On Fri, Oct 13, 2017 at 10:21 PM, Gerald Henriksen  wrote:
> > On Fri, 13 Oct 2017 00:30:00 +0100, you 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.
> > > 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.
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Peter Robinson]

On Sat, Oct 14, 2017 at 11:29 PM, Stewart Samuels  wrote:
> 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
> Thanks,
> Stewart
>
> On 10/14/2017 03:22 AM, Peter Robinson wrote:
> > On Fri, Oct 13, 2017 at 10:21 PM, Gerald Henriksen 
> > wrote:
> > > On Fri, 13 Oct 2017 00:30:00 +0100, you 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.
> > > > 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.
> >
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> arm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Peter Robinson]

On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson  wrote:
> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels  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

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

[Stewart Samuels]

On 10/15/2017 01:54 AM, Peter Robinson wrote:
> On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson  wrote:
> > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels  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
>
> 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.

[Andreas Reschke]

Any Updates ?

with actuell Fedora 27 no USB3 is working.

[root@odroidh1 ~]# uname -a
Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC
2017 armv7l armv7l armv7l GNU/Linux
[root@odroidh1 ~]# lsusb
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
[root@odroidh1 ~]# lsblk
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 /
[root@odroidh1 ~]#

Am 15.10.2017 um 18:50 schrieb Stewart Samuels:
> On 10/15/2017 01:54 AM, Peter Robinson wrote:
> > On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson
> >  wrote:
> > > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels
> > >  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
> >
> > 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.

[Peter Robinson]

On Wed, Nov 15, 2017 at 9:54 AM, Andreas Reschke  wrote:
> 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
> [root@odroidh1 ~]# uname -a
> Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
> armv7l armv7l armv7l GNU/Linux
> [root@odroidh1 ~]# lsusb
> 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
> [root@odroidh1 ~]# lsblk
> 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 /
> [root@odroidh1 ~]#
>
> Am 15.10.2017 um 18:50 schrieb Stewart Samuels:
>
> On 10/15/2017 01:54 AM, Peter Robinson wrote:
>
> On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson 
> wrote:
>
> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels 
> 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
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[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

On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson  wrote:
> On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels<[e-mail]>  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

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

On 11/15/2017 02:18 AM, Peter Robinson wrote:
> On Wed, Nov 15, 2017 at 9:54 AM, Andreas Reschke  wrote:
> > 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
> > [root@odroidh1 ~]# uname -a
> > Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
> > armv7l armv7l armv7l GNU/Linux
> > [root@odroidh1 ~]# lsusb
> > 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
> > [root@odroidh1 ~]# lsblk
> > 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 /
> > [root@odroidh1 ~]#
> >
> > Am 15.10.2017 um 18:50 schrieb Stewart Samuels:
> >
> > On 10/15/2017 01:54 AM, Peter Robinson wrote:
> >
> > On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson 
> > wrote:
> >
> > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels 
> > 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
> >
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> arm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[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

On 11/15/2017 08:53 AM, Stewart Samuels wrote:
> 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
> On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson<[e-mail]>  wrote:
>
> > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels<[e-mail]>  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
> 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
>
>
> On 11/15/2017 02:18 AM, Peter Robinson wrote:
> > On Wed, Nov 15, 2017 at 9:54 AM, Andreas Reschke  wrote:
> > > 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
> > > [root@odroidh1 ~]# uname -a
> > > Linux odroidh1 4.13.12-300.fc27.armv7hl #1 SMP Wed Nov 8 18:03:47 UTC 2017
> > > armv7l armv7l armv7l GNU/Linux
> > > [root@odroidh1 ~]# lsusb
> > > 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
> > > [root@odroidh1 ~]# lsblk
> > > 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 /
> > > [root@odroidh1 ~]#
> > >
> > > Am 15.10.2017 um 18:50 schrieb Stewart Samuels:
> > >
> > > On 10/15/2017 01:54 AM, Peter Robinson wrote:
> > >
> > > On Tue, Sep 19, 2017 at 10:11 AM, Peter Robinson
> > > wrote:
> > >
> > > On Thu, Aug 31, 2017 at 5:27 AM, Stewart Samuels
> > > 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
> > >
> > > 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 [e-mail]
> > > To unsubscribe send an email [e-mail]
> >
> > arm mailing list [e-mail]
> > To unsubscribe send an email [e-mail]

[Andreas Reschke]

Am 15.11.2017 um 23:02 schrieb 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
>
> On 11/15/2017 08:53 AM, Stewart Samuels wrote:
> > 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,

with the actuell kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl it seems to work:

[root@odroidh1 ~]# lsusb
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
[root@odroidh1 ~]# lsblk
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 /
[root@odroidh1 ~]#

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

[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

On 11/21/2017 08:49 AM, Andreas Reschke wrote:
> Am 15.11.2017 um 23:02 schrieb 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
> >
> > On 11/15/2017 08:53 AM, Stewart Samuels wrote:
> > > 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,
>
> with the actuell kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl it seems to work:
>
> [root@odroidh1 ~]# lsusb
> 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
> [root@odroidh1 ~]# lsblk
> 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 /
> [root@odroidh1 ~]#
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Peter Robinson]

On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels  wrote:
> 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

Good.
> system still requires the "cpuidle.off=1" argument on the "append" line of
> the extlinux.conf file to boot.

Why is this a problem?
> Regards,
> Stewart
>
> On 11/21/2017 08:49 AM, Andreas Reschke wrote:
> > Am 15.11.2017 um 23:02 schrieb 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
> > >
> > > On 11/15/2017 08:53 AM, Stewart Samuels wrote:
> > > > 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,
> >
> > with the actuell kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl it seems to work:
> >
> > [root@odroidh1 ~]# lsusb
> > 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
> > [root@odroidh1 ~]# lsblk
> > 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 /
> > [root@odroidh1 ~]#
> >
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> arm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Stewart Samuels]

On 11/28/2017 01:25 AM, Peter Robinson wrote:
> On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels  wrote:
> > 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
>
> Good.
> > 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.
> > Regards,
> > Stewart
> >
> > On 11/21/2017 08:49 AM, Andreas Reschke wrote:
> > > Am 15.11.2017 um 23:02 schrieb 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
> > > >
> > > > On 11/15/2017 08:53 AM, Stewart Samuels wrote:
> > > > > 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,
> > >
> > > with the actuell kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl it seems to work:
> > >
> > > [root@odroidh1 ~]# lsusb
> > > 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
> > > [root@odroidh1 ~]# lsblk
> > > 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 /
> > > [root@odroidh1 ~]#
> > >
> > > 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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > arm mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Peter Robinson]

> > On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels 
> > wrote:
> > > 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
> >
> > Good.
> > > 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.

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

Summary of Fedora on Odroid XU4 [and related HC1]

[R P Herrold]

On Thu, 30 Nov 2017, Peter Robinson wrote:
> 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_Devi...

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

Summary of Fedora on Odroid XU4 [and related HC1]

[Andreas Reschke]

Am 30.11.2017 um 16:59 schrieb R P Herrold:
> On Thu, 30 Nov 2017, Peter Robinson wrote:
> > 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_Devi...
>
> 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
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

Hello Rus,

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.

Andreas

Summary of Fedora on Odroid XU4 [and related HC1]

[R P Herrold]

On Thu, 30 Nov 2017, Andreas Reschke wrote:
> Am 30.11.2017 um 16:59 schrieb R P Herrold:
> > On Thu, 30 Nov 2017, Peter Robinson wrote:
> > > 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/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

Summary of Fedora on Odroid XU4 [and related HC1]

[Peter Robinson]

On Thu, Nov 30, 2017 at 3:59 PM, R P Herrold  wrote:
> On Thu, 30 Nov 2017, Peter Robinson wrote:
> > 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_Devi...
>
> 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.
> https://fedoraproject.org/wiki/Architectures/ARM/exynos
> > 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

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

Summary of Fedora on Odroid XU4 [and related HC1]

[R P Herrold]

On Mon, 8 Jan 2018, Peter Robinson wrote:
> 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?
> 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

[Stewart Samuels]

On 11/30/2017 12:37 AM, Peter Robinson wrote:
> > > On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels 
> > > wrote:
> > > > 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
> > >
> > > Good.
> > > > 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.
>
> 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_Devi...
> > 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

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

[Gerald Henriksen]

On Thu, 30 Nov 2017 10:56:17 -0800, you wrote:
> 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.

[R P Herrold]

On Fri, 1 Dec 2017, Gerald Henriksen wrote:
> 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" 
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

[Peter Robinson]

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

[Vince Geze]

> 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
>
> On 11/21/2017 08:49 AM, Andreas Reschke wrote:

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

[Dennis Gilmore]

El mié, 30-08-2017 a las 10:16 +0200, [e-mail] escribió:
> Summary of Fedora on Odroid XU4
> 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
> 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

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