I have noted elsewhere that if you just ask U-Boot to dump the addresses than contain the ROM you get synchronous aborts. It turns out that ATF (ARM trusted firmware - which runs before U-Boot) has locked down the address space so you get faults when you access the address range where the ROM is at. You could on one hand be annoyed (as I was), or you could reflect on the fact that this is actually a good thing for most software that will simply be screwing up if it tries to access these addresses.
What I did to dump the bootrom was to write my own little executable set up in such a way that it can be the only thing on a TF card and get booted. I made that little thing dump the bootrom to the console for me. Although the address space delegated to the bootrom is 64K, only 32K is actually used. See more here on my Github page along with a partially annotated disassembly of the bootrom.
What Marcin did was more or less the same. He added some code (as follows) to BL30 in the TPL stage:
void back_to_bootrom(enum rockchip_bootrom_cmd brom_cmd) { (...) char * p = (void *)0xffff0000; for (int i=0; i<32768; i++) { printf("%02x ", p[i]);
Marcin went through some suffering when he tried to replace the 16 Mbyte spi NAND with a bigger part. The story is that the bigger NAND parts use 4 byte addresses and the bootrom is only talking to SPI NAND using 3 byte addresses. Another can of worms entirely but worth mentioning.
Tom's electronics pages / tom@mmto.org