On 25/09/2019 16:41, Fabian Vogt wrote:
> 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 the
>>>> 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 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
>
> 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.
I'm working on some patches for a single binary for RPi3/4, stay tuned :)
Regards,
Matthias
>
> Cheers,
> Fabian
>
>> Cheers,
>> Fabian
>>
>>> Regards,
>>> Matthias
>>>
>>>>
>>>> Cheers,
>>>> Fabian
>>>>
>>>>> Regards,
>>>>> Matthias
>>>>>
>>>>> [1] https://build.opensuse.org/project/monitor/home:mbrugger:branches:RPi4
>>>>>
>>>>>> Let’s have a lot of fun! :D
>>>>>>
>>>>>>
>>>>>> [1]:
>>>>>> https://forums.opensuse.org/showthread.php/536541-Can-Raspberry-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-raspberry-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: [email protected]
To contact the owner, e-mail: [email protected]
