JTAG transfer speed of firmware very slow when dumping Starbridge Lynx 210 using Bus Pirate

I tried to back up the firmware of an old router I got for experimentation purposes using a Bus Pirate v3.6, but even after 2 hours, I noticed that OpenOCD hadn't finished downloading it. I later tried to get 256 bytes from the flash, and to my surprise, I got this message:

Info : JTAG tap: ti-ar7.cpu tap/device found: 0x0000100f (mfg: 0x007 (Hitachi), part: 0x0001, ver: 0x0)
target halted in MIPS32 mode due to debug-request, pc: 0x94028560
dumped 256 bytes in 10.641017s (0.023 KiB/s)  <----

I'm aware that the Bus Pirate was probably not the best buy and a stlinkv3 or something might have dumped it at a significantly higher speed, but I still doubt this is normal behavior. I could have tried to access the flash directly, but it doesn't seem to use SPI (I'll put a link to the datasheet if I find it again), and honestly I don't think I can solder some wires to such small IC without risking it getting burned. I'm willing to try it if I have no other choice thought. I think it's also worth noting that I already dumped the firmware using tftp via the router's shell, but I'll also like to be able to do it from JTAG in case I screw up with the bootloader (which I'm planning on poking later). Any ideas as to what I might be doing wrong? or is this expected from the BP?

I don't know if this might be of any help, but I made a hackaday post about my progress with the router. I posted some updates there, so you can take a look at it in case you want more info. And of course, feel free to ask me any questions! I'm new to this whole reverse engineering thing, but I'll try to provide as many details as I can.

By the way, you may have probably noticed by now, but this is more of a pet project of mine if nothing else. My end goal would be to make it run a custom, stripped down version of Attitude Adjustment (which is the image someone recommended me to try out first), but I don't plan on using this for any practical purposes.