hand crafted svd won't load.

[hanetzer]

Hello. Doing some u-boot development for a hisilicon soc. No SVD exists for it (and
I really doubt they ever exist for cortex-a socs with an mmu) so I wrote my own
(well, I wrote it in yaml and used svdtools to convert it to xml), since at that point in
bootup its much more like an MCU.
My method of use:

1. clone this repo into the root of the u-boot repo
2. open gdb/connect to openocd/etc
3. source PyCortexMDebug/scripts/gdb.py
4. svd_load hi3516dv300.svd

result:

(gdb) source PyCortexMDebug/scripts/gdb.py
(gdb) svd_load hi3516dv300.svd
Loading SVD file hi3516dv300.svd...
Could not load SVD file hi3516dv300.svd : None...

hi3516dv300.svd.gz

[hanetzer]

so I fed the svd thru svdconv and picked out the errors and fixed them up, and it loads now.
In the future it may be worthwhile to have svd_load report more errors as to why it fails.

[bnahill]

Agreed on the error reporting. See issue #49.

Does this file now load?

I'm surprised there aren't quite as established formats for application processors. I guess maybe because they more commonly provide their own drivers or run Linux? There's no reason you can't write your own SVD--or more preferably as you mentioned, stay away from writing XML and just convert.

[hanetzer]

Yeah it was an error of mine; I had copypasta'd from a prior svd which had their uarts spread out every
0x1_0000 but this was every 0x1000, so there was overlap.
Yeah, full on linux-capable SoC's don't tend to have SVD files supplied, but I find this to be useful for two reasons:

1. if you can dump the bootrom from the device, you can feed the svd to ghidra to help re it
2. while you're at bootrom/u-boot level its still fairly 'dumb' and you can treat it as an MCU during debugging