I'm on Ubuntu,
On the Pi, on the USB host, or on the machine running imager?
and indeed I can see something with the command "ip -c a" that a new interface has been create, but nerver get an IP, then just stay like this. This interface regularly change its name (new try to create something I guess) and the virtual MAC change as well.
As explained in my guide (but probably not in the other "little guides I found on the net", unless explicitly configured to do otherwise g_ether will use new, random MAC addresses for both interfaces it provides each time it starts.
But I just can't reach the Pi.
Now some precision about the steps above :
- I'm burning the 32bit Raspbian
I very much doubt that. If you really are using Raspbian try switching to Raspberry Pi OS.
- Step 2 & 3 are crote on the "bootfs" partition, not "boot".
What's "crote"? A typo for wrote?
Are you confusing the partition label (bootfs) with the partition's purpose (to hold the files necessary to boot a Pi)? I use boot partition as the label can, in fact, be anything that's valid for a FAT32 partition. It has no impact on whether the Pi can boot from that partition or on the mounting of it after boot.
- I do not understand why there is need to create a "ssh" empty file on this partition.
Let me guess, those "little guides I found on the net" tell you what but not why. It's a legacy method of enabling ssh on a headless PI.
I tried to read UART interface using GPIO and a USB / terminal DB9 connector, I'm seeing nothing (using minicom on ubuntu, it's a bit tricky but works most of the time).
DB9 implies RS232 levels. If the DB9 end was directly connected to the Pi you have almost certainly damaged those GPIO beyond repair. Pi GPIO are +3.3v only. They are not 5V tolerant and certainly not tolerant of the up to +15V and down to -15V used by RS232. In fact, they don't handle -ve voltages at all.
If you were using a 3.3V TTL UART at the Pi end, check that you have enabled UART0 in config.txt and that cmdline.txt specifies a console on serial0
If the USB end was on the Pi, there are several possible causes for a lack of communication:
- You've not enabled a getty on the tty it provides.
- You've forced dwc2 into device only mode. No USB devices can or will be detected.
- You've left dwc2 in it's default otg mode but your micro USB to USB A adapter isn't pulling the ID pin correctly to indicate that it needs to be a host.
- You've connected it to the power port and are expecting it to work (it won't - there are no data lines on that port).
Statistics: Posted by thagrol — Sat Dec 14, 2024 3:42 pm