HAT with serial port on Raspberry Pi 3+ looping back into U-Boot

msplsh

msplsh

It took me a little while to figure out what was going on, but it seems like the serial port on this HAT I have is having its output fed into U-Boot and causing a loop, preventing FreeBSD from booting with the HAT installed.
  1. U-Boot shows a prompt
  2. The HAT fills it in with its prompt
  3. U-Boot says "that's not a command"
  4. The HAT sees "that's not a command", ignores it, and responds with the prompt again
  5. etc...
This doesn't happen on Raspbian and I've already tried copying the config.txt between them.

Anyone had/seen this problem and have any ideas?
 
One thing I stumbled into late in my Arm experiments is that Pi is special in that it has a port which includes precompiled overlays for all kinds of accessories.
sysutils/rpi-firmware
This makes it as easy as adding overlays to /boot/loader.conf to load device drivers

I dunno if this helps you at all with your problem. This sounds like a pre-loader/uboot problem.
But it could be a problem with the DTB. So I would try adding the overlay for your device without the hat installed.
Then reboot with the hat installed.

There is also the matter of pin states. They can be muxed into all sorts of arrangements.
So you might need to look at that. Once again the DTB assigns pin states.
I seem to remember it being more of an issue with the BBB. It had like 7 different modes for most pins.

Worst case scenario you might have to build a uboot without serial or some other uboot jiggery.
 
The overlay stuff is not well documented.
Take a look at this phab. The next to last post has a good example of an overlay and setting parameters.

⚙ D22710 Update owc_gpiobus (one-wire over gpio) to the modern gpio_pin interface.

reviews.freebsd.org reviews.freebsd.org

You can also set stuff in a hints based fashion:
github.com

GitHub - alexandermishin13/rcrecv-kmod: FreeBSD kernel driver for gpio based remote control codes receiver.

FreeBSD kernel driver for gpio based remote control codes receiver. - alexandermishin13/rcrecv-kmod
github.com github.com

Note the loader directive. This uses the name of the precompiled binaries from the rpi-firmware.
fdt_overlays="your,other,overlays,sun8i-h3-rcrecv-gpio"
 
One more thing. You must copy the rpi-firmware files you want to load from /usr/local/share/rpi-firmware/ to /boot/dtb/overlay/.
The rpi-firmware is a repository of precompiled FreeBSD binaries of the official Pi Linux overlays.
So find your gadgets overlay files and copy them.
(You could just copy the whole directory over but it is more elegant to copy only what is needed for your hat)

The package message indicates another way of using the firmware. I don't believe config.txt is the preferred method. I thought that was superseded by using /boot/loader.conf facility. It may still work though.

Am I boring you with all these overlay details? It is much easier than the old way.
 
This deals with U-Boot's command line, so the FreeBSD loader has nothing to do with this, because it is not running.

The problem is not firmware. The problem is with U-Boot accepting output from the serial port on the HAT as input to the command line and vice versa.
 
Uboot has a command prompt. Perhaps you need to experiment with it. SETENV SAVEENV.
Like I said earlier you may need to recompile das U-boot. OOB it may only support the UART.
Without hat:
Code: 
U-Boot> setenv bootdelay -2
U-Boot> saveenv


Here is a post about Pi4 uboot serial stuff.
stackoverflow.com

GPS Serial Console issue on Ubuntu 20.04 on Raspberry Pi 4

I am trying to use the BerryGPS-IMUv3 (https://ozzmaker.com/berrygps-berrygps-imu-quick-start-guide/) on a RPi 4B running Ubuntu 20.04 headless. When the BerryGPS-IMU is installed, it prevents the pi
stackoverflow.com stackoverflow.com

Note the comment:
I guess that means something changed in later tags.
 
Phishfry said:
The package message indicates another way of using the firmware. I don't believe config.txt is the preferred method. I thought that was superseded by using /boot/loader.conf facility. It may still work though
Click to expand...
For overlays from sysutils/rpi-firmware it may be only way to load them properly, as they often do not contain the status = "okay" string and may require some other options to be set inline. I don't know how to do this with /boot/loader.conf, unless you write and compile your own overlay with these options enabled.
 
You must log in or register to reply here.
Back
Top