16:41 <polprog> my yesterday's s5pv210 (arm cortex a8) seems to be partly working, but I cannot issue any jtag reset command with 'reset halt' or 'reset run'

16:41 <polprog> the message im getting is s5pv210.cpu: how to reset?

16:41 <polprog> i have jtag reset config set (i believe) correctly

16:44 <polprog> What do i need to configure to reset that board?

17:54 <PaulFertser> polprog: do you have physical reset line connected to the target? Then you need "reset_config srst_only" (or trst_and_srst if you also have TRST connected)

17:54 <polprog> my board exposes nTRST and nRESET, they are tied together with a 330R and nTRST is pulled up to vdd

17:54 <PaulFertser> polprog: they shouldn't be tied together, why?

17:55 <polprog> im using a jlink with nTRST connected

17:55 <PaulFertser> polprog: to fully reset the target you need nRESET connected to SRST.

17:55 <PaulFertser> polprog: TRST isn't related to resetting the target at all.

17:55 <PaulFertser> polprog: it's just to bring JTAG state machine to "reset" state.

17:56 <polprog> thats how they are connected on the schematic, ill take a look at the board in a sec

17:56 <polprog> whether the resistor is fitted there

18:06 <PaulFertser> polprog: isn't nRESET routed separately?

18:08 <polprog> it is broken out separately on the connector, but the 330R is there and it connects nTRST with nRESET

18:20 <PaulFertser> polprog: that's silly, are you sure you do not want to desolder it?

18:20 <polprog> im reading up on what ntrst and nreset to and considering removing it yeah

18:20 <PaulFertser> polprog: there's "srst_pulls_trst" option in reset config which sometimes helps to deal with broken hardware like that.

18:21 <polprog> this board is full of old quirky stuff that ill desolder it and use nRESET from the jlink

18:39 <polprog> allright, ive separated reset and trst

18:46 <polprog> with reset_condig trst_and_srst I can now reset the board, but it drops connecton with the target when doing so

18:47 <polprog> http://0x0.st/HfBs.txt this is the log for reset run now

18:49 <PaulFertser> polprog: probably it has some ROM code that disables JTAG while it's executing

18:55 <polprog> probably the ROM that loads the first stage bootloader from SD card, since it can do secure boot

18:56 <polprog> it did hit the breakpoint..

19:02 <polprog> still broken, it does not hit the hardware breakpoints that I set and step is not working, i can halt it, and it halts (debug-request), but a subsequent step returns "tiemout waiting for target halt". It halts in a regular memory location, that is valid and i can read it

19:04 <PaulFertser> polprog: probably hw watchdog is running and resetting it?

19:04 <polprog> thats possible

19:04 <polprog> ill try to disable it

19:04 <PaulFertser> polprog: do you have serial output or other way to see it's booting?

19:05 <polprog> No, thats why im trying to use jtag debugging to see where uboot hangs

19:07 <PaulFertser> polprog: they routed out JTAG but not UART?

19:08 <polprog> They routed UART but i'm trying to build a version of uboot that puts something on any of the uarts

19:08 <polprog> I have a uboot tree that is said to work on the CPU, but not for this board

19:08 <polprog> I have the full schematic for the board and the rest of the documentation

19:09 <polprog> but the vendor uses their own bootloader and I really want to have uboot on it

19:09 <PaulFertser> polprog: if you set hw breakpoint at the u-boot entry then I would expect the watchdog to be not active. Unless there's some external that you can't disable.

19:10 <PaulFertser> polprog: also probably you want to try with telnet alone for starters, as interaction with GDB can get confusing. E.g. it removes all breakpoints after the target stops and reinstalls them when you ask to "continue" by default.

19:10 <polprog> The internal ROM loader disables watchdog. Then there is some vendor specific FSBL and then it loads uboot. Im not sure if the FSBL enables watchdog

19:14 <polprog> the wdt is disabled at this point

19:16 <polprog> i got something on the uart..

22:02 <silurian_invader> polprog: zynq?

22:17 <polprog> the good news is that i got u-boot configured correctly enough that the lowlevel_init prints "OK" to the UART

22:18 <polprog> the bad is that it hangs there and without working breakpoints it will take a lot of rebuilds...