Hi, Am Donnerstag, 26. September 2019, 09:36:29 CEST schrieb Fabian Vogt:
Hi,
Am Mittwoch, 25. September 2019, 19:01:29 CEST schrieb Guillaume Gardet:
-----Original Message----- From: Fabian Vogt <fvogt@suse.de> Sent: 25 September 2019 08:29 To: opensuse-arm@opensuse.org Cc: Guillaume Gardet <Guillaume.Gardet@arm.com>; Matthias Brugger <mbrugger@suse.com>; Linux Kamarada <linuxkamarada@gmail.com>; Nicolas Saenz Julienne <nsaenzjulienne@suse.com>; nd <nd@arm.com> Subject: Re: [opensuse-arm] Raspberry Pi 4 Model B
Hi,
Hi,
-----Original Message----- From: Fabian Vogt <fvogt@suse.de> Sent: 25 September 2019 07:42 To: opensuse-arm@opensuse.org Cc: Matthias Brugger <mbrugger@suse.com>; Linux Kamarada <linuxkamarada@gmail.com>; Nicolas Saenz Julienne <nsaenzjulienne@suse.com> Subject: Re: [opensuse-arm] Raspberry Pi 4 Model B
Hi,
Am Mittwoch, 25. September 2019, 13:43:44 CEST schrieb Fabian Vogt:
Hi,
Am Mittwoch, 25. September 2019, 13:16:37 CEST schrieb Matthias Brugger: > > On 25/09/2019 11:57, Fabian Vogt wrote: > > Hi, > > > > Am Dienstag, 24. September 2019, 16:49:42 CEST schrieb Matthias Brugger: > >> Hi, > >> > >> On 24/09/2019 13:24, Linux Kamarada wrote: > >>> Hi, everyone! > >>> > >>> AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. > >>> [1] > >>> > >>> I’ve bought that board, I know the very basics on how to use > >>> it [2] and I want to help to port openSUSE to it. How can I start? > >>> > >> > >> I'm working on some (still hacky) support for RPi4. > >> You can find the JeOS image in my home project [1]. > >> Beware that I was able to break the build of U-Boot yesterday. > >> I'll try to fix this tonight. > > > > I just gave that image a try and after a while staring at a > > console with no activity I noticed that it's the JeOS with > > jeos-firstboot, so I had to remove "console=tty" to actually > > see anything. Using the HDMI console won't really work without USB support. > > Why? HDMI output should work.
Yes, but without any ability for interaction not really useful.
> > Also, chrony-wait should be disabled, it delays booting by > > 10min as no network is currently working. > > Yes, networking is on my list. > > > What doesn't work: > > - USB (expected), but the OTG port seems to be available. It's > > forced to host > > mode by the kernel though as gadget support is not enabled > > - WiFi: brcmfmac: brcmf_sdio_htclk: HT Avail timeout > > (1000000): clkctl 0x50 > > I see that you force-disabled WiFi stuff in JeOS.kiwi, I had to copy over
> > firmware manually > > Does it work reliably? I heard that it has some hick-ups.
It doesn't work at all here, it fails because of the mentioned timeout.
> > - Ethernet: Gets detected just fine, but when actually sending packets
Am Mittwoch, 25. September 2019, 17:01:16 CEST schrieb Guillaume Gardet: the the
> > kernel freezes (sometimes with > > NETDEV WATCHDOG: eth0 (bcmgenet): transmit queue 1 timed > > out) > > - Sometimes the UART (clock?) glitches and there's garbled > > text > > Really? Did you change anything in the config.txt? I haven't > experienced this up to now.
Nope. I see it occasionally after between grub and the login prompt. I can't 100% rule out a bad connection, but as it doesn't glitch out after logging in at all I think that's unlikely.
> > What does work: > > - u-boot, grub, kernel, sd card, serial > > - I/O activity LED :D > > - cpufreq: Speed of "bc" corresponds roughly to CPU frequency > > > > So very nice progress already! > > Thanks :) > > > I'll try to build a kernel with dwc2 peripheral support, maybe that's enough. > > Probably not though, considering it's USB-C... > > That's not enough. Nicolas is working on some patches to enable > PCI, which is needed by USB.
For the USB-A ports, yes. Also for USB-C which is connected to the dwc2 which the kernel already initializes properly?
My kernel-default wasn't picked up by OBS yet for the last three hours :-/
Success! It works fine with a USB-C -> USB-A cable. Run:
-CONFIG_USB_DWC2_HOST=y +# CONFIG_USB_DWC2_HOST is not set -# CONFIG_USB_DWC2_DUAL_ROLE is not set +CONFIG_USB_DWC2_DUAL_ROLE=y
Could you send a patch to get this into openSUSE/SUSE kernels configs (master, stable, 15.2, etc.), please?
I noticed that dual-role modes were already enabled for dwc2+dwc3 on armv6+armv7. Pull requests to those three branches are sent.
Thanks a lot!
Got merged meanwhile, but apparently not synced to kernel.opensuse.org yet.
Got merged already:
Looks like I just hit an interesting bug in KMail. I started to write a response but had to log out and back in before I was done, so I saved a draft with the "Got merged already:" and "Currently SLE has CONFIG_USB_GADGET=n." sentences. After logging back in and opening the draft, those sentences were missing so I just wrote them again. Apparently they reappeared in the sent mail, for some reason... Cheers, Fabian
SLES doesn't support USB gadget mode AFAIK, so I didn't do anything there.
Hmm, looks like it should be changed, no?
SLE has CONFIG_USB_GADGET=n, so doing that would be a rather big change which needs discussion. It's not just a module which can be marked as unsupported. I don't know whether any platform currently supported by SLE even has USB device controllers.
Cheers, Fabian
Currently SLE has CONFIG_USB_GADGET=n.
Cheers, Fabian
Cheers, Guillaume
I guess that's also how this ended up being host-only for arm64.
Cheers, Fabian
Thanks, Guillaume
modprobe libcomposite u_ether mount none -t configfs /mnt cd /mnt/usb_gadget mkdir g1 cd g1 mkdir configs/c.1 functions/eem.usb0 ln -s functions/eem.usb0 configs/c.1/ echo fe980000.usb > UDC
Forward a network connection, then:
echo "BOOTPROTO=dhcp" > /etc/sysconfig/network/ifcfg-usb0 ifup usb0
and you can ssh onto the pi4 and download stuff.
localhost:~ # hdparm -tT /dev/mmcblk1 /dev/mmcblk1: Timing cached reads: 1632 MB in 2.00 seconds = 816.32 MB/sec HDIO_DRIVE_CMD(identify) failed: Invalid argument Timing buffered disk
reads:
126 MB in 3.01 seconds = 41.90 MB/sec
I played around with some other programs and it seems like CPU performance has roughly doubled compared to a 3B+. Even over X11 forwarding applications run very smoothly.
On my wish list is now to have u-boot use the device tree from the firmware for its own initialization as well, so that hardcoding of addresses isn't necessary anymore. That way we wouldn't need a new u-boot-rpi4 flavor and new JeOS flavors installing it instead of u-boot-rpi3.
Cheers, Fabian
Cheers, Fabian
> Regards, > Matthias > > > > > Cheers, > > Fabian > > > >> Regards, > >> Matthias > >> > >> [1] > >> https://build.opensuse.org/project/monitor/home:mbrugger:bran > >> ches > >> :RPi4 > >> > >>> Let’s have a lot of fun! :D > >>> > >>> > >>> [1]: > >>> https://forums.opensuse.org/showthread.php/536541-Can-Raspbe > >>> rry- Pi-4-run-openSUSE-LEAP-15-1/ > >>> > >>> https://www.reddit.com/r/openSUSE/comments/c6xvnr/raspberry_ > >>> pi_4 > >>> / > >>> > >>> https://www.raspberrypi.org/forums/viewtopic.php?t=244248 > >>> > >>> [2]: > >>> https://kamarada.github.io/pt/2019/09/20/primeiros-passos-no > >>> -ras pberry-pi-com-noobs-e-raspbian/ (in Brazilian > >>> Portuguese, but English translation is on the way) > >>> > >>> > >>> Antonio > >>> The Linux Kamarada Project > >>> http://kamarada.github.io/
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org