antto has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
antto has joined #openocd
bvernoux has joined #openocd
<Xogium>
borneoa___: yeah this one works. Ugh. Not really surprised there. I somehow keep hitting weird issues that noone's ever hit before
rkta has left #openocd [#openocd]
<olerem>
Xogium: any software is usually implemented and tested for some specific use case. If it is works for any one else is an accident :D
<Xogium>
olerem: yeah :) but I meant, I keep running into actual bugs sometimes, that noone's ever heard of before
<Xogium>
like there was this bug where sometimes, when the conditions were right, that linux kernel could get out of its own infinite loop after a panic and continue running whatever remained of userspace on cpu0. And it is only by luck you would run into it, because preempt and smp
<Xogium>
took us like 3 weeks to find it and squish it to death. This bug was positively ancient. We never found out what introduced it and exactly when, as it was present by the time of the dawn of git history
<olerem>
Xogium: we had a bug where putting bootloader to other, actually proper, location would trigger a cache corruption
<Xogium>
ow
<Xogium>
that's mean
<Xogium>
what happened ?
<olerem>
the reason was - ARM speculative executation was speculation it self in to IO mem. L2 cached got read error and responded with trash to L1 cache so CPU was executing trash instructions
<Xogium>
fwiw I increased the log level of u-boot all the way to 7 but all this does is making my board reset in a loop. My guess is u-boot is now crashing rather than hanging. Wonderful ! :D
<Xogium>
ouch. That's very bad
<olerem>
it was presend in all currently available boot loaders, becouse if it is executed somewehere in the middle of ram, then it would speculated most probably in to zeros, which is ok, except there RAM was not clean
<Xogium>
dang
<Xogium>
must have been difficult to debug
<olerem>
very. i wrote some openocd scripts to dump l1 instruction and data caches
<Xogium>
and I guess my bug whatever it is can qualify as heisenbug. Great. Boosting log level definitely altered the state by making it crash instead of hanging there. I have absolutely no idea what to do by now, besides downgrading the boot chain
gzlb has joined #openocd
<Xogium>
I know a bunch of ways to debug something but super low level gdb and openocd is definitely not one of my strengths
slobodan has joined #openocd
Hawk777 has quit [Quit: Leaving.]
<Xogium>
wouldn't it be dumb if all my problems come from dying micro sd storage haha
<olerem>
Xogium: there can be different source of problems, including bad RAM tuning, wrong PMIC configuration, not fitting PLL configs. Cross tolking between internal componnentes, etc
<Xogium>
olerem: yeah :/ I mean honestly all I did was to bump all versions of ATF, optee and u-boot to the new release by st
<Xogium>
I didn't tweak configs or anything like that except for a different bootcmd to load my bootscr script, and telling it the env isn't to be found via the dt
<Xogium>
but even with those fix not applied it fails the same way
<olerem>
Xogium: i feel your pain
<Xogium>
so I'm now very much confused
<Xogium>
I know that upgrading each component individually isn't to be done but I did it anyway, just to learn what can happen
<Xogium>
and also because I was curious
<Xogium>
upgrading ATF alone makes it panic because of the optee header, upgrading optee alone makes the same thing happen but the other way around, upgrading u-boot alone makes the board bootloop
<Xogium>
and of course upgrading all of them at once just makes it hang. And boosting the log level of u-boot in the hope to see something makes nothing but optee printing "I/TC: forced system reset"
<Xogium>
I reckon I've got my back against the wall so to speak
Haohmaru has joined #openocd
<olerem>
Xogium: are you sure, you load kernel to a working location?
<Xogium>
I'm not even getting to kernel
<Xogium>
I go from ATF to optee, then optee to u-boot... Which just basically hangs forever
<Xogium>
with nothing printed on uart
<olerem>
i work with some stm32mp1 based systems, which work fine so far, except i use mainline TF-A, no opetee for now and barebox instead of u-boot. but this information is probably no help for you
<Xogium>
I would like to, but I rely on power management unfortunately
<Xogium>
suspend to ram and all of those fancy things
<Xogium>
but if I could have done without, I'd have sure gone full mainline
<Xogium>
no offense to st of course they're brilliant. It's just, lets say that u-boot and I, we don't exactly enjoy each other's company ;)
<olerem>
Xogium: my work is bringing things mainline. so - i need to use alwys mainline
<Xogium>
of course yes, this makes sense :)
<Xogium>
frnakly by now I'm tempted to just screw it and go back to older versions of softwares bu for kernel, hoping 6.1 kernel can be booted fine using older ATF and such. All of this started because of a bug I'm trying to get rid of, where the otg port on the dk2 sometimes chokes to death until you reboot the board
rkta has joined #openocd
a3f has joined #openocd
dormito has quit [Ping timeout: 246 seconds]
<a3f>
I've an i.MX6Q (Cortex-A9) and I want to use OpenOCD v0.12.0 to set a memory watchpoint on an address. CPU is running bare-metal firmware in thumb mode. This works and on first access, the watchpoint is triggered. Now I remove the watchpoint, step a few instructions after the instruction which triggered the watchpoint, readd the watchpoint and resume, only to find the watchpoint trigger immediately again at the current instruction. This
<a3f>
happens whether I am using the shell over telnet or gdb. Any ideas or experience with watchpoints on Cortex-A9?
dormito has joined #openocd
<olerem>
borneoa___: may be you have more expiriance with this? ^
<olerem>
zapb_: ^ any may be you too :)
<Haohmaru>
baremetal on cortex-A hm..
<a3f>
Haohmaru, debugging a suspected memory corruption in the bootloader. unfortunately kasan didn't spot it.
<Haohmaru>
nah i was just thinking for one of my failed projects where i need muchos MHz
<Xogium>
borneoa___, PaulFertser, bvernoux: hot damn. You won't believe it. My boot issues were partly due to me messing something up but not so much. I was half joking this morning when I said, wouldn't it be dumb if it was my storage failing ? It was. I reflashed the previously perfectly working boot chain and it was failing
<Xogium>
I *HATE* micro sd
<olerem>
a3f: there are some differences in the watchpoint control register of A7 and A9. See:
<Xogium>
as in, I really, seriously hate those things
<olerem>
a3f: bits 13 - 5
<Xogium>
I did what I could to prevent degradation, not that there's a lot to be made given the way micro sd work, but it failed within 2 years. Pathetic
<Xogium>
the best I can do I guess is aim for slc micro sd... Ugh
<Haohmaru>
put an HDD on it
<olerem>
lol
<Xogium>
hdd over usb 2 ? Huh huh
<Xogium>
not sure ;)
<Haohmaru>
CDROM
<olerem>
will make you love micro SD :)
<Xogium>
^^
<Haohmaru>
CompactDisc(tm)
<Xogium>
I hate how micro sd failure is SO subtle you can't spot it easily 99% of the time
<olerem>
Xogium: i would bet, none of lowlevel init things support any kind of error handling or reporting for sd/mmc controller
<Xogium>
there was nothing that seemed off, really, but for the inconsistent behavior shown when you really dig into it. It used to work, it doesn't work anymore and you have no idea what happened and when it happened to be just over the edge
<Xogium>
olerem: no, generally you have no way of knowing. You can do reverse engineering like arnd likes to do with *cough* kingston micro sd
merethan has joined #openocd
<Xogium>
but aside from this, there's not many ways to see it coming. Even on so-called induistrial micro sd that have slc flash and claim to support smart, the info are minimal and often you need a specific program or at a minimum to sign an NDA to read how they encode the smart data, to be able to make your program to read them
<Haohmaru>
HDD with S.M.A.R.T. enabled ;P~
<Haohmaru>
wtf
<Xogium>
which... Honestly, I have a stupid idea that might work
<olerem>
Xogium: something what no one would implement in a boot loader anyway? :)
<Xogium>
using the micro sd to eMMC adapter that came with my odroid c2 years ago to stuff this bad boy into the dk2
<Xogium>
I'll lose like 90% of its hs400 speed but at least I'll have actual eMMC storage
<Xogium>
olerem: yes there's also that. Noone will have health checking in a bootloader. But thing is, who knows when the health starts to fail, really ? When does it become too much and alarm bells should start going off ?
<Xogium>
I've been dealing with boards that use micro sd for years and I still haven't found the answer to that
<olerem>
Xogium: i love to implement diagnostics, but it is something hard to sell. Usuall answer is: We need more bells, not diags!!!
<Xogium>
micro sd can fail in so various ways... Some very discretely like this one, where the failures accumulate day by day and sneak up on you and even then you struggle noticing it, some will on the other hand literally bit rot in your face. Yes I've seen that happening. Out of nowhere, on a perfectly fine running system, files were renamed and bit flipped all over
<olerem>
Xogium: you know, some file systems have checksumming?
<Xogium>
yep
<Xogium>
but what do you do when the failure reaches the bootloader ? :/
<olerem>
Xogium: and you are suing it?
<PaulFertser>
Xogium: SD cards are awful. Probably unless you buy them from mouser/digikey.
<olerem>
Xogium: checksumming bootloader and boot env still may tell you if something went wrong
<Xogium>
PaulFertser: honest that's what I plan on doing. Even then they are notoriously bad storage medium, and I'd use eMMC over them any day. But mouser doesn't sell low end crap
<olerem>
Xogium: can be bricked too :)
<olerem>
s//eMMC
<Xogium>
of course it can be bricked
<Xogium>
but at least the eMMC standard has specification of health status :)
<olerem>
ok. good point
<Xogium>
and since they work differently you can also literally tell the chip inside to behave differently with one partiton and not another (i.e: enhanced user area)
<olerem>
a3f: do you have your opinnion on eMMCs? :)
<Xogium>
as for checksum of the bootloader, I'm actually unsure how to do it. I mean, I can check the sha256 of the fip.bin and such, but how do I look at the one burned on the device to compare ? Surely it isn't as easy as passing the partition where the fip has been written, because there might be some empty space left, so that will of course give a different sha256
* Haohmaru
recently made a cortex-m4 bootloader with sha256 stuff
<Xogium>
PaulFertser: yeah that's what I plan on doing for this one here. I only have the one eMMC and the one adapter, but I might grab a few more of them
rkta has left #openocd [#openocd]
<Xogium>
this isn't perfect far from it... But... Ugh
<Xogium>
at least with eMMC when the health status changes you can check on it
<Xogium>
you can even make it so you get notified of that
<olerem>
Xogium:how?
<Xogium>
olerem: mmc-utils :)
<Xogium>
it has a command to read the registers which can expose the health status of the eMMC
<Xogium>
among other things
<Xogium>
so wrapping some script around this can definitely be useful
<olerem>
Xogium: ack, so there is still not central diagnostic infrastructure to nitify user or some other component about prefail conditions of some part
<Xogium>
unfortunately not. Technically it shouldn't be difficult to make since we've already got the health status info, just that noone'd done it
<olerem>
this kind of project is complicated enought to not do it a hobby time...
<Xogium>
something that runs in the background and probes at the status info, warning you if it changes in a pretty form... I don't think it'd be too difficult to make
<Xogium>
but yeah
<Haohmaru>
when corruption is detected - launch the matrix screensaver
<Xogium>
:D
<Xogium>
if you still can !
<olerem>
init a self destruction of the nuce power plant
<Haohmaru>
you have to have faith
<Xogium>
now, where the hell did I put that 64 gb eMMC
<Xogium>
;)
<Xogium>
I might even be nice and enable the enhanced user area so it gets a nice 32 gb of pseudo slc flash
<Xogium>
approximately 32 gb mind you
<Xogium>
cause honestly, slc micro sd is pricy... I've got a 512 mb one in another board for logging purpose and that was like 30 euros or something
<Haohmaru>
what's slc even
<Xogium>
single level cell
<Xogium>
i.e: instead of storing 2 bits per cell like mlc, or 3 like tlc... It stores one
<a3f>
olerem, my opinion is don't run your system off a SD-Card
<Xogium>
a3f: I agree ^^
<Xogium>
slc makes the cells last longer because they don't wear out as quickly since they store just one bit per cell
<a3f>
olerem, oh, thanks for the pointer! I will try to see if I can find their use sites in Linux and compare what openocd might be missing
<Xogium>
with the disadvantage that it is often slower and of course reduced capacity
<Xogium>
real slc I've seen can go up to max 2 gb afair. After that you jump straight to pslc which is basically software emulating how slc would behave and intentionally making it so data is stored one bit per cell
<Haohmaru>
huh
<Xogium>
some areas of a ssd are slc, the cache is one iirc. But the rest is basically all mlc at a minimum. The only ones that can have slc all the way are micro sd and eMMC afaik
<Xogium>
bootareas of eMMC that are mlc are also often emulated slc
<Xogium>
oh yes and of course the place where your ssd stores its firmware
<Haohmaru>
FRAM ftw
<Xogium>
I learned most of that chatting with an awesome person who worked on systems that were to go all the way up to the ISS
<Xogium>
:D
<Haohmaru>
i could've told you that flash memory is "meh" years ago if you asked me ;P~
<Xogium>
Haohmaru: of course it is
<Xogium>
but all those types, slc, mlc, etc. It's still nice to know how they work, I find
<Haohmaru>
and i don't understand the madness with these SSDs, they are flash too, right?
<Xogium>
worst of them all being qlc... God I hope they don't make one where they can store 5 bits per cell, 4 is already horrible
<a3f>
olerem, they seem to just have repurposed unused bits for hypervisor support. Linux doesn't treat the register differently between A7 and A9 (cf. encode_ctrl_reg())
<Xogium>
Haohmaru: yep they are
<Haohmaru>
i'm staying on HDDs then ;P~
<Xogium>
though, in all fairness to ssd, they seem to have way better firmware and flash quality than micro sd ;) not to mention they have smart data
<Xogium>
mine here is showing 10% worn out after about 3 years
<Xogium>
and that's with heavy compilation and stuff going on almost daily
<olerem>
a3f: cortex a9 is ARM_DEBUG_ARCH_V7 (or ARM_DEBUG_ARCH_V7_ECP14?) and cortex a7 is ARM_DEBUG_ARCH_V7_1, if i see it correctly
<a3f>
olerem, You're right. Cortex-A9 is indeed ARM_DEBUG_ARCH_V7_ECP14 and Cortex-A7 is ARM_DEBUG_ARCH_V7_1...
<a3f>
I thought Cortex-A7 being ARMv7.0 means debug arch is v7.0 too...
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
sam has joined #openocd
confused123 has joined #openocd
<sam>
Hi everyone, i am looking for some help with an issue i have encountered. i have 2 TAPs declared on a jtag chain. one of which is an ARM DAP (cortex-m) and the other a simple TAP. when we declare the ARM DAP as a cortex-m target we can communicate with the ARM just fine but when i try to access the other TAP with a drscan command i get the
<sam>
Assertion failed: active == tap, file /__w/openocd-xpack/openocd-xpack/build/win32-x64/sources/openocd.git/src/jtag/drivers/driver.c, line 141
<sam>
Debug: 40 28751 server.c:607 sig_handler(): Terminating on Signal 22
<sam>
but when i declare the DAP as a mem_ap target, i can access the other TAP just fine. Does anyone have an idea why this error happens in the first case?
confused123 has quit [Quit: Client closed]
<PaulFertser>
sam: probably you didn't disable polling?
<PaulFertser>
sam: with a target tap defined it's probably polled all the time. And for drscan to work you need IR regiser of the tap to have some specific value. But if the target is polled the other taps will be switched to BYPASS.
<sam>
Hi Paul, i indeed have not.. i was wondering if its something like that, but i was not sure how to do that..
<sam>
so i just have to use "poll off" when i want to communicate with the TAP and "poll on" when switching back to the DAP?
<sam>
yes, that indeed works! many thanks PaulFertser!
<PaulFertser>
sam: that's my guess, es.
<PaulFertser>
sam: happy to hear! :)
sam has quit [Quit: Client closed]
Chris__ has quit [Ping timeout: 245 seconds]
wingsorc has quit [Ping timeout: 246 seconds]
zkrx has quit [Ping timeout: 260 seconds]
Haohmaru has quit [Ping timeout: 240 seconds]
merethan has quit [Ping timeout: 244 seconds]
crabbedhaloablut has quit []
nerozero has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #openocd
crabbedhaloablut has quit []
josuah has quit [Quit: josuah]
josuah has joined #openocd
uartist7 has joined #openocd
rkta_ has joined #openocd
cozycactus_ has joined #openocd
cyrozap_ has joined #openocd
JakeSays_ has joined #openocd
JakeSays has quit [Read error: Connection reset by peer]
silurian_invader has quit [Ping timeout: 246 seconds]
xantoz has quit [Ping timeout: 246 seconds]
cozycactus has quit [Ping timeout: 246 seconds]
zmatt has quit [Ping timeout: 246 seconds]
cyrozap has quit [Ping timeout: 246 seconds]
uartist has quit [Ping timeout: 246 seconds]
cozycactus_ is now known as cozycactus
uartist7 is now known as uartist
xantoz has joined #openocd
bryanb has quit [Read error: Connection reset by peer]
lh has quit [Write error: Connection reset by peer]