|
Post by mobluse on Feb 20, 2021 5:58:00 GMT
Do you need to use the A port on the back or could you use the power port? It's easier to find microUSB to A-USB cables, than A to A cables.
I don't have any computer with ordinary Ubuntu installed ─ only Lubuntu 18.04, but I could create a Live USB stick with Ubuntu.
I noticed that I could power a Raspberry Pi Zero WH from the back port connected to the data port of the RPi while THEVIC20 was powered from the power port. That means the Raspberry Pi Zero WH could be the computer sharing its network (provided no OTG problems arise) to e.g. THEVIC20. The RPi is powered even if THEVIC20 is off.
I could not power THEVIC20 from the RPi connected to the USB A port on the back. There might be some current limitation from the RPi data port.
Does XWM use the internal Linux kernel? Why is that? Could one not have a Linux kernel on the USB stick?
|
|
|
Post by jj0 on Feb 20, 2021 9:43:15 GMT
Do you need to use the A port on the back or could you use the power port? It's easier to find microUSB to A-USB cables, than A to A cables. You need to use the USB Type A port as that is the one that supports OTG switching between Host mode and Client mode. Note you can still power THE64 from the power port.Lubuntu is based on Ubuntu, if they use the same Network Manager then it should still work OK.This is actually quite a cool idea. You could power the Pi and THE64 from e.g. a dual-port USB PSU so you don't have power issues and use the USB Type A port just for the network connection. You could even build the Pi into the case and connect it to the THE64's USB Type A and power port internally.Yes it does as that is already running. There is a method (called kexec) to replace a running kernel with a new one but that doesn't work on THE64 I think. And as the standard THE64 doesn't boot from USB currently the only way to change the kernel is to install a new one in nanda. This is certainly possible but then you have to consider whether you want to risk that. I've done it with my THE64's, e.g. my Mini now first checks if there's a kernel on a USB drive and if do loads that. I will publish the method on the forum some time when I have it working for the Maxi/VIC-20 as well.
|
|
|
Post by MeneerJansen on Feb 20, 2021 10:50:16 GMT
I agree you can make changes to XWM if you mount the rootfs as rw. But did you install those themes with apt, apt-get or dpkg, or in another way? I mounted the "rootfs.img" file on my Linux computer. Like described in this here topic. Then I probably did ye olde from the command line: apt-get install I searched for packages apt-cache search package_name
The standard theme looks like Windows 95, I installed something newer. This is my short "tips n' hints" file on it:
|
|
|
Post by jj0 on Feb 20, 2021 13:15:35 GMT
I agree you can make changes to XWM if you mount the rootfs as rw. But did you install those themes with apt, apt-get or dpkg, or in another way? I mounted the "rootfs.img" file on my Linux computer. Like described in this here topic. Then I probably did ye olde from the command line: apt-get install I searched for packages apt-cache search package_name
The standard theme looks like Windows 95, I installed something newer. This is my short "tips n' hints" file on it: Yes, if you mount it on your Linux computer you won't experience the issue, because then you are using the kernel from that computer. It's only when you run it you run it from THE64 that you will have the issue.
|
|
|
Post by mobluse on Feb 22, 2021 1:54:59 GMT
Do you need to use the A port on the back or could you use the power port? It's easier to find microUSB to A-USB cables, than A to A cables. You need to use the USB Type A port as that is the one that supports OTG switching between Host mode and Client mode. Note you can still power THE64 from the power port.Lubuntu is based on Ubuntu, if they use the same Network Manager then it should still work OK.This is actually quite a cool idea. You could power the Pi and THE64 from e.g. a dual-port USB PSU so you don't have power issues and use the USB Type A port just for the network connection. You could even build the Pi into the case and connect it to the THE64's USB Type A and power port internally.Yes it does as that is already running. There is a method (called kexec) to replace a running kernel with a new one but that doesn't work on THE64 I think. And as the standard THE64 doesn't boot from USB currently the only way to change the kernel is to install a new one in nanda. This is certainly possible but then you have to consider whether you want to risk that. I've done it with my THE64's, e.g. my Mini now first checks if there's a kernel on a USB drive and if do loads that. I will publish the method on the forum some time when I have it working for the Maxi/VIC-20 as well. I don't have an A to A cable, but I got THEVIC20 RNDIS to register in dmesg on Raspberry Pi Zero W: [ 3195.495006] Indeed it is in host mode hprt0 = 00021501 [ 3195.774837] usb 1-1: new high-speed USB device number 4 using dwc_otg [ 3195.775097] Indeed it is in host mode hprt0 = 00001101 [ 3196.085772] usb 1-1: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 2.33 [ 3196.085810] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 3196.085849] usb 1-1: Product: Android [ 3196.085866] usb 1-1: Manufacturer: USB Developer [ 3196.085881] usb 1-1: SerialNumber: 20080411 [ 3196.121175] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-20980000.usb-1, RNDIS device, d2:67:4c:b1:7d:fe On THEVIC20 I can type dhclient rndis0. I'm connected to the Raspberry Pi Zero W from a Raspberry Pi 4B. Now I only have to figure out how I manually can configure the RPi0 to share its network to USB.
|
|
|
Post by jj0 on Feb 22, 2021 7:43:45 GMT
You need to use the USB Type A port as that is the one that supports OTG switching between Host mode and Client mode. Note you can still power THE64 from the power port.Lubuntu is based on Ubuntu, if they use the same Network Manager then it should still work OK.This is actually quite a cool idea. You could power the Pi and THE64 from e.g. a dual-port USB PSU so you don't have power issues and use the USB Type A port just for the network connection. You could even build the Pi into the case and connect it to the THE64's USB Type A and power port internally.Yes it does as that is already running. There is a method (called kexec) to replace a running kernel with a new one but that doesn't work on THE64 I think. And as the standard THE64 doesn't boot from USB currently the only way to change the kernel is to install a new one in nanda. This is certainly possible but then you have to consider whether you want to risk that. I've done it with my THE64's, e.g. my Mini now first checks if there's a kernel on a USB drive and if do loads that. I will publish the method on the forum some time when I have it working for the Maxi/VIC-20 as well. I don't have an A to A cable, but I got THEVIC20 RNDIS to register in dmesg on Raspberry Pi Zero W: [ 3195.495006] Indeed it is in host mode hprt0 = 00021501 [ 3195.774837] usb 1-1: new high-speed USB device number 4 using dwc_otg [ 3195.775097] Indeed it is in host mode hprt0 = 00001101 [ 3196.085772] usb 1-1: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 2.33 [ 3196.085810] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 3196.085849] usb 1-1: Product: Android [ 3196.085866] usb 1-1: Manufacturer: USB Developer [ 3196.085881] usb 1-1: SerialNumber: 20080411 [ 3196.121175] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-20980000.usb-1, RNDIS device, d2:67:4c:b1:7d:fe On THEVIC20 I can type dhclient rndis0. I'm connected to the Raspberry Pi Zero W from a Raspberry Pi 4B. Now I only have to figure out how I manually can configure the RPi0 to share its network to USB. Do you get an IP address on THEVIC20? If so then you're halfway there. Remember that (unless your Pi Zero acts as DNS server) you need to set a suitable DNS server in /etc/resolv/conf. Also the Pi Zero needs to act as an IP router. If you don't get an IP address you can try to create a bridge between the Pi's wlan0 and it's usb0. Then run dhclient on THE64 and you should get an IP address and nameserver assigned from you internet router. For the Pi to have IP connectivity itself you have to run dhclient on the bridge interface as well. Using the Pi Zero (or any Pi) has the advantage you can use a normal micro-USB to USB data cable.
|
|
|
Post by mobluse on Feb 23, 2021 1:43:47 GMT
I don't have an A to A cable, but I got THEVIC20 RNDIS to register in dmesg on Raspberry Pi Zero W: [ 3195.495006] Indeed it is in host mode hprt0 = 00021501 [ 3195.774837] usb 1-1: new high-speed USB device number 4 using dwc_otg [ 3195.775097] Indeed it is in host mode hprt0 = 00001101 [ 3196.085772] usb 1-1: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 2.33 [ 3196.085810] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 3196.085849] usb 1-1: Product: Android [ 3196.085866] usb 1-1: Manufacturer: USB Developer [ 3196.085881] usb 1-1: SerialNumber: 20080411 [ 3196.121175] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-20980000.usb-1, RNDIS device, d2:67:4c:b1:7d:fe On THEVIC20 I can type dhclient rndis0. I'm connected to the Raspberry Pi Zero W from a Raspberry Pi 4B. Now I only have to figure out how I manually can configure the RPi0 to share its network to USB. Do you get an IP address on THEVIC20? If so then you're halfway there. Remember that (unless your Pi Zero acts as DNS server) you need to set a suitable DNS server in /etc/resolv/conf. Also the Pi Zero needs to act as an IP router. If you don't get an IP address you can try to create a bridge between the Pi's wlan0 and it's usb0. Then run dhclient on THE64 and you should get an IP address and nameserver assigned from you internet router. For the Pi to have IP connectivity itself you have to run dhclient on the bridge interface as well. Using the Pi Zero (or any Pi) has the advantage you can use a normal micro-USB to USB data cable. From Raspberry Pi Zero starting with end of dmesg output. I got an IP-number I could ping from RPi0, but `dhclient rndis0` on THEVIC20 doesn't give an IP-number, but I've not configured a bridge. [ 1619.735163] Indeed it is in host mode hprt0 = 00021501 [ 1620.015031] usb 1-1: new high-speed USB device number 3 using dwc_otg [ 1620.015277] Indeed it is in host mode hprt0 = 00001101 [ 1620.326008] usb 1-1: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 2.33 [ 1620.326047] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 1620.326065] usb 1-1: Product: Android [ 1620.326080] usb 1-1: Manufacturer: USB Developer [ 1620.326115] usb 1-1: SerialNumber: 20080411 [ 1620.355104] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-20980000.usb-1, RNDIS device, 0a:49:21:9b:f1:ab pi@BoincPi0:~ $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:f2:20:d6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.102/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0 valid_lft 84672sec preferred_lft 73872sec inet6 fe80::100d:b9b4:4d2:7a12/64 scope link valid_lft forever preferred_lft forever 4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 0a:49:21:9b:f1:ab brd ff:ff:ff:ff:ff:ff inet 169.254.162.119/16 brd 169.254.255.255 scope global noprefixroute usb0 valid_lft forever preferred_lft forever inet6 fe80::fa0:b27f:bd01:557d/64 scope link valid_lft forever preferred_lft forever pi@BoincPi0:~ $ ping 169.254.162.119 PING 169.254.162.119 (169.254.162.119) 56(84) bytes of data. 64 bytes from 169.254.162.119: icmp_seq=1 ttl=64 time=0.238 ms 64 bytes from 169.254.162.119: icmp_seq=2 ttl=64 time=0.239 ms 64 bytes from 169.254.162.119: icmp_seq=3 ttl=64 time=0.236 ms ^C --- 169.254.162.119 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 36ms rtt min/avg/max/mdev = 0.236/0.237/0.239/0.017 ms
I now have a working USB A to A cable and could connect THEVIC20 to a EeePC 900 with Lubuntu. THEVIC20 is powered from the Eee PC 900 only. I have shared to other computers all ethernet ports since I don't now which one is usb0, but I have no ethernet cable connected. The WiFi uses DHCP. I have the same problem as with RPi0. I get an IP number on the Eee PC, but not on THEVIC20 using `dhclient rndis0`. [ 1590.004163] usb 1-2: new high-speed USB device number 6 using ehci-pci [ 1590.160945] usb 1-2: New USB device found, idVendor=18d1, idProduct=0001 [ 1590.160953] usb 1-2: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 1590.160957] usb 1-2: Product: Android [ 1590.160962] usb 1-2: Manufacturer: USB Developer [ 1590.160966] usb 1-2: SerialNumber: 20080411 [ 1590.170151] rndis_host 1-2:1.0 usb0: register 'rndis_host' at usb-0000:00:1d.7-2, RNDIS device, 76:6e:c8:c3:3f:e7 [ 1590.446770] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready [ 1635.539209] perf: interrupt took too long (3949 > 3933), lowering kernel.perf_event_max_sample_rate to 50500 pi@EeePC900:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 00:22:15:5b:63:36 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0f:54:16:1c:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.148/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0 valid_lft 83149sec preferred_lft 83149sec inet6 fe80::9bd5:48c9:8bac:c811/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:af:c6:fd:b7 brd ff:ff:ff:ff:ff:ff inet 192.168.1.143/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan1 valid_lft 82303sec preferred_lft 82303sec inet6 fe80::e682:a410:145f:c74d/64 scope link noprefixroute valid_lft forever preferred_lft forever 6: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 76:6e:c8:c3:3f:e7 brd ff:ff:ff:ff:ff:ff inet 10.42.0.1/24 brd 10.42.0.255 scope global noprefixroute usb0 valid_lft forever preferred_lft forever inet6 fe80::a909:f21b:131d:242a/64 scope link noprefixroute valid_lft forever preferred_lft forever pi@EeePC900:~$ ping 10.42.0.1 PING 10.42.0.1 (10.42.0.1) 56(84) bytes of data. 64 bytes from 10.42.0.1: icmp_seq=1 ttl=64 time=0.073 ms 64 bytes from 10.42.0.1: icmp_seq=2 ttl=64 time=0.094 ms 64 bytes from 10.42.0.1: icmp_seq=3 ttl=64 time=0.095 ms ^C --- 10.42.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2053ms rtt min/avg/max/mdev = 0.073/0.087/0.095/0.012 ms I might experiment some more by e.g. connecting another computer to the real ethernet connector and see if I can use the Eee PC's WiFi from that. On the Eee PC 900 in Lubuntu 18.04 I use `nm-connection-editor`.
|
|
|
Post by jj0 on Feb 23, 2021 8:55:54 GMT
I don't use Lubuntu but from the info here I gather you need to first connect THEVIC20 tot the PC and start XWM so that OTG mode is active. This should create the 'virtual' usb0 network card on the PC. Then you go to the network manager in Lubuntu (Preferences->Network Connections) and enable sharing on the usb0 device. The sharing will (at least on my Ubuntu) set up the DHCP server on Lubuntu that assigns an IP address to then rndis0 interface on THEVIC20 when dhclient asks for it.
|
|
|
Post by mobluse on Feb 24, 2021 4:17:02 GMT
I don't use Lubuntu but from the info here I gather you need to first connect THEVIC20 tot the PC and start XWM so that OTG mode is active. This should create the 'virtual' usb0 network card on the PC. Then you go to the network manager in Lubuntu (Preferences->Network Connections) and enable sharing on the usb0 device. The sharing will (at least on my Ubuntu) set up the DHCP server on Lubuntu that assigns an IP address to then rndis0 interface on THEVIC20 when dhclient asks for it. I got THEVIC20 online using the Eee PC 900 with Lubuntu and nameserver work on Internet, but not for the local computers, but I could ssh to the host EeePC. I needed to install dnsmasq. I also run this script on the EeePC: github.com/arpitjindal97/raspbian-recipes/blob/master/wifi-to-eth-route.sh(I changed the nameserver in the script to OpenDNS: 208.67.222.222.) Then I rebooted and didn't run the script, but then it worked anyway due to Lubuntus own system with sharing to other computers. What made it work was probably dnsmasq, but I'm not sure. Before I got usb0 to work I succeeded in connecting a Raspberry Pi with ethernet to the ethernet of the host EeePC and using its WiFi from the client Pi. Then I tried to connect THEVIC20 using Raspberry Pi Zero, but I haven't yet got that to work. It gets an IP number. `ip a` on THEVIC20: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN group default link/ipip 0.0.0.0 brd 0.0.0.0 3: gre0: <NOARP> mtu 1476 qdisc noop state DOWN group default link/gre 0.0.0.0 brd 0.0.0.0 4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default link/sit 0.0.0.0 brd 0.0.0.0 5: ip6tnl0: <NOARP> mtu 1452 qdisc noop state DOWN group default link/tunnel6 :: brd :: 6: rndis0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 32:98:8d:08:58:b9 brd ff:ff:ff:ff:ff:ff inet 192.168.2.6/24 brd 192.168.2.255 scope global rndis0 inet6 fe80::3098:8dff:fe08:58b9/64 scope link valid_lft forever preferred_lft forever `ip route` on the host Raspberry Pi Zero: default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.102 metric 303 169.254.0.0/16 dev usb0 scope link src 169.254.233.237 metric 204 192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.102 metric 303 I use the same script as on EeePC. It's strange that I get an 169.254 address in ip route. `ip a` on the host RPi0: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:f2:20:d6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.102/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0 valid_lft 85034sec preferred_lft 74234sec inet6 fe80::100d:b9b4:4d2:7a12/64 scope link valid_lft forever preferred_lft forever 4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 8e:19:fd:ed:f2:7f brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global noprefixroute usb0 valid_lft forever preferred_lft forever inet 169.254.233.237/16 brd 169.254.255.255 scope global noprefixroute usb0 valid_lft forever preferred_lft forever inet6 fe80::e216:1e59:e9a0:1aae/64 scope link valid_lft forever preferred_lft forever `ifconfig -a` on the host RPi0: lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 29596 bytes 1776520 (1.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 29596 bytes 1776520 (1.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::e216:1e59:e9a0:1aae prefixlen 64 scopeid 0x20<link> ether 8e:19:fd:ed:f2:7f txqueuelen 1000 (Ethernet) RX packets 6 bytes 384 (384.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 64 bytes 15783 (15.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::100d:b9b4:4d2:7a12 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:f2:20:d6 txqueuelen 1000 (Ethernet) RX packets 1325 bytes 130788 (127.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 807 bytes 133532 (130.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I cannot ssh from THEVIC20 to RPi0 using 192.168.2.1. `dhclient rndis0` sets the nameserver to 192.168.2.1 each time I run it even if I set something else. I'm rather close to getting it to work, and it would be a cheap way to get THEVIC20 and THEC64 online to e.g. download files. When I use EeePC as host I can use Dillo as browser, but that doesn't handle JavaScript, but `links` browser does, and I could read this site using `links`.
|
|
|
Post by spannernick on Feb 24, 2021 15:27:54 GMT
Could you use a USB WIFI Dongle or a USB to RJ45 Adapter(my USB to RJ45 Adapter, it blue, does work on THEC64 Mini FEL MODE) with THEC64 X-Windows Mod, I guess it would depend on if there's a modgel for the kernal and if it works with it or can be modified to work with it, and you would have to have 2 modgets, one of THEC64 Mini and one for THEC64 Maxi cause there kernels are not the same and uses different SoC(System On a Chip, there like ASIC(Application-specific integrated circuit) Chip, which came first..? the Chicken or the Egg, well Commodore did cause of there Chicken Head logo.. got to be funny with Covid 19 around.)...? My USB to RJ45 Adapter It works on my Sega Mega Drive Mini too with Hackchi installed.
|
|
|
Post by jj0 on Feb 24, 2021 16:03:53 GMT
Could you use a USB WIFI Dongle or a USB to RJ45 Adapter(my USB to RJ45 Adapter, it blue, does work on THEC64 Mini FEL MODE) with THEC64 X-Windows Mod, I guess it would depend on if there's a modgel for the kernal and if it works with it or can be modified to work with it, and you would have to have 2 modgets, one of THEC64 Mini and one for THEC64 Maxi cause there kernels are not the same and uses different SoC(System On a Chip, there like ASIC(Application-specific integrated circuit) Chip, which came first..? the Chicken or the Egg, well Commodore did cause of there Chicken Head logo.. got to be funny with Covid 19 around.)...? My USB to RJ45 Adapter On the Mini you could use it, if you remember I provided the kernel modules for this one in one of the earlier threads. So all you have to do is replace the asix.ko module that is load in start.sh with the one for this adapter.
|
|
|
Post by mobluse on Feb 24, 2021 17:44:56 GMT
I noticed that nm-connection-editor (a GUI network manager) that I used to get usb0 to work in Lubuntu on EeePC is also available in Raspberry Pi OS Buster on Raspberry Pi Zero in the package network-manager-gnome. I run my Raspberry Pi Zero W headless without X installed, so I would prefer if I could configure the network on the Pi without using a GUI.
|
|
|
Post by mobluse on Feb 24, 2021 18:14:35 GMT
Could you use a USB WIFI Dongle or a USB to RJ45 Adapter(my USB to RJ45 Adapter, it blue, does work on THEC64 Mini FEL MODE) with THEC64 X-Windows Mod, I guess it would depend on if there's a modgel for the kernal and if it works with it or can be modified to work with it, and you would have to have 2 modgets, one of THEC64 Mini and one for THEC64 Maxi cause there kernels are not the same and uses different SoC(System On a Chip, there like ASIC(Application-specific integrated circuit) Chip, which came first..? the Chicken or the Egg, well Commodore did cause of there Chicken Head logo.. got to be funny with Covid 19 around.)...? My USB to RJ45 Adapter On the Mini you could use it, if you remember I provided the kernel modules for this one in one of the earlier threads. So all you have to do is replace the asix.ko module that is load in start.sh with the one for this adapter. Maybe you could use THEC64 MINI as a host providing network using an ethernet adapter to THEVIC20/THEC64 as an rndis client via a USB cable. Preferably one could use the microUSB of THEC64 MINI connected to the back USB-A port of THEVIC20/THEC64 and the whole thing would be powered from THEVIC20/THEC64. Many people who own the full size models also own THEC64 MINI since before. It works powerwise because I tested it using a 2 A power supply and I get pictures from both HDMI ports. I've not tested this further with Linux booted on both machines.
|
|
|
Post by jj0 on Feb 25, 2021 14:00:14 GMT
I don't use Lubuntu but from the info here I gather you need to first connect THEVIC20 tot the PC and start XWM so that OTG mode is active. This should create the 'virtual' usb0 network card on the PC. Then you go to the network manager in Lubuntu (Preferences->Network Connections) and enable sharing on the usb0 device. The sharing will (at least on my Ubuntu) set up the DHCP server on Lubuntu that assigns an IP address to then rndis0 interface on THEVIC20 when dhclient asks for it. I got THEVIC20 online using the Eee PC 900 with Lubuntu and nameserver work on Internet, but not for the local computers, but I could ssh to the host EeePC. I needed to install dnsmasq. I also run this script on the EeePC: github.com/arpitjindal97/raspbian-recipes/blob/master/wifi-to-eth-route.sh(I changed the nameserver in the script to OpenDNS: 208.67.222.222.) Then I rebooted and didn't run the script, but then it worked anyway due to Lubuntus own system with sharing to other computers. What made it work was probably dnsmasq, but I'm not sure. Before I got usb0 to work I succeeded in connecting a Raspberry Pi with ethernet to the ethernet of the host EeePC and using its WiFi from the client Pi. Then I tried to connect THEVIC20 using Raspberry Pi Zero, but I haven't yet got that to work. It gets an IP number. `ip a` on THEVIC20: <snip> `ip route` on the host Raspberry Pi Zero: <snip> I use the same script as on EeePC. It's strange that I get an 169.254 address in ip route. `ip a` on the host RPi0: <snip> `ifconfig -a` on the host RPi0: <snip> I cannot ssh from THEVIC20 to RPi0 using 192.168.2.1. `dhclient rndis0` sets the nameserver to 192.168.2.1 each time I run it even if I set something else. I'm rather close to getting it to work, and it would be a cheap way to get THEVIC20 and THEC64 online to e.g. download files. When I use EeePC as host I can use Dillo as browser, but that doesn't handle JavaScript, but `links` browser does, and I could read this site using `links`. It's much easier to set up a bridge on the Pi Zero W between (in your case) wlan0 and usb0. I don't have a Pi Zero W but on a Pi Zero with added ethernet adapter and a new, clean RaspberryOS install I followed only the 'Setup the network bridge' part of this instruction, and in addition to the instructions for eth0 I did the same for usb0, creating an automatic bridge between eth0 and usb0. In your case, replace eth0 with wlan0 of course. Now when I run XWM on the Maxi (powered by the Pi Zero's OTG port) the usb0 interface that is created on the Pi Zero is automatically added to the bridge. And because it is bridged with 'the rest of the network' running dhclient on rndis0 on the Maxi gives it an IP-address and nameserver on your local network so you are immediately in business.
|
|
|
Post by mobluse on Feb 26, 2021 19:35:28 GMT
I got THEVIC20 online using the Eee PC 900 with Lubuntu and nameserver work on Internet, but not for the local computers, but I could ssh to the host EeePC. I needed to install dnsmasq. I also run this script on the EeePC: github.com/arpitjindal97/raspbian-recipes/blob/master/wifi-to-eth-route.sh(I changed the nameserver in the script to OpenDNS: 208.67.222.222.) Then I rebooted and didn't run the script, but then it worked anyway due to Lubuntus own system with sharing to other computers. What made it work was probably dnsmasq, but I'm not sure. Before I got usb0 to work I succeeded in connecting a Raspberry Pi with ethernet to the ethernet of the host EeePC and using its WiFi from the client Pi. Then I tried to connect THEVIC20 using Raspberry Pi Zero, but I haven't yet got that to work. It gets an IP number. `ip a` on THEVIC20: <snip> `ip route` on the host Raspberry Pi Zero: <snip> I use the same script as on EeePC. It's strange that I get an 169.254 address in ip route. `ip a` on the host RPi0: <snip> `ifconfig -a` on the host RPi0: <snip> I cannot ssh from THEVIC20 to RPi0 using 192.168.2.1. `dhclient rndis0` sets the nameserver to 192.168.2.1 each time I run it even if I set something else. I'm rather close to getting it to work, and it would be a cheap way to get THEVIC20 and THEC64 online to e.g. download files. When I use EeePC as host I can use Dillo as browser, but that doesn't handle JavaScript, but `links` browser does, and I could read this site using `links`. It's much easier to set up a bridge on the Pi Zero W between (in your case) wlan0 and usb0. I don't have a Pi Zero W but on a Pi Zero with added ethernet adapter and a new, clean RaspberryOS install I followed only the 'Setup the network bridge' part of this instruction, and in addition to the instructions for eth0 I did the same for usb0, creating an automatic bridge between eth0 and usb0. In your case, replace eth0 with wlan0 of course. Now when I run XWM on the Maxi (powered by the Pi Zero's OTG port) the usb0 interface that is created on the Pi Zero is automatically added to the bridge. And because it is bridged with 'the rest of the network' running dhclient on rndis0 on the Maxi gives it an IP-address and nameserver on your local network so you are immediately in business. How can you connect both the ethernet adapter and the Maxi to the Raspberry Pi Zero? Do you use a USB hub?
|
|
|
Post by jj0 on Feb 26, 2021 20:02:37 GMT
It's much easier to set up a bridge on the Pi Zero W between (in your case) wlan0 and usb0. I don't have a Pi Zero W but on a Pi Zero with added ethernet adapter and a new, clean RaspberryOS install I followed only the 'Setup the network bridge' part of this instruction, and in addition to the instructions for eth0 I did the same for usb0, creating an automatic bridge between eth0 and usb0. In your case, replace eth0 with wlan0 of course. Now when I run XWM on the Maxi (powered by the Pi Zero's OTG port) the usb0 interface that is created on the Pi Zero is automatically added to the bridge. And because it is bridged with 'the rest of the network' running dhclient on rndis0 on the Maxi gives it an IP-address and nameserver on your local network so you are immediately in business. How can you connect both the ethernet adapter and the Maxi to the Raspberry Pi Zero? Do you use a USB hub? I use an OTG cable (https://en.m.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_cables).
|
|
|
Post by mobluse on Feb 26, 2021 22:22:51 GMT
How can you connect both the ethernet adapter and the Maxi to the Raspberry Pi Zero? Do you use a USB hub? I use an OTG cable (https://en.m.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_cables). Yes, but do you not need to connect a USB hub to the OTG cable? since you have two devices connected to the Raspberry Pi Zero: ethernet adapter and Maxi.
|
|
|
Post by jj0 on Feb 26, 2021 22:55:13 GMT
I use an OTG cable (https://en.m.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_cables). Yes, but do you not need to connect a USB hub to the OTG cable? since you have two devices connected to the Raspberry Pi Zero: ethernet adapter and Maxi. It's an OTG cable with two Female Type-A connectors, so I can connect the USB2Ethernet and the Maxi. I think it's the same as a passive HUB.
|
|
|
Post by spannernick on Mar 3, 2021 20:46:07 GMT
I was thinking, if you could get XWM to use the internet by using a RPI, could you get it to work on VICE too, the VICE that comes with PCU or VICE standalone and connect it to C64 Telnet Billiton Boards Sites .....?
|
|
|
Post by jj0 on Mar 3, 2021 21:51:33 GMT
I was thinking, if you could get XWM to use the internet by using a RPI, could you get it to work on VICE too, the VICE that comes with PCU or VICE standalone and connect it to C64 Telnet Billiton Boards Sites .....? I'd probably need to recompile VICE with '--enable-ethernet', I don't think I did that,
|
|
|
Post by spannernick on Mar 6, 2021 15:04:45 GMT
I had a idea.. I was thinking this takes up 2GB space on your USB Stick or SD Card, I know you can't shrink it but could you unpack it and mount it like we did with VICE and Midnight Commander...? Then you could use the space that in the XWM folder on the USB Stick instead and could then make the XWM or X smaller and removing stuff we don't need, so all the files from rootfs.img is in a folder called XWM instead, so your would not be using chroot but overmounting Buildroot's folders instead like I did with MC, and users can access the the files for XWM better too, so if they want to change the theme say, what you think JJ...?
|
|
|
Post by jj0 on Mar 6, 2021 17:10:49 GMT
I had a idea.. I was thinking this takes up 2GB space on your USB Stick or SD Card, I know you can't shrink it but could you unpack it and mount it like we did with VICE and Midnight Commander...? Then you could use the space that in the XWM folder on the USB Stick instead and could then make the XWM or X smaller and removing stuff we don't need, so all the files from rootfs.img is in a folder called XWM instead, so your would not be using chroot but overmounting Buildroot's folders instead like I did with MC, and users can access the the files for XWM better too, so if they want to change the theme say, what you think JJ...? It's too complicated/ VICE and especially MC are simple programs that use a few libraries so are relatively easy to separate. X-Windows and all the programs you can run while in X-Windows is much too complicated to manage that way. Also is 2GB really that much these days?
|
|
|
Post by ewuuwe on Jun 8, 2021 11:23:45 GMT
Update: Link updated to TheC64-X-Windows v3.zip: - Adds evtest-gtk tool, can be used to determine what each button on a joystick/gamepad is called. Use if you want to change Project Carousel on USB XMW start or gamefolder switch buttons
- Sound now works though can still hickup as memory is very tight
- Added some missing /dev folders - thanks threader
- If there is no nandb but there is a mmcblk0p2 then mmcblk0p2 is used instead of nandb - useful for those that use e.g. a Maxi Pi
Download from Mega... Here or from One Drive... Here. This is a custom firmware upgrade for the Mini and the Maxi that rather than upgrade something instead starts an X-Windows session, allowing you to copy games, edit files like gamecotrollerdb.txt etc using a graphical desktop: It will startup with a file manager with bookmarks to the '/usr/shares/the64' directory, the full rootfs and the USB disk, and also a terminal window. In addition there are icons on the Desktop to: - Backup the nand and the 'usr/shares/the64' files to the USB disk, to a backup directory. It creates new copies every time you run it.
- Run the evtest-qt joystick test program
To quit and get back to theTheC64 mode logout use the red 'switch off' logout button. You need a keyboard and mouse attached to the TheC64 though the Maxi's keyboard works as keyboard. To use it, unzip the zipfile to an USB disk (preferably a fast one) that you know works on TheC64, e.g. that you already know the TheC64 can load games from. It needs to be 2GB or more. Then go to the System Information menu where you can 'upgrade'. This will start the X-Windows session, depending on the speed of your USB disk it can take some time to start. There are some graphical glitches with the application windows not refreshing, if you encounter this minimise and then maximise the window and it will be redrawn ok. You can make a screenshot using the PrtSct key. The rootfs image itself is a copy of the Olimex A20 Lime rootfs. Remember that TheC64 has very little memory (and doesn't support a swapfile) so memory-hungry applications won't run. And obviously there's no network. Use at your own risk. Make a backup first. I'm not responsible for anyone bricking his/her TheC64 by using this. Thanks to both cyanic and raxrip who created the firmware unpacker/packer that makes this possible. The joystick icon was made by Freepik from www.flaticon.comA brief overview of how to add/change things on the rootfs image: From the TheC64: - In 'start.sh' on the USB drive change the 'mount -o ro /mnt/rootfs.img /tmp/chroot' to 'mount -o rw /mnt/rootfs.img /tmp/chroot' to make it writable
- Put any stuff you want to change/add also on the USB dirve, e.g.background image, software packages. For software packages you need do download the corresponding .deb package for Debian Jessie
- Run the 'update' on the TheC64. The rootfs image is now read/write so you can make any changes you want. To install a .deb package do 'dpkg -i xxxx.deb'
From a PC running Linux: - Mount (a copy of) the rootfs.img on a suitable directory, e.g. sudo 'mount rootfs.img /mnt'
- You need to have qemu-user-static installed and possibly binfmt installed
- If you want to run X-Windows programs from the rootfs and have them displayed on your PC's screen, then from a normal terminal window on your PC do:
# xhost + access control disabled, clients can connect from any host # echo $DISPLAY :1
- Start a root command-line session from the rootfs image:
sudo chroot /mnt /bin/sh or
sudo chroot /mnt /bin/bash
- Do:
export DISPLAY=<$DISPLAY from above>
- You can now edit the filesystem and also install packgages with apt-get and should have a normal network connection
- Some X programs will run on your screen, e.g. 'xclock'. But many others won't.
- Instead of using systemd-nspawn you might also be able to use Docker or qumu
- After logging out of the session do a 'sudo umount /mnt' and copy the rootfs image back to the USB drive for use on the TheC64
If you don't have a PC running linux you can also do it from an Ubuntu 'live' install usb disk.
Note that the X-Windows session is running as root but with $HOME set to the non-root user home directoty '/home/olimex' so not 100% standard. Also no other services from the rootfs are running.
|
|
|
Post by spannernick on Sept 8, 2021 16:59:51 GMT
|
|
|
Post by erduk on Nov 16, 2021 12:04:04 GMT
Great news, congratulations to all developers. I guess we are one step closer to have RetroPie/Lakka running now.
|
|
|
Post by jj0 on Nov 29, 2021 9:27:46 GMT
See here for updated usb2ethernet drivers - now also working for the Maxi.
|
|
|
Post by erduk on Dec 7, 2021 17:40:27 GMT
Your picture was helpful. I used that system to install DOSBox, FUSE-GTK (ZX Spectrum), WXMaxima, QTOctave, perlconsole etc. I can run CP/M emulators in DOSBox and FUSE, and C64 emulators in DOSBox. I show some of the programs running here: IBM PC emulator (DOSBox) running a C64 emulator running FORTH, a Jupiter Ace emulator (xAce) with native Forth, and BASIC (YABasic) for Linux. Hi, would it be possible to provide a link to your build? Thank you.
|
|
|
Post by threader on Dec 8, 2021 3:04:27 GMT
I took the time to try out the 'qemu-user-static' approach and 'chroot' to a copy of the Olimex/Debian image to a dir. I also tracked down the last relevant Debian repository for jessie in the Debian snapshots archive snapshot.debian.org/. I Struggled a bit back and forth with setting up qemu-user with that but in the end landed on this page unix.stackexchange.com/questions/41889/how-can-i-chroot-into-a-filesystem-with-a-different-architechture which suggested this: # This provides the qemu-arm-static binary apt-get install qemu-user-static
# Mount my target filesystem on /mnt mount -o loop fs.img /mnt
# Copy the static ARM binary that provides emulation cp $(which qemu-arm-static) /mnt/usr/bin # Or, more simply: cp /usr/bin/qemu-arm-static /mnt/usr/bin
# Finally chroot into /mnt, then run 'qemu-arm-static bash' # This chroots; runs the emulator; and the emulator runs bash chroot /mnt qemu-arm-static /bin/bash
That let me quickly get where i wanted instead of adding everything via 'apt install libc6:armhf libncurses5:armhf' etc. And I ended up with the following 'start-qemu-user-static-armhf.sh' script. #!/bin/sh mount -t proc proc rootfs/proc mount -t devtmpfs devtmpfs rootfs/dev
mkdir rootfs/dev/pts mount -t devpts devpts rootfs/dev/pts mkdir rootfs/dev/shm mount -t tmpfs tmpfs rootfs//dev/shm mount -t tmpfs tmpfs rootfs/tmp
#sudo chroot rootfs/ qemu-arm-static /bin/bash
And /etc/apt/sources.list looks like this now: #deb http://ftp.uk.debian.org/debian jessie main contrib non-free deb https://snapshot.debian.org/archive/debian/20200420T210233Z jessie main contrib non-free #deb-src http://ftp.uk.debian.org/debian jessie main contrib non-free deb-src https://snapshot.debian.org/archive/debian/20200420T210233Z jessie main contrib non-free #deb http://ftp.uk.debian.org/debian jessie-updates main contrib non-free deb https://snapshot.debian.org/archive/debian/20200420T210233Z jessie-updates main contrib #deb-src http://ftp.uk.debian.org/debian jessie-updates main contrib non-free
# Not working #deb-src https://snapshot.debian.org/archive/debian/20200420T210233Z jessie-updates main contrib non-free #deb http://security.debian.org/debian-security jessie/updates main contrib non-free #deb https://snapshot.debian.org/archive/debian/20200420T210233Z jessie/updates main contrib non-free #deb-src http://security.debian.org/debian-security jessie/updates main contrib non-free #deb-src https://snapshot.debian.org/archive/debian/20200420T210233Z jessie/updates jessie/updates main contrib non-free
But computer says no..... W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/main/source/Sources server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
So, I try the following: mv rootfs/etc/ssl/certs mount -o bind /etc/ssl/certs rootfs/etc/ssl/certs
Eureka! apt update Get:1 https://snapshot.debian.org jessie InRelease [2034 B] Ign https://snapshot.debian.org jessie InRelease Hit https://snapshot.debian.org jessie-updates InRelease Hit https://snapshot.debian.org jessie Release.gpg Hit https://snapshot.debian.org jessie Release Fetched 18.7 MB in 30s (611 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date.
So i unmount the binded directory and just move and copy for now, ca-certificates willneed to be installed from a current source, so simply add Debian stable right?: # Current deb http://ftp.de.debian.org/debian stable main contrib non-free deb-src http://ftp.de.debian.org/debian stable main contrib non-free [code]
Computer says noooooooo....... [code] W: GPG error: http://ftp.de.debian.org stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 605C66F00D6C9793
Well at least this is a known error. apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 605C66F00D6C9793 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 648ACFD622F3D138
Right ... This seems familiar.... Computer says nooooooo...... - ?!!!!? Err https://snapshot.debian.org jessie/main Sources Err https://snapshot.debian.org jessie/contrib Sources Err https://snapshot.debian.org jessie/non-free Sources Err https://snapshot.debian.org jessie/main armhf Packages Err https://snapshot.debian.org jessie/contrib armhf Packages Err https://snapshot.debian.org jessie/non-free armhf Packages Err https://snapshot.debian.org jessie-updates/main Sources Err https://snapshot.debian.org jessie-updates/contrib Sources Err https://snapshot.debian.org jessie-updates/non-free Sources Err https://snapshot.debian.org jessie-updates/main armhf Packages Err https://snapshot.debian.org jessie-updates/contrib armhf Packages W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/main/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/contrib/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/non-free/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/main/binary-armhf/Packages
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/contrib/binary-armhf/Packages
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie/non-free/binary-armhf/Packages
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/main/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/contrib/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/non-free/source/Sources
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/main/binary-armhf/Packages
W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/contrib/binary-armhf/Packages
E: Some index files failed to download. They have been ignored, or old ones used instead.
Mkay... I install 'ca-certificates' with apt anyway hoping my problems might pass. Huh, computer says noooo? Running hooks in /etc/ca-certificates/update.d... run-parts: failed to open directory /etc/ca-certificates/update.d: Value too large for defined data type done.
And running 'dpkg-reconfigure ca-certificates' did ofc. generate the same error. So what happens when i run 'apt update' i wonder? W: Failed to fetch https://snapshot.debian.org/archive/debian/20200420T210233Z/dists/jessie-updates/contrib/binary-armhf/Packages server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Huh. Ok, i move /etc/ssl/certs to /etc/ssl/certs-new-stable and copy the /etc/ssl/certs directory from my host OS and surely enough. apt update Hit http://ftp.de.debian.org stable InRelease Hit http://ftp.de.debian.org stable/main Sources Hit http://ftp.de.debian.org stable/contrib Sources Hit http://ftp.de.debian.org stable/non-free Sources Hit http://ftp.de.debian.org stable/main armhf Packages Hit http://ftp.de.debian.org stable/contrib armhf Packages Hit http://ftp.de.debian.org stable/non-free armhf Packages Hit http://ftp.de.debian.org stable/contrib Translation-en Hit http://ftp.de.debian.org stable/main Translation-en Hit http://ftp.de.debian.org stable/non-free Translation-en Get:1 https://snapshot.debian.org jessie InRelease [2034 B] Ign https://snapshot.debian.org jessie InRelease Hit https://snapshot.debian.org jessie-updates InRelease Get:2 https://snapshot.debian.org jessie Release.gpg [1652 B] Hit https://snapshot.debian.org jessie-updates/main Sources Hit https://snapshot.debian.org jessie-updates/contrib Sources Hit https://snapshot.debian.org jessie-updates/non-free Sources Hit https://snapshot.debian.org jessie-updates/main armhf Packages Hit https://snapshot.debian.org jessie-updates/contrib armhf Packages Hit https://snapshot.debian.org jessie-updates/contrib Translation-en Hit https://snapshot.debian.org jessie-updates/main Translation-en Hit https://snapshot.debian.org jessie Release Hit https://snapshot.debian.org jessie/main Sources Hit https://snapshot.debian.org jessie/contrib Sources Hit https://snapshot.debian.org jessie/non-free Sources Hit https://snapshot.debian.org jessie/main armhf Packages Hit https://snapshot.debian.org jessie/contrib armhf Packages Hit https://snapshot.debian.org jessie/non-free armhf Packages Hit https://snapshot.debian.org jessie/contrib Translation-en Hit https://snapshot.debian.org jessie/main Translation-en Hit https://snapshot.debian.org jessie/non-free Translation-en Fetched 1652 B in 28s (58 B/s) Reading package lists... Done Building dependency tree Reading state information... Done 597 packages can be upgraded. Run 'apt list --upgradable' to see them.
Huh? I can now set up to compile some Lima drivers and see what happens, though the list of dependencies for just building Mesa will surely mess up dependencies between a clean jessie and this mess, i messed up with installing ca-certificates from 'stable' anyway as that dragged with it a libc6 update, then there's the case of this, git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/lima?id=a1d2a6339961efc078208dc3b2f006e9e9a8e119 , I'll try building a module ofc. Cheers!
|
|
|
Post by jj0 on Dec 8, 2021 15:15:43 GMT
I took the time to try out the 'qemu-user-static' approach and 'chroot' to a copy of the Olimex/Debian image to a dir. I also tracked down the last relevant Debian repository for jessie in the Debian snapshots archive snapshot.debian.org/. <SNIP>Huh? I can now set up to compile some Lima drivers and see what happens, though the list of dependencies for just building Mesa will surely mess up dependencies between a clean jessie and this mess, i messed up with installing ca-certificates from 'stable' anyway as that dragged with it a libc6 update, then there's the case of this, git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/lima?id=a1d2a6339961efc078208dc3b2f006e9e9a8e119 , I'll try building a module ofc. Cheers! Hmmm... What Linux main OS are you running? I haven't had the issues you describe on Ubuntu (18.x and onwards) but the way I set it up is slightly different: - I've installed 'qemu-user-static' and 'binfmt=support'. The latter package automatically/transparently invokes qemu-arm-static if you try to run an arm binary so you can just do a 'chroot rootfs'
- I've used this Armbian Xenial image instead of Debian Jessie. I copied the files from the image to a directory so I wouldn't run out of space when compiling something
- I usually chroot into it without all the map binds. This does work but git clone from https doesn't due to not /dev/random being available but then I do the git clone from outside the chroot
But as long as you get there in the end.... LIMA driver would be interesting but won't it clash with the MALI driver?
|
|
|
Post by threader on Dec 8, 2021 18:04:06 GMT
I run Debian unstable.
There is a very good chance it won't work, I've already had to import a driver (drivers/reset/ - Generic Reset Controller support.), and it's not module friendly, in it's first instance at least, and I expect RGL haven't set us up with a kernel we can actually work with and flash yet, we need the y2038 patches and a re-compiled base system, or its a brick in 2038.
I'm currently trying to sort out the supporting commits for the first instance of the lima driver. But I expect we can unload the driver with a 'rmmod -f <whatever the name of the sun7i disp.ko(?) driver is> && modprobe drm.ko && modprobe lima.ko'
That's exactly what I did some years ago, though I was thinking it was a kernel kvm feature that had to be built.
Do you know of a way I can coax git into working with the correct directory, when importing commits from Linux kernel main, i end up having to manually stuff everything into place, i thought about a submodule, but that didn't play ball.
Edit: This is starting to come together, a few complicated bits left though. I remember bumping up to xarray.h in 3.10 recently.
ARCH=arm CROSS_COMPILE=/home/thread/dev/sdk/gcc-linaro-arm-linux-gnueabihf-2012.05-20120523_linux/bin/arm-linux-gnueabihf- make -j7 modules #menuconfig #sun7ismp_redquark_defconfig CHK include/linux/version.h HOSTCC scripts/basic/fixdep CHK include/generated/utsrelease.h HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash HOSTCC scripts/bin2c CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig make[1]: 'include/generated/mach-types.h' is up to date. MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost CC [M] drivers/gpu/drm/drm_auth.o CC [M] drivers/gpu/drm/drm_buffer.o CC [M] drivers/gpu/drm/drm_bufs.o CC [M] drivers/gpu/drm/drm_cache.o CC [M] drivers/i2c/algos/i2c-algo-bit.o CC [M] drivers/gpu/drm/drm_context.o CC [M] drivers/gpu/drm/drm_dma.o CC [M] drivers/gpu/drm/drm_drv.o CC [M] drivers/gpu/drm/drm_fops.o CC [M] drivers/gpu/drm/drm_gem.o CC [M] drivers/gpu/drm/drm_ioctl.o CC [M] drivers/gpu/drm/drm_irq.o CC [M] drivers/scsi/scsi_wait_scan.o CC [M] drivers/video/fbmem.o CC [M] drivers/gpu/drm/drm_lock.o CC [M] drivers/video/fbmon.o CC [M] drivers/gpu/drm/drm_memory.o CC [M] drivers/video/fbcmap.o CC [M] drivers/gpu/drm/drm_proc.o CC [M] drivers/gpu/drm/drm_stub.o CC [M] drivers/gpu/drm/drm_vm.o CC [M] drivers/video/fbsysfs.o CC [M] drivers/gpu/drm/drm_agpsupport.o CC [M] drivers/gpu/drm/drm_scatter.o CC [M] drivers/gpu/drm/ati_pcigart.o CC [M] drivers/gpu/drm/drm_pci.o CC [M] drivers/video/modedb.o CC [M] drivers/gpu/drm/drm_platform.o CC [M] drivers/gpu/drm/drm_sysfs.o CC [M] drivers/video/fbcvt.o CC [M] drivers/video/console/fbcon.o CC [M] drivers/video/console/bitblit.o CC [M] drivers/video/sun7i/disp/dev_disp.o CC [M] drivers/gpu/drm/drm_hashtab.o CC [M] drivers/video/sun7i/hdmi/aw/hdmi_core.o CC [M] drivers/video/sun7i/disp/dev_fb.o CC [M] drivers/video/sun7i/hdmi/aw/hdmi_hal.o drivers/video/sun7i/disp/dev_fb.c: In function ‘Fb_map_video_memory’: drivers/video/sun7i/disp/dev_fb.c:338:5: warning: passing argument 2 of ‘disp_malloc’ from incompatible pointer type [enabled by default] In file included from drivers/video/sun7i/disp/dev_fb.c:2:0: drivers/video/sun7i/disp/dev_disp.h:78:7: note: expected ‘__u32 *’ but argument is of type ‘long unsigned int *’ drivers/video/sun7i/disp/dev_fb.c:341:9: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat] drivers/video/sun7i/disp/dev_fb.c: In function ‘Display_Fb_Request’: drivers/video/sun7i/disp/dev_fb.c:1243:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/video/sun7i/disp/dev_fb.c:1221:19: warning: unused variable ‘ulLCM’ [-Wunused-variable] drivers/video/sun7i/disp/dev_fb.c: At top level: drivers/video/sun7i/disp/dev_fb.c:1198:22: warning: ‘LCM’ defined but not used [-Wunused-function] CC [M] drivers/gpu/drm/drm_mm.o CC [M] drivers/gpu/drm/drm_crtc.o CC [M] drivers/video/sun7i/hdmi/aw/hdmi_interface.o CC [M] drivers/video/sun7i/hdmi/aw/hdmi_edid.o CC [M] drivers/gpu/drm/drm_modes.o CC [M] drivers/video/sun7i/hdmi/drv_hdmi.o CC [M] drivers/video/sun7i/disp/dev_capture.o CC [M] drivers/video/sun7i/hdmi/dev_hdmi.o CC [M] drivers/video/sun7i/disp/dev_disp_attrnode.o drivers/video/sun7i/hdmi/dev_hdmi.c: In function ‘hdmi_module_init’: drivers/video/sun7i/hdmi/dev_hdmi.c:215:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] LD [M] drivers/video/sun7i/hdmi/hdmi.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Cache.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Clock.o CC [M] drivers/video/sun7i/lcd/dev_lcd.o CC [M] drivers/video/sun7i/lcd/lcd0_panel_cfg.o CC [M] drivers/video/console/fonts.o CC [M] drivers/video/sun7i/lcd/lcd1_panel_cfg.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Dma.o CC [M] drivers/video/console/font_sun12x22.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Int.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_IrqLock.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Lib_C.o CC [M] drivers/video/console/softcursor.o CC [M] drivers/gpu/drm/drm_edid.o LD [M] drivers/video/sun7i/lcd/lcd.o LD [M] drivers/video/fb.o CC [M] drivers/gpu/drm/drm_info.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Pin.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Semi.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Thread.o CC [M] drivers/video/console/tileblit.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Time.o CC [M] drivers/video/sun7i/disp/OSAL/OSAL_Parser.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_be.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_fe.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_hwc.o CC [M] drivers/gpu/drm/drm_debugfs.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_layer.o LD [M] drivers/video/console/font.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_lcdc.o CC [M] drivers/gpu/drm/drm_encoder_slave.o CC [M] drivers/gpu/drm/drm_trace_points.o CC [M] drivers/video/sun7i/disp/de_bsp/de/ebios/de_tvec.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_clk.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_combined.o CC [M] drivers/gpu/drm/drm_global.o CC [M] drivers/gpu/drm/drm_prime.o CC [M] drivers/gpu/drm/lima/lima_drv.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_de.o In file included from drivers/gpu/drm/lima/lima_drv.c:5:0: include/linux/of_platform.h:106:13: warning: ‘struct device’ declared inside parameter list [enabled by default] include/linux/of_platform.h:106:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/of_platform.h:106:13: warning: ‘struct of_device_id’ declared inside parameter list [enabled by default] include/linux/of_platform.h:106:13: warning: ‘struct device_node’ declared inside parameter list [enabled by default] CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_display.o In file included from drivers/gpu/drm/lima/lima_drv.h:9:0, from drivers/gpu/drm/lima/lima_drv.c:13: drivers/gpu/drm/lima/lima_ctx.h:7:26: fatal error: linux/xarray.h: No such file or directory compilation terminated. make[4]: *** [scripts/Makefile.build:307: drivers/gpu/drm/lima/lima_drv.o] Error 1 make[3]: *** [scripts/Makefile.build:443: drivers/gpu/drm/lima] Error 2 make[3]: *** Waiting for unfinished jobs.... CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_event.o make[2]: *** [scripts/Makefile.build:443: drivers/gpu/drm] Error 2 make[1]: *** [scripts/Makefile.build:443: drivers/gpu] Error 2 make[1]: *** Waiting for unfinished jobs.... CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_hdmi.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_hwc.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_layer.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_lcd.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_scaler.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_sprite.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_tv.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_vga.o CC [M] drivers/video/sun7i/disp/de_bsp/de/disp_video.o LD [M] drivers/video/sun7i/disp/disp.o make: *** [Makefile:945: drivers] Error 2
Edit again: It will crash with the sun7i driver, that is ofc. built in. That said I'm putting in the effort to try and get it built. The hacks are amassing, i just had to put something meant for compiler.h in a the ldr.h header.
Edit: Uhm, the changes i have to make to lib/ will need a new kernel, i'm up in some radix-tree....
|
|