Is there a SRST connected? That would suggest Ozone/J-Link is doing the CPU reset in-band via JTAG/SWD as SRST activation is just a simple local HW operation of the adapter and I do not see how OpenOCD would miss that?
Yes, both SRSTn and TRSTn are connected, verified on the schematics as well as that the 0-ohm resistors are there.
It works in OpenOCD as well, it just appears to be in a different place and gets triggered now.
Here is an interesting error:
Error: armada_7040.cpu: IR capture error; saw 0x4209 not 0x4209
BTW ignore the 7040 naming, I dont know why I used it for CN9130.
My IRMASK is really got to be wrong here, since if I use 0x7FFFF which as I understand should be correct then the error goes away but:
Open On-Chip Debugger 0.11.0+dev-00561-gdbbac5f11 (2022-02-04-10:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Dec 9 2021 14:14:49
Info : Hardware version: 11.00
Info : VTarget = 3.354 V
Info : clock speed 400 kHz
Info : JTAG tap: tx2_cn9130.cpu tap/device found: 0x07025357 (mfg: 0x1ab (Purple Ray), part: 0x7025, ver: 0x0)
Info : DAP transaction stalled (WAIT) - slowing down
Info : DAP transaction stalled during replay (WAIT) - resending
Config:
source [find interface/jlink.cfg]
transport select jtag
adapter speed 400
# TRST and SRST both exist, and can be controlled independently
reset_config trst_and_srst separate
# Define the _TARGETNAME
set _CHIPNAME tx2_cn9130
set _TARGETNAME $_CHIPNAME.cpu
jtag newtap $_CHIPNAME cpu -irlen 19 -ircapture 0x4209 -irmask 0x7FFFF -expected-id 0x07025357
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
target create $_TARGETNAME aarch64 -endian little -dap $_CHIPNAME.dap
And what you think about the watchdog for RB5009?
linux/arch/arm/dts/armada-7040.dtsi has this block:
watchdog: watchdog@610000 {
compatible = "arm,sbsa-gwdt";
reg = <0x610000 0x1000>, <0x600000 0x1000>;
interrupts = <0 2 4>;
};
So we just need to enable this watchdog device into DTS and that's it?
1 Like
It should already be enabled by default
Well at the moment it is not enabled in the kernel config.
# CONFIG_ARM_SBSA_WATCHDOG is not set
And what datasheet say about the watchdog?
That's a mistake then, cause its part of the AP806 itself.
Datasheet also states that there is a SBSA compliant watchdog
OK, thanks. Tomorrow I will try to turn it on and test.
I checked the watchdog. It works as expected. Thank you.
Nice, any luck with JTAG or anything else?
Hey folks
I have the device here as well and'd like to support. JTAG debugging is a bit too low level for me but anything else I can support you with?
Cheers,
Matthias
There is no progress with JTAG. I have it not work. I think the absence of a TRST pin on the JTAG connector is to blame for this. Nevertheless, I almost finished refining the RouterBOOT for loading FIT images from NOR flash.
1 Like
Great, that would avoid getting rid of RouterBoot.
I suppose its the aux-loader2 on you github?
So you are using it to boot the kernel ELF or U-boot?
Yes, but wait until tomorrow, I'm still working on it today!
It can run a kernel from FIT or ELF image by loading data from NOR.
It can also launch any payload (added to its tail) - ELF wrap mode.
So in a NOR flash you can write both: a FIT image and an U-Boot ELF.
1 Like
Ok, so you are basically appending this to RouterBoot and then you can boot whatever from NOR?
So, booting a U-boot ELF which then can boot from NAND?
What is the licensing situation, cause it needs to be GPL compatible if this is to be used by OpenWrt?
Here is a small tizer about RouterBOOT, auxillary loader and dual boot: OpenWrt from NOR and RouterOS from NAND.
1 Like
Yes exactly. Or, in general, you can start the FIT kernel from NOR(without U-Boot) and use NAND as rootfs (ubi).
The auxillary loader is under GPL, but its source code is not required to be included in OpenWrt. I did it on purpose! It is distributed as a small binary ELF file at the end of which a FIT OpenWrt initramfs image is added. Through it, the RouterBOOT is modified and then the RouterBOOT is already able to load a pure FIT image!
We will have to see then, Its hard to tell whether including a binary will be acceptable, especially when there is source code available.
Binary code is needed only once - to flash a modified RouterBOOT! Further, the new RouterBOOT is able to launch the pure FIT image via TFTP. So the binary code can easily not be included in OpenWrt.
Instead, for the initial write the new RouterBOOT, for example, you can use your U-Boot
or just do the following:
wget https://github.com/adron-s/aux-loader2/blob/main/releases/2.00-20220207/aux-loader.elf -O- > openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-fit-uImage.elf
cat openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-fit-uImage.itb >> openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-fit-uImage.elf
1 Like
Then we will just have to see hows its gonna go with the maintainters
1 Like
@adron I suppose one could still revert to RouterOS, even with the modified RouterBOOT?
Thanks for all the hard work. I should be getting my RB5009UG this weekend 