Go to advanced search

by dradford
Mon Nov 28, 2016 11:10 am
Forum: Bare metal, Assembly language
Topic: RPI2 ARM MMU address translations
Replies: 7
Views: 2283

Re: RPI2 ARM MMU address translations

Yes, the HYP mode thing is very frustrating. I don't really see why the Linux kernel can't do the change to HYP mode itself if it wants, and let the device boot in secure-SVC mode as standard (which IMO is far more sensible).
by dradford
Tue Mar 15, 2016 12:24 pm
Forum: Device Tree
Topic: Overlay to remap Pi 3 UART
Replies: 126
Views: 122012

Re: Overlay to remap Pi 3 UART

Make sure that the pl011/UART0 function is only mapped to GPIOs 14 & 15. But if you are using a baremetal system then you won't be using Device Tree, so the overlays and kernel pinctrl should be completely irrelevant. Well, you can still use device tree in bare metal if you want. Frankly, the way e...
by dradford
Thu Mar 10, 2016 12:35 pm
Forum: Bare metal, Assembly language
Topic: multiple timers on RPi2?
Replies: 5
Views: 3452

Re: multiple timers on RPi2?

@arjan: IRQs aren't really the best option for precise timing (depending on how precise 'precise' needs to be). The latency is all over the place, especially if IRQs get disabled for any reason, or multiple interrupts need processing at the same time. IRQs are essentially assuming that the hardware ...
by dradford
Mon Mar 07, 2016 3:08 pm
Forum: Bare metal, Assembly language
Topic: RPI2 speed
Replies: 17
Views: 3607

Re: RPI2 speed

Whoops! Those DMBs need to be DSBs.
by dradford
Mon Mar 07, 2016 1:20 pm
Forum: Bare metal, Assembly language
Topic: RPI2 speed
Replies: 17
Views: 3607

Re: RPI2 speed

Apart from anything else, if you have multiple images on a card that you keep switching between, it's a nuisance having to remember to change the magic settings that need to be in your config.txt to get each to work. But you shouldn't really need to mess with config.txt to get a kernel to work. Real...
by dradford
Sat Mar 05, 2016 9:50 am
Forum: Bare metal, Assembly language
Topic: Rpi 2/3 irq
Replies: 3
Views: 1755

Re: Rpi 2/3 irq

You nominate 1 core to handle all peripheral interrupts. Other interrupts (like inter-core mailboxes) are routed separately. But it looks like you can send IRQ and FIQ to different cores, so if you don't mind losing FIQs you could divert ONE of the gpu interrupts to a separate core as an FIQ.
by dradford
Fri Mar 04, 2016 2:21 pm
Forum: Bare metal, Assembly language
Topic: Rpi 2/3 irq
Replies: 3
Views: 1755

Re: Rpi 2/3 irq

For IRQ routing on Pi2, try page 11 of this: https://www.raspberrypi.org/documentati ... rev3.4.pdf
by dradford
Fri Mar 04, 2016 12:01 pm
Forum: Bare metal, Assembly language
Topic: RPi 3 SMMU setup documentation
Replies: 4
Views: 1424

Re: RPi 3 SMMU setup documentation

The mapping had to be changed because the old one only allowed for 512MB of physical memory, so it seems reasonable to assume it will be the same as the Pi2. But that's just a guess.
by dradford
Fri Mar 04, 2016 11:40 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

I had to write it blind, so I may have got it wrong. I need to sort this out myself (properly), so I'll try and make some time to play with it at the weekend and let you know.
by dradford
Thu Mar 03, 2016 2:56 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

In that fragment there are 3 small gotchas: 1) You can't go to SVC mode directly from HYP. You need to ERET. 2) Setting an SVC stack won't help if the exception arrives in (say) UND (but I think you set up all the stacks earlier, so it doesn't matter). 3) VBAR is banked (secure and non-secure). Most...
by dradford
Wed Mar 02, 2016 3:06 pm
Forum: Bare metal, Assembly language
Topic: RPI2 speed
Replies: 17
Views: 3607

Re: RPI2 speed

Seems bonkers to be entering the kernel in a non-secure state, with such a complicated path back to secure SVC. I know you can reprogram r14_hyp and spsr_hyp then do an ERET to get out of HYP, but I'm not sure if you're going to end up back in a secure mode. If you don't, the only way I know would b...
by dradford
Wed Mar 02, 2016 12:12 pm
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

Ah, I get you now. But surely 0x00008040 is a defined instruction? ANDEQ.

Try asm(".word 0xe0700000") instead of the branch. I think that's an undefined mul on cortex-a7. I'll have to wait till I get home to double-check the one I normally use.
by dradford
Wed Mar 02, 2016 11:38 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

Actually, why would you want to b 0x20 anyway? There's no instruction there, just data.
by dradford
Wed Mar 02, 2016 11:28 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

Insert ".align 2" before the "uart_port:" label? It looks like it would be an unaligned load, which by default is a data abort (on pi1 anyway).
by dradford
Wed Mar 02, 2016 11:09 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

Sorry, I seem to have taken so long to write that that it's already out-of-date ;)
by dradford
Wed Mar 02, 2016 11:07 am
Forum: Bare metal, Assembly language
Topic: Vector table init at rpi2
Replies: 25
Views: 4778

Re: Vector table init at rpi2

I wouldn't mess with SCTLR, use the VBAR registers instead. They are set to 0 on boot, so they should be fine. There will be 3/4 you need to program: one for secure PL1, one for non-secure PL1, one for monitor mode, and one for hypervisor mode. The ARM boots in secure SVC mode. On a Pi1 your kernel ...
by dradford
Mon Feb 29, 2016 11:01 am
Forum: Bare metal, Assembly language
Topic: Timer interrupt resolution
Replies: 1
Views: 750

Re: Timer interrupt resolution

Have you considered FIQs? Very low latency response is what they're designed for, and they'll get processed even when normal interrupts are disabled. (There's also an ultra-low-latency interrupt setting in an ARM control register, but I wouldn't really recommend that.)
by dradford
Mon Feb 15, 2016 3:58 pm
Forum: Graphics programming
Topic: Framebuffer to TFT consuming lot of CPU
Replies: 7
Views: 3248

Re: Framebuffer to TFT consuming lot of CPU

The really nice thing about using SPI0 is that it can be fed directly from dma, and so your only cpu hits will be at the start and end of transfer, once per frame. (Of course, the extra bus traffic can slow down memory accesses by the cpu, but that's always going to be the case.) I'd urge you to rev...

Go to advanced search