Hi all,
About USB3, seem that Fedora w/kernel 5.3.7-301 see usb 3 port as usb
1.1 !!!!
See below, the first BUS row is very clear.
lsusb -vvv
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ohci_hcd
iProduct 2 Generic Platform OHCI controller
iSerial 1 ff5d0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0012
No power switching (usb 1.0)
No overcurrent protection
bPwrOn2PwrGood 2 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 ff5c0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 dwc2_hsotg
iProduct 2 DWC OTG Controller
iSerial 1 ff580000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0000
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Oblivious, a "modprobe xhci_hcd" does not fix the problem.
Any ideas?
Nigel, your Arch kernel does support Rock64's USB3 well? Have you tried
a heavy write on it? If yes, does it hangs?
Best regards,
Agharta
Il 28/11/19 13:58, agharta82(a)gmail.com ha scritto:
Hi Benson,
see below
Il 28/11/19 13:19, Benson Muite ha scritto:
>
>
> On 11/28/19 2:37 PM, agharta82(a)gmail.com wrote:
>>
>> Hi Benson,
>>
>> I'm really new in Pagure.
>>
> So am I. It seemed ok, once uploaded an ssh key, could then use
> command line git interface. Web interface seems limited compared to
> Gitlab/Github, but it is better integrated with Fedora infrastructure.
Ok, I have to try it. Thanks for your feedback.
>>
>> Feel free to edit and make pull request. I don't wont to make errors
>> or create confusions.
>>
> Git keeps history, so errors can be undone. The more people that can
> add to code the better. It would be of interest to learn your
> thoughts on Rock64 board. Price point seems similar to Raspberry Pi.
> Are you using USB to attach an external hard drive for Nextcloud?
>
Price is ok, board seems too.....but there are some problems:
* in debian-like images the network hangs if rebooted. Performance
is very good.
https://wiki.pine64.org/index.php/ROCK64_Software_Release#Linux_Image_Rel...
* in fedora 31 minimal have bad performance (ssh & console for
example . I need to do a cpu/sd/memory test in both OSes to create
a valid comparison)
* in debian-like images, if I connect a device to usb3 port it
hangs after a bit....I have not yet figured out if it is a
hardware or software problem....investigation is needed. In any
case a ticket is already open
https://github.com/ayufan-rock64/linux-build/issues/112
* in fedora usb3 does not work.....
* My final target is to boot Rock64 via sd-card and connect 2 HDD
in raid-1 mode through usb 3 (and relative hub) and store
Nextcloud data into raid-1 fs.
* My oniric target is to use that board with IP-cameras and
Zoneminder too....but for now I would be satisfied with the
previous point.
Actually I am getting familiar with fedora 31 aarch64: it is quite
different form x64 version, dnf update gives me errors about protected
packages (......).
> Finally, there is a file socs.d/Rockchips-ARMv8, which would fit
> description for rk3328 (
https://en.wikipedia.org/wiki/Rockchip), but
> the specifications there are different than what you used. Maybe
> rk3328 should be Rockchip-rk3328?
>
Seek values provided by socs.d/Rockchips-ARMv8 seems not working for
me, but beacuse I can't see serial console I don't know why....
In any case spl.img file is not availabe in fedora .xz build.
I have used the default seek values form main Rockchip guide:
http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
> Some of the other files, such as socs.d/exynos5 and socs.d/st have a
> few more steps than the others. Downloading spi boot binaries is not
> so great in Fedora as the build process is not under Fedora control.
> Not sure what the best solution is for this.
>
Actually Fedora can run into Rock64 IF AND ONLY IF spi boot is erased.
I think that an spi-compatibe image should be added in fedora (as
debian do). If yes, boot could be executed directy from usb disk (and
raid-1 disks I hope).
>
> It may be helpful to check the Fedora list guidelines,
>
https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting
> is discouraged, though I sometimes find I do it.
>
> Thanks for your contributions. I look forward to trying out Rock64
> board in the future.
>
Thank you for your patience, I'll keep you informed about problems &
resolutions.
My best cheers,
Agharta
>> Thank you.
>>
>> Best regards,
>>
>> Agharta
>>
>>
>> Il 28/11/19 12:24, Benson Muite ha scritto:
>>>
>>> On 11/27/19 5:22 PM, Benson Muite wrote:
>>>>
>>>>
>>>> On 11/27/19 5:00 PM, Nigel Sollars wrote:
>>>>> Well done!,
>>>>>
>>>>> I was waiting to see how this one went. in the meantime Arch
>>>>> pushed out a 5.4.0-1 kernel,
>>>>>
>>>>> archrock 5.4.0-1-ARCH #1 SMP
>>>>>
>>>>> [ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc
>>>>> version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019
>>>>> [ 0.000000] Machine model: Pine64 Rock64
>>>>>
>>>>>
>>>>> Looks like the Lima driver got some work ( more info inside dmesg
>>>>> ) among other cleanups
>>>>>
>>>>> Nige
>>>>>
>>>>> On Wed, Nov 27, 2019 at 8:43 AM agharta82(a)gmail.com
>>>>> <mailto:agharta82@gmail.com> <agharta82(a)gmail.com
>>>>> <mailto:agharta82@gmail.com>> wrote:
>>>>>
>>>>> OH GUYS! WHAT A BEAUTIFUL DAY!!!!!
>>>>>
>>>>> Finally I've found the solution!
>>>>>
>>>> Excellent
>>>>>
>>>>> So,*_first for all SPI flash should be ERASED_*: fedora
>>>>> aarch64 does not have spi boot images (at 2019-11-27). To
>>>>> erase spi follow this link:
>>>>>
https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-r...
>>>>>
>>> It may be worth opening an issue in Pagure for this, not sure how
>>> it should be best included in the arm installer for Fedora.
>>>>>
>>>>> Second, install fedora-arm-installer package, then create a
>>>>> new ad-hoc script; this script for rock64 that I have made
>>>>> works well:
>>>>>
>>>>> File is placed into folder
>>>>> /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
>>>>>
>>>
>>> Made one change, put file in socs.d/rk3328 and added a softlink
>>> from boards.d/rock64 to socs.d/rk3328
>>>
>>> Not sure if names I choose are the most appropriate.
>>>
>>>>> # write uboot
>>>>> echo "= Writing idbloader.img for $TARGET .... on media
$MEDIA"
>>>>> dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA
>>>>> seek=64; sync; sleep 5
>>>>> echo "= Writing u-boot FIT image for $TARGET .... on media
>>>>> $MEDIA"
>>>>> dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA
>>>>> seek=16384; sync; sleep 5
>>>>> # set console for Rockchips
>>>>> SYSCON=ttyS2,115200n8
>>>>>
>>>>>
>>>>> I'm not sure about SYSCON because my serial adapter does not
>>>>> works at 1500000 baudrate, so I can't test it. I have leaved
>>>>> it at default. Hope someone can test and correct it if required.
>>>>>
>>>>> References to find right dd seek:
>>>>>
http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
>>>>>
>>>>>
>>>>> Next, download fedora aarch64 31 minimal xz image and:
>>>>>
>>>>> arm-image-installer
>>>>> --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs
>>>>> --media=/dev/THE_SD_MEDIA --target=rock64-rk3328
>>>>> --addconsole (and other stuff)
>>>>>
>>>>> Insert sd into Rock64 and power on!
>>>>>
>>>>> Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!!
>>>>>
>>>>> Wait a bit (by default search for ipv6 ip).
>>>>>
>>>>> Connect Keyboard and follow on screen setup to set root
>>>>> password, Timezone etc...
>>>>>
>>>>>
>>>>> AT THE END ALL WORKS!!!!!
>>>>>
>>>> Great
>>>>>
>>>>>
>>>>> Benson, feel free to integrate it to Pagure, and make a new
>>>>> fedora-arm-image-installer package.
>>>>>
>>>> Can start on this, though I do not have this board, so cannot
>>>> really test it. Let me know if you have used Pagure or Git,
>>>> usually it is good for the person who found the solution to add it
>>>> to the repository. If still want me to do it, can do so.
>>>
>>> It seems you already forked the repository, so feel free to make
>>> your additions there. There is a pull request at:
>>>
>>>
https://pagure.io/arm-image-installer/pull-requests
>>>
>>>>>
>>>>> Really guys, I am very very very happy!
>>>>>
>>>>>
>>>>> Have a fantastic day!!!
>>>>>
>>>>> Agharta
>>>>>
>>>>>
>>>>>
>>>>>