boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
thinkfat has joined #openocd
thinkfat_ has quit [Ping timeout: 265 seconds]
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
nerozero has joined #openocd
<PaulFertser>
karlp: yes, I tested it and it worked for adding normal comments (but somehow line-by-line comments were added as top-level instead), I followed the Gerrit manual, basically, I have Gerrit e-mail type set to "plain", use normal quoting in mutt, do not remove any of the quoted content, just add my comments before the quote starts.
Haohmaru has joined #openocd
<clever>
i'm having some problems debugging an arm core
<clever>
every time i issue a `monitor halt` in gdb, it crashes the guest hard
<PaulFertser>
clever: when does the crash happen? After you resume?
<PaulFertser>
clever: why are you connecting with gdb but using monitor command to halt btw?
<clever>
PaulFertser: every time i reboot the target, the jtag interface stops responding temporarily
<clever>
and then the cpu is in the running state, but gdb thinks its halted
<boru>
What is the target?
<clever>
so i use `monitor halt` to make it actually halted
gnom has quit [Read error: Connection reset by peer]
<clever>
the 2nd time it enters virtual addressing, it has an exception, and the pc gets corrupted
<clever>
i cant set a breakpoint within that phase, because the addr isnt mapped
<clever>
and turning breakpoints on&off constantly, doesnt seem to be reliable, but let me try what you just said
<boru>
Are you using soft or hard breakpoints?
<clever>
boru: unknown
<clever>
i'm just running `breakpoint *0x1234` in gdb
<boru>
When you set a breakpoint in gdb for the first time, does it "warn" you that it's using hardware breakpoints?
<clever>
> Info : rpi2.a7.3: hardware has 6 breakpoints, 4 watchpoints
<boru>
Right, but is it using them?
<clever>
reconnecting to check...
crabbedhaloablut has joined #openocd
<clever>
boru: no warning, it just says it was added
<clever>
> Breakpoint 1 at 0x800028a0
<boru>
Try `-c "gdb_breakpoint_override hard"`
<clever>
openocb or gdb flag?
<boru>
OpenOCD.
<clever>
boru: and it correctly halted at start_kernel(), despite setting the breakpoint way back when it was only in physical mode!
<clever>
it still didnt warn about using hard breakpoints, but it did work
<boru>
Might be a target specific thing, I can't remember
<boru>
But I'm glad it works.
<clever>
now comes the next challenge
<boru>
I suspected it was something to do with the switch to virtual, as that often confuses debuggers when you're using soft breakpoints.
<clever>
earlyprintk works during the decompressor
<clever>
Uncompressing Linux... done, booting the kernel.
<clever>
linux can print this out
<clever>
but, thats the last thing it ever says
<clever>
if i break with gdb after failure, its off in the weeds
<boru>
Does it switch the ouput device to a serial port or display?
<clever>
it should stay on the serial port the entire time
<clever>
the display drivers arent working
<boru>
Perhaps it's off in the weeds and perhaps not. Do you have thread support enabled in gdb?
<clever>
only one arm core is enabled
<clever>
DTB doesnt tell linux how to start the other 3
<boru>
Anyway, it's not an openocd problem anymore, I think. Perhaps try some linux kernel channel. I'm a BSD guy, so I don't know a whole lot about how modern linux boots.
<clever>
so it shouldnt need to know how to manage the other 3
<clever>
should `catch signal all`, still catch faults here?
<boru>
Processor faults will go to fault handlers, but signals should go to gdb.
<clever>
i had read before, that processor faults get mapped to signals
<boru>
Seems reasonable.
<clever>
so gdb will treat it basically the same as a segfault
<boru>
I don't work with application processors and linux, so I'm afraid I won't be much help here. Stick around; perhaps someone else will offer more insight.
<clever>
most of my work has been in a barely documented cpu, the VPU on the rpi
<boru>
Is that broadcrap as well?
<clever>
i think its a variant of a synopsys DSP
<boru>
Ah.
<clever>
the official .elf file, has been branded by a synopsys linker, which can only be obtained under NDA
<clever>
boru: all of that, is going on, in its own core!
<boru>
I'd advocate keeping your debug environment as simple as possible until you get things figured out.
<boru>
Neat though, nonetheless.
<clever>
the rpi logo, is using the 2d sprite acceleration
<clever>
the triangle is using full on shaders
<clever>
and that whole thing, only uses 4% cpu
<clever>
baring coherency problems (it cant peek on the arm caches), this could spy on linux, and report boot progress in realtime
<clever>
if i knew what addresses to peek at
<boru>
So you're looking for MMIO regions, or some keyhole registers?
<clever>
i know where the MMIO is, but for some reason, once linux turns on the mmu, it just falls silent
<boru>
Probably needs to be configured to shift out to the correct place. IIRC, there are a bunch of people reversing that stuff. Are you working with them?
<boru>
The VPU OS and ISA, that is.
<clever>
i'm in all of the channels they would hang out in
* boru
nods.
<boru>
I'd check out other nets, also.
<clever>
kernel/printk/printk_safe.c:__printf(1, 0) int vprintk_func(const char *fmt, va_list args)
<clever>
currently, gdb is single-stepping thru that function
<boru>
You'll never see serious RE discussion on open/pub nets really.
<boru>
Not in a long time.
<clever>
another issue, is that when i `stepi`, it takes over a second to step
<boru>
Yes, as with C, all print formatting functions end up in a vprint* function eventually. That's where the real implementation typically resides.
<clever>
and it prints `rpi2.a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41` each time i step
<boru>
What frequency are you using?
<clever>
i think openocd gave a warning, that sysfsgpio cant set a speed
<boru>
Perhaps you've defaulted to some low frequency then.
<clever>
and i just branched off to vprintk_default()
<clever>
boru: how much do you know about the low-level of BSD? would you be interested in re-porting it to the pi, without the blobs?
<boru>
1) There are already people who have ported it. 2) I don't work with application processors.
<boru>
I know the innards of FreeBSD quite well, but I've got too many other projects.
<clever>
in reply to 1, that likely relies heavily on the closed-source firmware
<clever>
i'm working on the open firmware
<boru>
Well, they're probably willing to share their knowledge, regardless.
<clever>
i should get to bed now, and finish this tomorrow
<clever>
its almost 6am!
<boru>
Cherish being able to stay up hacking all night, whilst you're young.
<karlp>
PaulFertser: eh, I just pressed "reply" and added a comment on top, preserved the whole mail. nothing fancy, works for github mails at least...
<PaulFertser>
karlp: did you set delivery option to plain text? Gerrit might be defaulting to html, I'm not sure.
<PaulFertser>
karlp: I also was removing the "On NNN <someone> wrote:" line from my reply, but I guess it wouldn't harm parsing in any case.
<PaulFertser>
I've spent considerable time setting up a local IMAP4 server :( gerrit is for whatever reason not able to just read a local mailbox/maildir and wants POP or IMAP
<PaulFertser>
karlp: do you think I should see if I can make Gerrit send plain text by default instead?
<PaulFertser>
karlp: btw, I wasn't asking you to reword.
<karlp>
it's ok, don't worry about it, it was the second time in an hour that someone wanted to bikeshed some trivial text :)
<PaulFertser>
And Tarek didn't use your words verbatim anyway, and IMHO yours was a better version than what was pushed.
<karlp>
it's still an improvement over what was there.
<karlp>
at least it got merged in one form :)
<PaulFertser>
karlp: well, if I saw on someone else's website text like that it would slightly annoy me because bad grammar distracts from the substance. And if we can fix it before pushing to annoy fewer people IMHO that's a reasonable thing to do.
<PaulFertser>
I wouldn't mind this in source code comments.
<karlp>
well, I'll take poor english that's functional over "correct" but unclear and misleading
<karlp>
and hey, the whole thing is, you can make more than one cahnge!
<karlp>
it doesn't have to be fixed in one single commit with 1000 comments on it :)
<PaulFertser>
Indeed
<PaulFertser>
github does reasonable job getting replies to issues, not sure about line-by-line comments though
<PaulFertser>
"Please note that some email clients extract the text from the HTML email they have received and send this back as a quoted reply if you have set the client to plaintext mode. In this case, Gerrit only supports parsing a change message." so apparently parsing still didn't work. I could dig this more if there's a demand.
<karlp>
oh, I wouldn't even try doing line by line by mail :)
<karlp>
it's ok, I just wont ever try replyign again.
<karlp>
(via email)
cp- has quit [Ping timeout: 260 seconds]
zjason` is now known as zjason
tarekb has joined #openocd
c4017w_ has joined #openocd
c4017w has quit [Ping timeout: 240 seconds]
tlwoerner has joined #openocd
tarekb has quit [Read error: Connection reset by peer]