OpenWrt Forum Archive

Topic: U-Boot mod for routers with AR9331/AR9344

The content of this topic has been archived between 3 Apr 2015 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

I have TP-WR940V2 with 4MB flash.
I mod flash from 4MB to 8MB with U-boot mod as this topic.
Now I installed firmware from TRUNK image(like 941v5) but I run
opkg update (OK)
opkg install luci-ssl xupnpd....
It had some error dont installed package.
Please tell me It had error because of 8Mb flash or have some bug in trunk package?
I do with 15.05.01 work OK

dktn wrote:

I have TP-WR940V2 with 4MB flash.
I mod flash from 4MB to 8MB with U-boot mod as this topic.
Now I installed firmware from TRUNK image(like 941v5) but I run
opkg update (OK)
opkg install luci-ssl xupnpd....
It had some error dont installed package.
Please tell me It had error because of 8Mb flash or have some bug in trunk package?
I do with 15.05.01 work OK

It's not related with this project, please don't spam this topic with that kind of problems.
Plus, next time if you want to ask for a help, don't write "some error", because we don't have any wizards on the forum.

(Last edited by pepe2k on 12 Apr 2016, 12:47)

Something is unclear to me: does the u-boot update page from httpd recovery need the full 128 KB image or just the 123 KB one? If I compile a new u-boot image from a newer commit and want to flash it from web recovery mode(httpd), do I need to use dd to combine it with original image or I can just go flash the 123 KiB image?

Also, what does AHB clock affect on a device with no USB port at all? Also, can you add more profiles for clocks? I want to try to overclock my tl-wr841n to 700 MHz CPU if possible. I run it at 620 MHz for a while and it seems to work fine.

(Last edited by user5077 on 12 Apr 2016, 14:09)

user5077 wrote:

Something is unclear to me: does the u-boot update page from httpd recovery need the full 128 KB image or just the 123 KB one? If I compile a new u-boot image from a newer commit and want to flash it from web recovery mode(httpd), do I need to use dd to combine it with original image or I can just go flash the 123 KiB image?

For TP-Link devices the U-Boot image should be withing 10-123 KB size. For web update it doesn't make any difference.

user5077 wrote:

Also, what does AHB clock affect on a device with no USB port at all?

I don't know exact internal schematic, but it's like a system bus with almost everything connected over it, not only the USB subsystem, but also GMACs, PCIE, WMAC etc. For example, on AR933x with AHB clock around 300 MHz Ethernet part is not working at all.

user5077 wrote:

Also, can you add more profiles for clocks? I want to try to overclock my tl-wr841n to 700 MHz CPU if possible. I run it at 620 MHz for a while and it seems to work fine.

Yes, I want to include profiles generator, just need to find time and finish it smile

@pepe2k, why does my firmware update form looks like this? It's missing ART and Uboot buttons and it's smaller, on another router is ok, but this is wierd
http://i.imgur.com/rP5ftHf.png

(Last edited by mile18 on 14 Apr 2016, 13:41)

mile18 wrote:

@pepe2k, why does my firmware update form looks like this? It's missing ART and Uboot buttons and it's smaller, on another router is ok, but this is wierd
http://i.imgur.com/rP5ftHf.png

Links for art and u-boot upgrade pages were removed from index.html long time ago (for safety reasons). You should go there manually (art.html, uboot.html).

pepe2k wrote:
mile18 wrote:

@pepe2k, why does my firmware update form looks like this? It's missing ART and Uboot buttons and it's smaller, on another router is ok, but this is wierd
http://i.imgur.com/rP5ftHf.png

Links for art and u-boot upgrade pages were removed from index.html long time ago (for safety reasons). You should go there manually (art.html, uboot.html).

Oh i didn't know that, thank you. Btw you can add support for WR-842ND v2 becouse it's the same as 841ND v8. Tested and working.

Sorry, but why leave only 4 KiB space for env variables? I need more space for them, anything I can do?..

user5077 wrote:

Sorry, but why leave only 4 KiB space for env variables? I need more space for them, anything I can do?..

Look at the schematic here: https://github.com/pepe2k/u-boot_mod#us … programmer
If you really need more space for env (btw. what for?), you can lower the image size and change env block size and address.

pepe2k wrote:
user5077 wrote:

Sorry, but why leave only 4 KiB space for env variables? I need more space for them, anything I can do?..

Look at the schematic here: https://github.com/pepe2k/u-boot_mod#us … programmer
If you really need more space for env (btw. what for?), you can lower the image size and change env block size and address.

OK, tried to set u-boot image to 96 KB, and modified env settings in ap143.h like this(for a 16 KB env space)

#if defined(CONFIG_FOR_TPLINK_WR820N_CN) ||\
    defined(CONFIG_FOR_TPLINK_WR802N)    ||\
    defined(CONFIG_FOR_TPLINK_WR841N_V9)
    #define CFG_ENV_ADDR        0x9F018000
    #define CFG_ENV_SIZE        0x4000
    #define CFG_ENV_SECT_SIZE    0x10000

The image was compiled, hope I modified it correctly.

user5077 wrote:
pepe2k wrote:
user5077 wrote:

Sorry, but why leave only 4 KiB space for env variables? I need more space for them, anything I can do?..

Look at the schematic here: https://github.com/pepe2k/u-boot_mod#us … programmer
If you really need more space for env (btw. what for?), you can lower the image size and change env block size and address.

OK, tried to set u-boot image to 96 KB, and modified env settings in ap143.h like this(for a 16 KB env space)

#if defined(CONFIG_FOR_TPLINK_WR820N_CN) ||\
    defined(CONFIG_FOR_TPLINK_WR802N)    ||\
    defined(CONFIG_FOR_TPLINK_WR841N_V9)
    #define CFG_ENV_ADDR        0x9F018000
    #define CFG_ENV_SIZE        0x4000
    #define CFG_ENV_SECT_SIZE    0x10000

The image was compiled, hope I modified it correctly.

The CFG_ENV_ADDR is wrong here, it should be 0x9F01BC00 (0x9F01BC00 + 0x4000 = 0x9F01FC00, where starts MAC address).

I used gcc-4.8-linaro_uClibc-0.9.33.2 from  trunk and it fail to work,do you have a try?

doiga wrote:

Since I couldn't find the version gcc-4.8-linaro_musl-1.1.11, I used gcc-4.8-linaro_uClibc-0.9.33.2 from barrier_breaker and it worked!
Thanks.

doiga wrote:

That may be the problem since I'm using gcc 5.3.0 and musl 1.1.14, the one on the u-boot wiki. I will try with the toolchain you said.

pepe2k wrote:

Seems like problem related with new gcc and/or musl.
Last version I have build images successfully was: toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.11

I will take a look on this problem next week and probably just include working toolchain in repository.
For now you can revert to earlier version in trunk and rebuild toolchain or use toolchain from previous OpenWrt release.

That version of gcc worked for me, but since it was updated to work with musl, as you can see here https://github.com/pepe2k/u-boot_mod/issues/95. Try with gcc-musl


longjun.tang wrote:

I used gcc-4.8-linaro_uClibc-0.9.33.2 from  trunk and it fail to work,do you have a try?

pepe2k wrote:
user5077 wrote:
pepe2k wrote:

Look at the schematic here: https://github.com/pepe2k/u-boot_mod#us … programmer
If you really need more space for env (btw. what for?), you can lower the image size and change env block size and address.

OK, tried to set u-boot image to 96 KB, and modified env settings in ap143.h like this(for a 16 KB env space)

#if defined(CONFIG_FOR_TPLINK_WR820N_CN) ||\
    defined(CONFIG_FOR_TPLINK_WR802N)    ||\
    defined(CONFIG_FOR_TPLINK_WR841N_V9)
    #define CFG_ENV_ADDR        0x9F018000
    #define CFG_ENV_SIZE        0x4000
    #define CFG_ENV_SECT_SIZE    0x10000

The image was compiled, hope I modified it correctly.

The CFG_ENV_ADDR is wrong here, it should be 0x9F01BC00 (0x9F01BC00 + 0x4000 = 0x9F01FC00, where starts MAC address).

Did that and my router won't boot anymore, only the first led is on, no serial output. Anything I did wrong?

user5077 wrote:
pepe2k wrote:
user5077 wrote:

OK, tried to set u-boot image to 96 KB, and modified env settings in ap143.h like this(for a 16 KB env space)

#if defined(CONFIG_FOR_TPLINK_WR820N_CN) ||\
    defined(CONFIG_FOR_TPLINK_WR802N)    ||\
    defined(CONFIG_FOR_TPLINK_WR841N_V9)
    #define CFG_ENV_ADDR        0x9F018000
    #define CFG_ENV_SIZE        0x4000
    #define CFG_ENV_SECT_SIZE    0x10000

The image was compiled, hope I modified it correctly.

The CFG_ENV_ADDR is wrong here, it should be 0x9F01BC00 (0x9F01BC00 + 0x4000 = 0x9F01FC00, where starts MAC address).

Did that and my router won't boot anymore, only the first led is on, no serial output. Anything I did wrong?

I have no idea and I always say: if you want to play with bootloader, make sure to have reliable and proven method for fix the device in case of total brick/corrupted bootloader (for WR841Nv9 take a look at https://wiki.openwrt.org/doc/recipes/de … using.jtag).

pepe2k wrote:

(for WR841Nv9 take a look at https://wiki.openwrt.org/doc/recipes/de … using.jtag).

Hi Pepe!

I bricked my TL-WDR3600 a few days ago by replacing the host_util LZMA 32bit binary with the 64bit one that ships with Ubuntu 15.10; it all compiled and looked fine, but bricked the router in the end.

After doing a binary diff with xdelta3, it showed almost 50% difference when using the host_util version vs. the Ubuntu one. Any idea if this is to be expected? Maybe there could be some sort of check that the correct LZMA binary is used in the Makefile? The uncompressed RAM version worked great, so I happily went on flashing ... :]

The debrick guide above allowed me to reflash u-boot successfully! Looks like this is a very good option for many devices now. I was looking for an JTAG option quite a long time before finding this, we should link it to every supported device page imho, at least to give some pointer that this could work.

With my router, I also had to remove a bootstrap resistor (for EJTAG mode switch) and short Pin 2 (Data Pin) of the SPI Flash to ground during powerup for the router to be recognized by OpenOCD.
See here: https://wikidevi.com/wiki/TP-LINK_TL-WDR4300

Used a Raspberry Pi3 for the JTAG interface (sysgpio), and only had to connect the GND, TDI, TDO, TMS and TCK pins. The WDR3600 is using the reference layout (at least for those pins): http://www.jtagtest.com/pinouts/ejtag

I think its a good idea -- or even required? to add the 'erase' option to the flash write_image operation. At one point I bricked the router so hard after writing uboot via JTAG, that I had to de-solder the SPI Flash for external re-flashing. Not sure if this happened due to a bad JTAG wiring or leaving out the erase before writing.
It seems to be depending on the degree/way the u-boot in Flash is messed up if shorting the SPI Data Pin to ground is enough to enter JTAG mode correctly (or not). At this point, it might be required to de-solder Pin(s) of the Flash, see also at wikidevi.
In my case, after the bad OpenOCD reflash, the device still showed up in OpenOCD; but flash probe command would fail, followed by permanent device probing errors. Almost took the Flash chip or connected HW-Parts for damaged, but external re-flashing worked like a charm and everything worked just fine again after soldering it back in. OpenOCD device detection was working again while the SPI Flash was removed, more evidence that it can mess with initialization.

After another brick...eh, chance to learn stuff, (and about the time it hit me about the LZMA), I flashed via EJTAG with erase option, followed by a dump_image of what was just written. MD5-sums matched and the router booted up just fine smile


In any case, thanks a lot for all your efforts Pepe! This is an awesome Project/u-boot version. Even my serial connection works flawless now in u-boot. Before it had lots of errors and only once the linux kernel driver loaded it was suddenly all fine.

Added two new OC profiles to push the CPU a bit higher,

In u-boot/include/cmd_qcaclk.h

        }, {
                720, 400, 200, 25,
                _qca95xx_spi_ctrl_addr_reg_val(8, 1, 0, 2),
                {
                        _qca95xx_cpu_pll_cfg_reg_val(28, 1, 0, 0, 0),
                        _qca95xx_ddr_pll_cfg_reg_val(16, 1, 1, 0, 0),
                        _qca95xx_cpu_ddr_clk_ctrl_reg_val(1, 1, 2, 1, 1, 1),
                        _qca95xx_cpu_pll_dither_reg_val(52),
                        _qca95xx_ddr_pll_dither_reg_val(0)
                }, {
                        _qca95xx_cpu_pll_cfg_reg_val(18, 1, 0, 0, 0),
                        _qca95xx_ddr_pll_cfg_reg_val(10, 1, 1, 0, 0),
                        _qca95xx_cpu_ddr_clk_ctrl_reg_val(1, 1, 2, 1, 1, 1),
                        _qca95xx_cpu_pll_dither_reg_val(0),
                        _qca95xx_ddr_pll_dither_reg_val(0)
                },
        }, {
                800, 400, 200, 25,
                _qca95xx_spi_ctrl_addr_reg_val(8, 1, 0, 2),
                {
                        _qca95xx_cpu_pll_cfg_reg_val(30, 1, 0, 0, 0),
                        _qca95xx_ddr_pll_cfg_reg_val(16, 1, 1, 0, 0),
                        _qca95xx_cpu_ddr_clk_ctrl_reg_val(1, 1, 2, 1, 1, 1),
                        _qca95xx_cpu_pll_dither_reg_val(52),
                        _qca95xx_ddr_pll_dither_reg_val(0)
                }, {
                        _qca95xx_cpu_pll_cfg_reg_val(20, 1, 0, 0, 0),
                        _qca95xx_ddr_pll_cfg_reg_val(10, 1, 1, 0, 0),
                        _qca95xx_cpu_ddr_clk_ctrl_reg_val(1, 1, 2, 1, 1, 1),
                        _qca95xx_cpu_pll_dither_reg_val(0),
                        _qca95xx_ddr_pll_dither_reg_val(0)
                },
        }, {

I'm not 100% sure what all those register values mean and took quite some good guesses how this should look like, but so far the router seems to be stable at 800 / 400 / 200 MHz. Performance has definitely increased quite a bit.
If you have some time, could you check if this looks correct? Or give some reference how to calculate these?
Thanks!

(Last edited by freezer2k on 18 Apr 2016, 18:59)

freezer2k wrote:

[...]
I bricked my TL-WDR3600 a few days ago by replacing the host_util LZMA 32bit binary with the 64bit one that ships with Ubuntu 15.10; it all compiled and looked fine, but bricked the router in the end.


Yep, this problem is old: https://github.com/pepe2k/u-boot_mod/issues/57
I should really take care of it...


freezer2k wrote:

After doing a binary diff with xdelta3, it showed almost 50% difference when using the host_util version vs. the Ubuntu one. Any idea if this is to be expected? Maybe there could be some sort of check that the correct LZMA binary is used in the Makefile? The uncompressed RAM version worked great, so I happily went on flashing ... :]


RAM image doesn't include compressed U-Boot image (take a look here: https://github.com/pepe2k/u-boot_mod/bl … efile#L112) and any low-level code, so it doesn't make sense to rely on RAM version tests.

RAM version should be use only for JTAG approach (low-level and RAM initialization is done using JTAG, then RAM version of the U-Boot is loaded to the device and used to transfer "FLASH" U-Boot image over network etc.). I will include support for OpenOCD for all supported SOCs as soon as I find more free time.

The easiest way to fix this problem would be include correct LZMA library sources with the code and build them on demand, I will think about it.


freezer2k wrote:

The debrick guide above allowed me to reflash u-boot successfully! Looks like this is a very good option for many devices now. I was looking for an JTAG option quite a long time before finding this, we should link it to every supported device page imho, at least to give some pointer that this could work.


Fully agree, this guide is really useful.
I have plans to include some guides and ready tools in my repository for JTAG debricking.


freezer2k wrote:

With my router, I also had to remove a bootstrap resistor (for EJTAG mode switch) and short Pin 2 (Data Pin) of the SPI Flash to ground during powerup for the router to be recognized by OpenOCD.
See here: https://wikidevi.com/wiki/TP-LINK_TL-WDR4300


For the FLASH, it should be enough to use HOLD or CS signals instead of DATA, IMHO it's proper way to "disable" FLASH chip.

About the EJTAG mode... I have several WDR3600/4300 and some of them have this bootstrap resistor, other don't.


freezer2k wrote:

[...]
I think its a good idea -- or even required? to add the 'erase' option to the flash write_image operation. At one point I bricked the router so hard after writing uboot via JTAG, that I had to de-solder the SPI Flash for external re-flashing. Not sure if this happened due to a bad JTAG wiring or leaving out the erase before writing.


For NOR FLASH you should always perform erase before write and it's because of how that memory type works. During write, you can only change individual bits to zero and erasing sets all bits in blocks/sectors to 1.


freezer2k wrote:

In any case, thanks a lot for all your efforts Pepe! This is an awesome Project/u-boot version. Even my serial connection works flawless now in u-boot. Before it had lots of errors and only once the linux kernel driver loaded it was suddenly all fine.


You're welcome smile


freezer2k wrote:

Added two new OC profiles to push the CPU a bit higher,
[...]
I'm not 100% sure what all those register values mean and took quite some good guesses how this should look like, but so far the router seems to be stable at 800 / 400 / 200 MHz. Performance has definitely increased quite a bit.
If you have some time, could you check if this looks correct? Or give some reference how to calculate these?
Thanks!


I will include more PLL/clocks profiles, but I need to test them on scope. All profiles which are already in code were tested and confirmed on scope as it turned out that VCO (voltage controlled oscillator) has limitations and even if you think that the clock is 600 MHz (remember, clock is just calculated from registers values), it could be totally different.

For PLL/clock calculations you can refer to this file:
https://github.com/pepe2k/u-boot_mod/bl … a_clocks.c

And pages 39~41, 138~145 in datasheet:
https://github.com/Deoptim/atheros/blob … AR9344.pdf

Hello pepe2k! Is it possible to add support for the Zsun WiFi SD Card Reader? It's AR9331 based and a really nice candidate for a weather station project I'm pondering. wink I would love to see some serious underclocking capabilities if possible. From what I have read you can go so low as 100/100/100 on it. It should give quite some savings I think.

OpenWRT is already supported and flashing is fairly easy. It got really good specs for both the size and cost:
https://wiki.hackerspace.pl/projects:zs … r#hardware

Lennong, I've asked the same thing several days ago. He has it on the todo list, we just need to wait.
Were you able to make HT40 mode working? Mine is stuck at 20MHz making 72Mb/s rate max.

Antinomy wrote:

Lennong, I've asked the same thing several days ago. He has it on the todo list, we just need to wait.
Were you able to make HT40 mode working? Mine is stuck at 20MHz making 72Mb/s rate max.

You will never get HT40 mode with that hardware. You need at least two streams (tx-rx/antennas) with a certain distance between them to be able to do HT40.

Hello,
I just want to say thanks to Pepe for making this mod. I was tested it on  TL-WR740N v5 and it work fine, tried it on version 6 - router was bricked.
Is there any chance TL-WR740N v6 to be supported? (as long as I read it is 841N v10 identical)

(Last edited by nedoskiv on 22 May 2016, 13:14)

Hi pepe2k!
I want to disable LED LAN blinking every boot on my tplink 740 V4. Could you help me!
Thanks in advance!

(Last edited by hoatienii on 6 Jun 2016, 05:12)

freezer2k wrote:

The debrick guide above allowed me to reflash u-boot successfully! Looks like this is a very good option for many devices now. I was looking for an JTAG option quite a long time before finding this, we should link it to every supported device page imho, at least to give some pointer that this could work.

You mind sharing more details about this?
When i apply the patch I get the following errors:

$ git apply -3 < ath79.patcherror: Anwendung des Patches fehlgeschlagen: src/flash/nor/Makefile.am:32
Falling back to three-way merge...
Applied patch to 'src/flash/nor/Makefile.am' cleanly.
Falling back to three-way merge...
Applied patch to 'src/flash/nor/ath79.c' cleanly.
error: src/flash/nor/drivers.c ist nicht im Index
error: Anwendung des Patches fehlgeschlagen: src/flash/nor/spi.c:61
Falling back to three-way merge...
Applied patch to 'src/flash/nor/spi.c' cleanly.

The make also fails and I guess it is related to patching before:

............
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -I../../../src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DBINDIR=\"/usr/local/bin\" -I../../../jimtcl -I../../../jimtcl -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -MT drivers.lo -MD -MP -MF .deps/drivers.Tpo -c drivers.c -o drivers.o
drivers.c:23:1: error: expected identifier or ‘(’ before ‘<<’ token
 <<<<<<< ours
 ^
drivers.c:27:1: error: expected identifier or ‘(’ before ‘==’ token
 =======
 ^
drivers.c:34:1: error: expected identifier or ‘(’ before ‘>>’ token
 >>>>>>> theirs
 ^
drivers.c:42:28: warning: redundant redeclaration of ‘cfi_flash’ [-Wredundant-decls]
 extern struct flash_driver cfi_flash;
                            ^
drivers.c:33:28: note: previous declaration of ‘cfi_flash’ was here
 extern struct flash_driver cfi_flash;
                            ^
drivers.c:52:28: warning: redundant redeclaration of ‘lpc2000_flash’ [-Wredundant-decls]
 extern struct flash_driver lpc2000_flash;
                            ^
drivers.c:29:28: note: previous declaration of ‘lpc2000_flash’ was here
 extern struct flash_driver lpc2000_flash;
                            ^
drivers.c:53:28: warning: redundant redeclaration of ‘lpc288x_flash’ [-Wredundant-decls]
 extern struct flash_driver lpc288x_flash;
                            ^
drivers.c:30:28: note: previous declaration of ‘lpc288x_flash’ was here
 extern struct flash_driver lpc288x_flash;
                            ^
drivers.c:54:28: warning: redundant redeclaration of ‘lpc2900_flash’ [-Wredundant-decls]
 extern struct flash_driver lpc2900_flash;
                            ^
drivers.c:31:28: note: previous declaration of ‘lpc2900_flash’ was here
 extern struct flash_driver lpc2900_flash;
                            ^
drivers.c:55:28: warning: redundant redeclaration of ‘lpcspifi_flash’ [-Wredundant-decls]
 extern struct flash_driver lpcspifi_flash;
                            ^
drivers.c:32:28: note: previous declaration of ‘lpcspifi_flash’ was here
 extern struct flash_driver lpcspifi_flash;
                            ^
drivers.c:84:1: error: expected expression before ‘<<’ token
 <<<<<<< ours
 ^
Makefile:521: die Regel für Ziel „drivers.lo“ scheiterte
make[5]: *** [drivers.lo] Fehler 1
make[5]: Verzeichnis „/home/sr/openocd/src/flash/nor“ wird verlassen
Makefile:476: die Regel für Ziel „all-recursive“ scheiterte
make[4]: *** [all-recursive] Fehler 1
make[4]: Verzeichnis „/home/sr/openocd/src/flash“ wird verlassen
Makefile:620: die Regel für Ziel „all-recursive“ scheiterte
make[3]: *** [all-recursive] Fehler 1
make[3]: Verzeichnis „/home/sr/openocd/src“ wird verlassen
Makefile:457: die Regel für Ziel „all“ scheiterte
make[2]: *** [all] Fehler 2
make[2]: Verzeichnis „/home/sr/openocd/src“ wird verlassen
Makefile:514: die Regel für Ziel „all-recursive“ scheiterte
make[1]: *** [all-recursive] Fehler 1
make[1]: Verzeichnis „/home/sr/openocd“ wird verlassen
Makefile:422: die Regel für Ziel „all“ scheiterte
make: *** [all] Fehler 2

The only change I did was to add --enable-buspirate and remove the parport stuff since I use the buspirate as interface.

sebr wrote:
freezer2k wrote:

The debrick guide above allowed me to reflash u-boot successfully! Looks like this is a very good option for many devices now. I was looking for an JTAG option quite a long time before finding this, we should link it to every supported device page imho, at least to give some pointer that this could work.

You mind sharing more details about this?



I'm not sure about your patching, but it looks like the fallback mode patched correctly?

Never seen these compilation errors.

With the latest OpenOCD and for flashing only, I think this patch is not even required.
There should be a ath71xx? target that works with the same config. Config might need some adjustment based on which flash type is used.

Thanks for your reply. Now I used the patch command and it revelaed that /src/flash/nor/drivers.c was not patched. Since it was only two additional lines I added them manually. Now no errors and I can build OpenOCD without errors.
But I cannot communicate with the target or halt it. The bootstrap resistor is not present. Since I have only connected VTref, GND, TDI, TDO, TMS and TCK the reset configuration of my buspirate should not matter. Here is the interface config.I wonder what I am doing wrong.