Raspberry Pi Forums

Yes, setting core_freq=250 should eliminate any UART glitching. It will also limit the VPU compute resource, which will mainly affect the new high quality analogue audio output, and could slightly increase the lifetime of the Pi (if there is any change at all).

@abelectronicsuk The next firmware release, due tonight, will included improved serial port alias handling: 1) It will search for any existing "serial0" in the DT, allowing the pi3-disable-bt alias to also disable the remapping. 2) It now searches for "=serial0", "=ttyAMA0" etc. instead of "config=....

That would be true on a system with a 1/3 kernel/user split, but we use a 2/2 split so it's all low mem.

I have seen corruption on ttyS0 on my Pi3, but then I noticed that the red LED was flickering due to under-voltage. This triggers a clock speed reduction. Upgrading to a better supply (2.5A) has solved that problem for me.

The DTB start address is size dependent. The aim is to copy the DTB as high as possible. Once the kernel starts it will "unflatten" the DTB into allocated memory and then re-use the space. 1 ARM memory starts at 0 in the VPU physical address space. The GPU memory sits at the top. This is how it work...

The code to load the DTB high is not conditional on its size. Making it so is possible, but it would mean that some problems would only be detected when the DTB reaches the threshold, and I much prefer systems to fail consistently.

The slot at 0x100 is limited to just under 16KB (0x3f00), and there have been situations where the fully resolved DTB exceeds that. I modified the loader to remove that limit by putting the DTB at the end of memory, in the same way that the initramfs followkernel option does.

The slot at 0x100 is limited to just under 16KB (0x3f00), and there have been situations where the fully resolved DTB exceeds that. I modified the loader to remove that limit by putting the DTB at the end of memory, in the same way that the initramfs followkernel option does. You can force a specifi...

@6by9 submitted a pull request against rpi-4.4.y (https://github.com/raspberrypi/linux/pull/1316) and I merged it.

You're welcome. I expect the question will get back to me eventually.

Try using console=serial1 in cmdline.txt. It will get mapped back to ttyAMA0. I'm working on a firmware update that will restore the original behaviour when the overlay is used, but for now this one weird trick is necessary.

It works for me. Which distribution are you using, and how did you get to this point - clean install, upgrade etc.?

That log looks perfectly normal. I was curious so I dug out an OpenElec card, tried the overlay and got the same result, i.e. no visible change in the requested pin. The driver appears to be loaded - /sys/devices/platform/power_ctrl exists, and doesn't if you don't use the overlay. The same configur...

The fact that /dev/i2c-1 is present shows that your software configuration is correct. You can confirm using raspi-gpio: sudo apt-get install raspi-gpio (if you don't have it already) raspi-gpio get You should see output that includes: GPIO 02: level=1 fsel=4 alt=0 func=SDA1 GPIO 03: level=1 fsel=4 ...

I've pushed the new overlay (pi3-disable-bt) to the rpi-4.1.y source tree. You can download a pre-built version here.

You are thinking about adding this into your HAT EEPROM to force the use of uart0 on pins 14 & 15, regardless of whether this is a Pi2 or Pi3? Technically it should work - the overlay will: 1) Disable uart1. 2) Enable uart0 and make it use pins 14 and 15. These should be a no-op on a Pi 2. What the ...

I'll put together an overlay that disables Bluetooth and UART1 and maps UART0/ttyAMA0 to GPIOs 14 & 15.

Run this after a reboot:

Code: Select all

sudo vcdbg log msg |& grep -v -E "(HDMI|gpioman)"

and let me know what it says. It may be that the overlay is absent.

Here - have a birthday present from Raspberry Pi - raspi-gpio.

If you copy it into the boot partition you can run it from /flash/raspi-gpio.

"raspi-gpio get" will show that the pin (the default is 26) is set to an output. Be careful with pin numbers - the kernel uses the Broadcom GPIO numbering, not the number of the pin on the 40-pin header. So pin 26 is actually GPIO 26 which is on header pin 37.

I'm glad to hear you got there in the end.

That sounds like false modesty - I'm sure you're just waiting for the chance to pick holes in jdb's work.

(I am winking heavily as I write this (no, read it again James)).

You probably want to stop sampling the input (or at least suppress the output) once the first button has been pressed, and send an "arm" signal back from the controller when you are ready for the next question.

You might find this RaspiTV article on RPi.GPIO interrupts interesting - it would make your game fairer, because it is effectively checks the buttons much more often.

I would guess that the reason you are running out of file handles is that the sender loop opens ser twice and closes it once. First, remove the second ser.open(). Then think about why you are opening and closing within the loop - it could be for a good reason like power management, but it might not ...

Search found 2762 matches

Re: Overlay to remap Pi 3 UART

Re: Overlay to remap Pi 3 UART

Re: device tree overlays and U-Boot

Re: Overlay to remap Pi 3 UART

Re: device tree overlays and U-Boot

Re: device tree overlays and U-Boot

Re: Why is start.elf loading my device tree to 0x17fed200?

Re: device tree overlays and U-Boot

Re: DT overlay for I2C pin selection

Re: Overlay for on/off push-button controller.

Re: Overlay to remap Pi 3 UART

Re: Overlay to remap Pi 3 UART

Re: Overlay for on/off push-button controller.

Re: Optional interfaces (I2C, I2S, SPI) and Device Tree

Re: Overlay to remap Pi 3 UART

Re: Overlay to remap Pi 3 UART

Re: Overlay to remap Pi 3 UART

Re: Overlay for on/off push-button controller.

Re: Overlay for on/off push-button controller.

Re: Overlay for on/off push-button controller.

Re: DiscoHAT compatibility for devices

Re: Analogue audio testing

Re: RX / TX UART

Re: RX / TX UART

Re: RX / TX UART