Hopefully before this bites me I will remember that you told me about it...I am not doing anything that is moving data from one peripheral to another or timing critical between peripherals. The write buffer shouldnt be in play if the caches are off. I wonder if it is I cache only and not d cache if data still gets hung up in the write buffer.DexOS wrote:I agree with you dwelch67 and feel your pain, i would go as far as to say if you want to learn bare metal coding chose another Arm, i have worked on a lot of different processors and this one is really a pain.
Code should work or not work, there should be know gray areas.
I read some where that ATAGs start at offset 0x100, but this was for general linux.
As a side note, you do know about the need to "memory barrier"When changing between ARM peripheral see page 7 of the BCM2835-ARM-Peripherals.pdfCode: Select all
MemoryBarrier: mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache mcr p15, 0, ip, c7, c5, 6 @ invalidate BTB mcr p15, 0, ip, c7, c10, 4 @ drain write buffer mcr p15, 0, ip, c7, c5, 4 @ prefetch flush mov pc, lrAccesses to the same peripheral will always arrive and return in-order. It is only when
switching from one peripheral to another that data can arrive out-of-order. The simplest way
to make sure that data is processed in-order is to place a memory barrier instruction at critical
positions in the code.
Even treating it as a microcontroller $25 or $35 I guess buys you a lot, the sdm32f4 discovery is what I would consider a competitor to this and yes has much better documentation, I/O, etc. Supposedly the Raspberry Pi goal is programming education, providing computers to kids who might not otherwise have one. Bare-metal programming is educational as well and I feel a skill being lost so not the best platform but if they are even marginally successful, a small percentage of the small percentage that have one and try to program will try something low level, so I hope to have some starting points.
Definitely true, though, this is not a low level platform for beginners in general, too many secrets, too many surprises, too much hacking required to get anything working. All the things that cause a percentage of the folks that try to fail and never come back (to low level programming).
Will see what happens, if it starts towards arduino like success, before it gets there it will need better docs and less surprises if we figure it out through hacking or from the vendor.
