<Hawk777>
Fleck: IIRC on ARM PC-relative addressing is relative to the address of the instruction plus four, in other words what PC *would be* after execution completed if the instruction were four bytes long (as they all were in original ARM).
<Hawk777>
Fleck: As for why it shows an instruction instead of .word, I would guess that some kind of ELF metadata is missing to tell it that location contains data and not code, or whatever tool you used to make this file doesn’t read that metadata, so it disassembled the bytes because it’s in a code section—as long as the bytes are what you want them to be, it doesn’t matter if they happen to also decode to a valid instruction.
tomtastic has quit [Ping timeout: 260 seconds]
tomtastic has joined #openocd
tsal has quit [Ping timeout: 252 seconds]
tsal has joined #openocd
boru` has joined #openocd
boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
thinkfat has quit [Ping timeout: 265 seconds]
thinkfat_ has joined #openocd
[itchyjunk] has joined #openocd
emeb has quit [Quit: Leaving.]
[itchyjunk] has quit [Read error: Connection reset by peer]
rgr has joined #openocd
nerozero has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
<Fleck>
aaand Hawk777 just left ;)
<Fleck>
I just got here :P
rgr has quit [Ping timeout: 265 seconds]
<Fleck>
so if I understand Hawk777, in my example, E2 address would also execute (to get 4 bytes from E0) wich gives PC=080002E4 and then add #4 as instructed? Confused...
tarekb has joined #openocd
tarekb has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #openocd
<karlp>
or just count #4 as 4 words, not four bytes...
<karlp>
or.... go and read the ISA.
<karlp>
it's freely available, if this sort of thing is interesting to you.
<karlp>
the instruction vs data is what hawk said though, you can't tell data and instructions apart from just binaries.
<Fleck>
don't get angry at me, I am really trying here
<Fleck>
but as I understand, it only works out if #4 is 4 halfwords...
<Fleck>
or if each address is 32bits, that can't be true? How can we get unaligned access then...
<Fleck>
also if each address is 32bit, then, #4 also doesn't work out...
tomtastic has quit [Ping timeout: 245 seconds]
gnom has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Remote host closed the connection]
<Fleck>
OK, I actually found the answer: Calculate the PC or Align(PC, 4) value of the instruction. The PC value of an instruction is its address plus 4 for a Thumb(I am using thumb...) instruction, or plus 8 for an ARM instruction.
<Fleck>
I wonder if ARM manual has error in it, #40 is decimal 40 or 0x40 as they say?
tomtastic has joined #openocd
<Haohmaru>
arm .svd file format allows writing numbers with # prefix, but i think it was for binary
<Haohmaru>
yeah, #01001110
wingsorc has joined #openocd
[itchyjunk] has joined #openocd
emeb has joined #openocd
[itchyjunk] has quit [Remote host closed the connection]
<Fleck>
Haohmaru: well, in asm it's a constant
<Fleck>
but usually in deciaml AFAIK
* Haohmaru
doesn't speak asm
<Fleck>
same :)
<Haohmaru>
but weren't there different syntaxes
Haohmaru has quit []
<Fleck>
usually it's 0x for hex. w/o for decimal, b for binary, but, IDK...
jerwd has joined #openocd
nerozero has quit [Ping timeout: 265 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
rudar has joined #openocd
akaWolf has joined #openocd
wingsorc has quit [Quit: Leaving]
<PaulFertser>
jerwd: hey! I see you have some nice patches there, thank you for contributing!
<jerwd>
Hey @PaulFertser! Thanks! I'm really happy to contribute. I've got even more on the way actually. Mostly around the ARM Coresight stuff.
<PaulFertser>
jerwd: I wonder if you know some article/guide/success story/conference talk about using those advanced features. I guess most developers, even those who frequently contribute to kernel have no clue how to approach that.
<jerwd>
I wish I had more information like that I could share. If I get the opportunity to share more things like that, I would be happy to though.
<PaulFertser>
jerwd: you probably can participate in some conference yourself and give an interesting talk. E.g. on ELC
<jerwd>
yep. ARM gives tons of these tools, but they have to be wired up in the ASIC at design time. It's pretty neat what you can do with it though.
<jerwd>
I think some of the ASICs out there do show how they have things connected in their docs if they are used.
<PaulFertser>
jerwd: yes, and some have proper "ROM table".
<jerwd>
Key word being _proper_ :)
<jerwd>
Wow, that manual you linked is quite extensive.
<PaulFertser>
Too bad the vendors do not provide essential info like that :(
<jerwd>
Yeah, that's very rare these days unfortunately.
<jerwd>
Not like the good 'ol apple ii where you even gave you the schematics. :)
<jerwd>
er where they that is
<clever>
jerwd: ive also seen some devices, where the jtag port appears to be wired to an internal gpio-ish pin, that can be bit-banged with mmio from a 2nd cpu
<clever>
i still need to investigate how exactly that thing works
<jerwd>
oh yeah, I've seen some variations on that theme over the years.
<clever>
jerwd: there is also a config flag, on if the jtag is routed to gpio or mmio
<clever>
and once the arm core has come out of reset, you cant change any of those flags
<jerwd>
that's cool, which parts have you seen that on?
<clever>
jerwd: all of the rpi soc's
<jerwd>
ah sweet!
<jerwd>
I have quite a few of those things laying around.
<jerwd>
on another project of mine, I ended up using the RPi PWM/DMA/FIFO to drive some of those WS281X LEDs. Bitbanging in Linux, with time critical frequencies wasn't working for obvious reasons.
<clever>
jerwd: the thing that still makes zero sense to this day, is this "bresp" table.....
<clever>
i think the MEMREP step, is what returns registers back to the reset default
<jerwd>
My experience with reading/writing to a unpowered domain is that you'll just get a bus hang and complete lockup. Maybe the endpoint is in reset?
<clever>
this platform has protections for that
<clever>
reads from an unpowered device return 0xdeadbeef
<clever>
and also raise an exception on the VPU
<clever>
exceptions function basically the same as interrupts
<clever>
jerwd: the vector table is an array of uint32_t[128]
<jerwd>
ah cool
<clever>
16 slots for cpu exceptions, like divide by zero, or bus errors(caused by other bus masters)
<clever>
16 slots for software interrupts (like `int 0x80` on x86)
<clever>
32 each*
<clever>
then 64 slot for peripheral interrupts
<clever>
since all opcodes must be 16bit aligned, bit0 of the addr is assumed to be 0
<clever>
the bit0 in the vector table, is then repurposed for a secure vs non-secure flag
<clever>
the VPU has a (non)secure state flag somewhere
<clever>
and you can configure any exception handler to be handled in the current? mode or the secure mode
<clever>
the official firmware, runs in non-secure mode, and certain security related MMIO are firewalled off
<clever>
there is then a syscall like api using software interrupts, to call certain special functions
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
rgr has quit [Ping timeout: 245 seconds]
<clever>
jerwd: also, all of the camera stuff i said so far, is purely just to get raw bayer images into ram
<clever>
the agc/awb control loops, and converting bayer into rgb/yuv, involve a hw component that is still blob controlled, and the engineers have stated that it will never get proper drivers from them
<jerwd>
ah bummer.
<clever>
the ISP is that secret sauce
<clever>
from what ive heard, it can do re-packing, debayer, lens shading, various stats collection, pixel format conversions, scaling, and several conversions to/from planar formats
<clever>
for example, the camera returns 10bit image data, packed in a rather weird format
<clever>
first, you have 4 bytes containing the upper 8 bits from 4 pixels
<clever>
then you have 1 byte, containing the lower 2 bits, from the same 4 pixels
<clever>
so, to get the full value for pixel 1, you need to do `uint16_t v = (buffer[0] << 2) | buffer[4] & 0x3`
<clever>
and then pixel 2, is (buffer[1] << 2) | buffer[4] & (0x3 << 2)
<clever>
jerwd: page 40, figure 17, shows each step of processing that happens within the ISP
<clever>
the image data goes along the top path, doing thru each stage, some of which output stats
<clever>
others take data in from the stats
<clever>
jerwd: i'm also starting to suspect if the camera sensor is even on...
<clever>
its supposed to be doing some 500mhz DDR stuff, but i'm not picking up any emi when i put a scope probe near the bus
<clever>
jerwd: modified the sensor driver, to record very single i2c transaction, now to find a datasheet leak....
<clever>
ah, this one doesnt seem like a leak
<clever>
it feels more like a proper release
<clever>
jerwd: ah, that looks useful the camera sensor can be configured to just emit a static color bar pattern, entirely ignoring the actual image sensor element
<clever>
that would at least eliminate the agc loop from the picture