Raspberry Pi Forums

Explain what a Sabertooth is and I might know where this topic belongs, but it isn't here.

You could try with a multimeter, connecting one probe to each ground. The measured voltage is the difference between the two grounds. Note that the multimeter has a very high resistance, unlike a simple wire, otherwise it might end up connecting the two grounds together and solving the problem.

Voltages cannot be measured absolutely, you can only measure the difference between two points, and the ground is the reference point against which other signals are compared. If two devices have different grounds they may have different ideas about whether a signal is high or low.

From http://www.linux-mtd.infradead.org/doc/ubifs.html: fast mount - unlike JFFS2, UBIFS does not have to scan whole media when mounting, it takes milliseconds for UBIFS to mount the media, and this does not depend on flash size; however, UBI initialization time depends on flash size and has to be t...

So the fact that the mounting takes 50s suggests that it involves reading 40-45MB, which is over half of the the device capacity (65536KB). If your filesystem is full of small files that might be reasonable, but for an empty one it would seem excessive. How would you describe the occupancy of the vo...

You can just use the drop_caches method and repeat your read test:

Code: Select all

$ flush
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
$ time dd if=/mnt/flash/testfile of=/dev/null bs=1M count=10

And do this before the read test:

Code: Select all

$ flush
$ echo 3 | sudo tee /proc/sys/vm/drop_caches

I don't trust those numbers. Try with "conv=fdatasync" in the dd command line.

What's the access speed like once it's mounted? How much data does 49s equate to at that speed?

That's going to be tricky then, unless you can hook up a UART.

Have you tried asking the designer of the board? https://github.com/NebraLtd/nebra-lora-hardware/issues

What does "lsusb" show?

Have you tried:

Code: Select all

dtoverlay=dwc2,dr_mode=host

?

Deleted strange rant/possible AI spam (and well-reasoned responses to it).

That patch was merged late April, so your current kernel (Tue May 30) includes it.

As there should only be one set of pull-ups per bus, unless Grove are completely clueless (which seems unlikely), the devices will have no pull-ups.

GPIO 8 and 9

Which pin/GPIO numbering scheme are you using? The I2C bus with the pull-ups is on SoC/Broadcom GPIOs 2 & 3, which are on header pins 3 & 5.

Are the other devices all being powered from the Pi via the 4-pin connectors? The Zero W isn't capable of powering much in the way of external peripherals. Do you have a way to give at least one an independent power supply?

And the early bootloader does also parse it, hence the diagnostic messages above.

It looks fine to me: $ grep gpio /boot/config.txt #dtoverlay=gpio-ir,gpio_pin=17 #dtoverlay=gpio-ir-tx,gpio_pin=18 gpio=2=op,dl which leads to: RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52 ... FAT32 clusters 130554 Read config.txt bytes 2130 hnd 0x6702 gpio_cmd: '2=op,dl'...

What is in boot.scr? Any references to fdt are particularly relevant.

I made a mistake - the sd_overclock parameter is currently only supported on the older Pis, and was intended to boost the clock as well as reduce it. Something similar could probably added to the sdhci-iproc driver used by BCM2711, but it isn't there yet. And you're right about the sdhci-iproc drive...

SD cards are meant to run as fast as they can, which for that interface is 50MHz. Linux has no standard way to change that. However, the Pi MMC/SD drivers have an extra setting that allows the clock to be changed. To run the interface at 20MHz, add "dtparam=sd_overclock=20" to confíg.txt. ...

> how i can enable the flow control of uart5? You've done enough to enable the flow control signals from the UART to appear on the 40-pin header, but: 1. The UART may not be configured to use them. RTS (strictly, nRTS) is driven low when the UART is ready to receive data. Similarly, it looks for low...

> in which version of kernel shows ttyAMA5?

The patch appeared in 6.1.26, so it should be included in yours. "ls /dev/ttyAMA*" if you're in doubt. Note that you might get different results if the Device Tree (dtb) files weren't also updated.

To see if the overlay has been applied correctly and is being used by the kernel, what does "raspi-gpio get 12-15" show?

Note that with one of the latest kernels, enabling UART5 results in /dev/ttyAMA5 appearing, not /dev/ttyAMA1.

Search found 4713 matches

Re: Sabertooth + Raspberry

Re: MCP23017 not seen in the i2c bus

Re: MCP23017 not seen in the i2c bus

Re: CM4 + nor-Flash - mount speed

Re: CM4 + nor-Flash - mount speed

Re: CM4 + nor-Flash - mount speed

Re: CM4 + nor-Flash - mount speed

Re: CM4 + nor-Flash - mount speed

Re: CM4 + nor-Flash - mount speed

Re: Adding wifi/ethernet to compute module 3+

Re: Adding wifi/ethernet to compute module 3+

Re: Adding wifi/ethernet to compute module 3+

Re: Issue to power my Raspberry Pi 4 with GPIO

Re: i2c-fan,

Re: Non Conflicting I2C device not working together (Pi Zero W)

Re: Non Conflicting I2C device not working together (Pi Zero W)

Re: Non Conflicting I2C device not working together (Pi Zero W)

Re: Invalid GPIO command 2=op,dl

Re: Invalid GPIO command 2=op,dl

Re: CM4: Mismatched revision code from bootloader vs cpuinfo

Re: Setting mmc0 4-bit mode actual clock speed on rpi4b

Re: Setting mmc0 4-bit mode actual clock speed on rpi4b

Re: CTS RTS Pin enable

Re: CTS RTS Pin enable

Re: CTS RTS Pin enable