<Xogium>
so been trying to debug my board since yesterday... all I get over serial is this. Don't mind the weird optee version and such, it's been transmitted through git describe for some reason but fwiw it is 3.19.0 from st: https://paste.xogium.me/wv.txt
<Xogium>
trying to attach gdb to it and no matter what I use as binary, ATF, opteee, u-boot... I only get
<Xogium>
0x00000000 in ?? ()
<Xogium>
also when I try and run some commands I often get target was not halted
<Xogium>
I'm very confused, isn't openocd supposed to halt the target when you mess about with it ?
<bencoh>
iirc target gets halted upon gdb connection by default
bvernoux has joined #openocd
<Xogium>
bencoh: right... So why is it saying not halted ? Could my board by in a state where it can't be halted ?
<Xogium>
*be in
<Xogium>
also that memory address it gives is probably bogus
<PaulFertser>
Probably watchdog resets the board
<Xogium>
PaulFertser: hmm no serial is hung
<Xogium>
like it doesn't try to boot loop, it just hangs like that
<PaulFertser>
Xogium: I suggest you try without GDB and instead use just OpenOCD Tcl commands via Telnet.
<PaulFertser>
At this point
<PaulFertser>
To see and control everything that's happening.
<Xogium>
you mean like cpu register ?
<bvernoux>
Xogium, reset;halt often help
<Xogium>
will try
<bvernoux>
Xogium, what is the target MCU/CPU ?
<Xogium>
cortex a7
<bvernoux>
which target cfg are you using ? (did you try latest openocd 0.12 official too ?)
<Xogium>
stm32mp15x_dk2.cfg as board, and archlinux does have the very latest version :)
<Xogium>
I'm on the telnet interface but not really sure what to do using it
<bvernoux>
you can test reset;halt
<borneoa___>
Xogium: when the bootrom of stm32mp15x starts, the JTAG is disabled. Then it's up to the next SW in the boot chain to 'eventually' open the JTAG
<Xogium>
borneoa___: oh, I see. So you think it might not have poened it ?
<Xogium>
*opened
<borneoa___>
Xogium: IIRC, the latest SW release keeps JTAG off
<Xogium>
huh, so how are we meant to debug such issue ?
<Xogium>
I realy don't get what's up with it actually. I did nothing besides bump the ATF and opteee version and it behaves this way now
<Xogium>
well, apparently typing halt in there does work
<bvernoux>
type reg
<bvernoux>
to see if you see registers to confirm it is correctly halted
<bvernoux>
then you can try step by step
<bvernoux>
using step
<borneoa___>
Xogium: I know the ST wiki is not the top for accessibility. Anyway it contains instructions on using a tool (advertisement: made by me) named stm32wrapper4dbg. This tool slightly modifies the first binary (TF-A) to open the JTAG and wait for OpenOCD to attach. It makes 'reset halt' functional
<Xogium>
borneoa___: thanks :) so this would allow me to see what might be going on with the entire boot chain again, including optee and u-boot ? Alternatively, can I update components one by one to see which one breaks ? Keep ATF 2.6 for example, and only update optee to 3.19 ?
<borneoa___>
Xogium: then put the SD card in your Linux box and type: stm32wrapper4dbg -s /dev/sdb2 -d /dev/sdb1
<Xogium>
as far as I can tell ATF stage goes okay, but optee freezes. But who knows really
<borneoa___>
Xogium: this supposed sdb is the SD card. It takes the 2nd version in sdb2 and overwrites the default one in sdb1
<Xogium>
makes sense
<borneoa___>
Xogium: it's recomanded to keep TFA and optee from the same delivery
<Xogium>
yeah... Figured so
<PaulFertser>
bvernoux: nobody announced anything like that on the mailing list so that might mean nobody is working on it.
<PaulFertser>
bvernoux: something like that was mentioned few years ago but didn't get any traction.
<Xogium>
hmm
<Xogium>
borneoa___: well... That didn't seem to help
<Xogium>
Info : accepting 'gdb' connection on tcp/3334
<Xogium>
Error: timed out while waiting for target halted
<Xogium>
Error executing event gdb-attach on target stm32mp15x.cm4:
<bvernoux>
PaulFertser, ok thanks for the details
<borneoa___>
bvernoux: there is not a real roadmap for OpenOCD, as it accepts contributions by everyone. There is some discussion ongoing inside ST to add cmsis flash support in OpenOCD. But no schedule to finalize it.
<bvernoux>
PaulFertser, Does there is a roadmap for future version of openocd ?
<bvernoux>
borneoa___, cmsis flash support will be a very great things
<borneoa___>
bvernoux: there are pro and cons. Pro: we can reuse the cmsis flash binaries from chip vendors that don't care to add support to OpenOCD. Cons: we could reduce the interest to contribute to OpenOCD by keeping the "secrets" in the binary blob
<borneoa___>
bvernoux: from license point of view, OpenOCD cannot distribute the binaries, so user will have to look for them somewhere else, with all the mess of inconsistent versions and for sure limited or no support from OpenOCD mailing list
<bvernoux>
I thins the Pro is we can quickly add algorithm without coding anything
<bvernoux>
just coding the flash algorithm program/erase with the standard format defined by cmsis flash
<Xogium>
yeah okay the wrapper unfortunately didn,t help in solving the issue where halting is apparently timing out ?
<borneoa___>
Xogium: if you let the board boot and after a while you start OpenOCD, does it find the CPUs?
<Xogium>
borneoa___: I believe so. The logs appear to be normal anyway, finding hardware breakpoints and all of that
<borneoa___>
Xogium: yes, that's normal. CM4 is not started by Linux boot
<Xogium>
hmm
<borneoa___>
Xogium: the system uses on Linux side the driver remoteproc to manage the CM4. The binary for CM4 must be in Linux filesystem and is loaded with a Linux command.
<borneoa___>
Xogium: the alternative is to boot the platform in dev mode. In that mode the CPUs are all started but kept in infinite loop and JTAG is open. Nothing is booted automatically but user has to load a code through JTAG
<borneoa___>
Xogium: do you have the info for the boot switch of your board to start the dev mode?
<Xogium>
no... Hmm
<Xogium>
but still then, all the things I try to load in gdb to analyze report an address with all zeroes
<Xogium>
I guess I must go deeper using the telnet interface, to analyze more things. I just am not sure at all what I'm doing
<Xogium>
I hadn't realized the cm4 meant cortex m4. Damn tts and their abreviations... Why not just speak c m 4
<Xogium>
centimeter 4
<Xogium>
lol
<Xogium>
maybe I'm a dummy but here's what I try... arm-none-eabi-gdb /path/to/elf/file then tar ext :3334. So elf of bl2, elf of optee, elf of u-boot, even tried the kernel elf and I get 0x0000 all the time
slobodan has joined #openocd
<Xogium>
it's been a long time I used gdb and openocd so definitely not excluding the possibility that's a dummy here
<Xogium>
*that I'm a dummy rather
<borneoa___>
Xogium: port 3334 is for the cortex m. You need to use port 3333 for the cortex a
firelegend has joined #openocd
<Xogium>
... oooh. I thought it was only an alternate port. Somehow, that wasn't obvious to me at all :D
<Xogium>
okay I got something, sort of
<Xogium>
we,re hanging out in u-boot apparently, not optee
<Xogium>
I don't think this has got anything to do with optee being in ddr rather than in sysram these days ?
firelegend24 has quit [Quit: Client closed]
<borneoa___>
Xogium: TFA and optee should run quite fast, so halting in uboot is usual. Uboot also waits few seconds for a char on console to halt the boot and provide a prompt
<Xogium>
makes sense... But its halted there indefinitely
<Xogium>
I've shared logs of the boot btw
<borneoa___>
But now that you have run the wrapper tool, you can 'reset halt' and you will be at the very first instruction of TFA
<borneoa___>
Xogium: so you are in uboot, accordingly to the program counter, but no console output of uboot. Probably the old uboot is not compatible with the new TFA+optee. I neve tried this mix
<Xogium>
oh this is new u-boot
<Xogium>
atf 2.8, optee 3.19.0, u-boot 2022.01
<Xogium>
err 2022.10
<Xogium>
I've not modified the default config of u-boot for the board but for two things, the boot command and the env_mmc_use_dt or whatever it's called, since I don't have a partition called with the name it requires, but nothing that should so badly break u-boot to the point it just freezes like this
<Xogium>
borneoa___: do you have any ideas how I can probe at it further ? I have no clue what I'm doing aside from that typical bt full :)
bvernoux has quit [Quit: Leaving]
gzlb has quit [Quit: WeeChat 4.0.4]
indy_ is now known as indy
<borneoa___>
Xogium: what you mean that you don't have that partition? This version should be already based on FIP. When you flash the default ST image you get the SD card properly partitioned
<Xogium>
borneoa___: oh, I maybe wasn't clear on how I use this, sorry. This is in my own buildroot-based project, where I don't use the full bsp and grab individual components
<borneoa___>
Xogium: oops, never tried the buildroot version. What is the output of the build? A full binary image to flash, or only the single components and you have to assemble them?
<Xogium>
it makes a tf-a binary you flash to fsbl1 and fsbl2, and fip.bin
<Xogium>
so optee and u-boot
<Xogium>
genimage lets you flash them fine, but for updates right now I'm manually flashing them
<borneoa___>
Does the default build boot ok?
<borneoa___>
I mean, without your changes?
<Xogium>
I can try, give me a moment
<Xogium>
so I revert this CONFIG_ENV_MMC_USE_DT=n
diddly_ has quit [Server closed connection]
diddly has joined #openocd
<Xogium>
borneoa___: okay, behaves the same way
<borneoa___>
Xogium: so something broken in the buildroot release?
<Xogium>
I don't know... I'm confused
<Xogium>
I don't know how to really debug this
<Xogium>
this is my onw buildroot external tree btw, not the one from bootlin
<Xogium>
so probably if there's something messed up, I was the one who did it
<Xogium>
*own
<Xogium>
which is weird really because all I really did was bump the version of every part of the boot chain
<jn>
bumping the version of every part of the boot chain is a lot of change at once though
<Xogium>
jn: yes, but I don't really have much choice :/ it's recommended you keep the entire boot chain in sync
<Xogium>
as pointed out by borneoa___ earlier
<jn>
understandable but the "all i did" does some heavy lifting
<Xogium>
yes
<Xogium>
I totally agree
<Xogium>
well at least I'm guessing I hang in u-boot because u-boot is the problem... But I don't quite know what to do aside from downgrading it and seeing if it works. That would just let me know that new version is buggy
<borneoa___>
Xogium: I would give a try to the official buildroot, to check if the issue is already there.
bvernoux has joined #openocd
<Xogium>
borneoa___: righto, will try it
antto has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
antto has joined #openocd
antto has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
antto has joined #openocd
antto has quit [Client Quit]
antto has joined #openocd
nerozero has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit []
Hawk777 has joined #openocd
urja has quit [Read error: Connection reset by peer]
slobodan has quit [Ping timeout: 246 seconds]
urja has joined #openocd
bvernoux has quit [Read error: Connection reset by peer]