How to install to RB750GR3?

fawz · December 21, 2017, 1:03am

It's very unlikely that you actually permanently damaged the router. I initially had a lot of trouble getting flashrom to work simply due to bad/flaky connections to the flash chip. I first tried to connect the bus pirate directly to the chip with "custom" wire-connections, but the only thing that gave me a stable connection was using a SOIC8 clip/clamp like this SOIC8 clamp.

@pen Don't use the 10 pin header that's next to the flash chip. I also first tried using it, but it seems to go through additional circuits on the board and I couldn't use it directly with the flashrom flasher (IIRC a pin was "missing"/couldn't determine its corresponding chip pin). Connect to the chip directly. The chip is as specified on the wiki, and you can find a datasheet by googling for it. Make sure you note where pin one is by comparing where the little dot on the chip is to where it is on the datasheet drawing.

@RicoBelo I recommend getting a clamp and not unsoldiering the winbond chip yet. Make sure you get a good solid connection to the chip and flashrom should work. Also make sure to connect the HOLD and WP pins to 3.3V as shown on the bus pirate's flashrom page. Also, if you try to power it through the Mikrotik's power supply (which I haven't tried), you might need to constantly apply the reset button according to flashrom's wiki pages. However, the bus pirate takes a long time to read/write (2-3 hours for me), so that's impractical.

If you can unsoldier the chip, that's great. But it is very fiddly if you've never done it before. Try the clamp directly first.

Edit: Lastly, to make sure not to brick your device in the future, try to read the flash contents 2-3 times to different files first and use something like "diff -s" to make sure that they all turned out identical. Then you know your connection works, and you know you have a stock image to flash back.

RicoBelo · December 21, 2017, 3:25pm

@fawz First thanks for you reply !
I checked that /HOLD and /WP are effectively wired to VCC, so it' ok at this point ! I tried to power the card from the Bus Pirate but the card drawn too much current for the flasher, that's why I powered it from the card itself. Maybe because the 5x2 pins header is also powering side circuits as you suggest...

By the way, I ordered on Ali Express a SOIC clamp, as well as some Winbond chips, just in case of mine is dead. I'll try to re-flash with on clamps in-ciruit first, and if it still fail I'll flash a new chip then I'll replace it on the board...

Stay tuned

fawz · December 21, 2017, 8:44pm

@RicoBelo That sounds good! It may be that something on the board is interfering. If you have spares for the chip and you can make sure that you can flash those spares, then it's probably the circuit, yes. Very nice!

If you have to desolder the chip from the circuit board, just make sure to not rip the pads off the PCB, as that can be hard to fix. The chip isn't that hard to break, and you'll have spares.

This is something that helped me at one point: get a thin wire or pin to slowly lift the desoldered pins off of the pcb: carefully lifting a chip from a pcb. Of course a hot air solder gun is better/also nice, as well as soldering paste etc.

Good luck! If you need the stock image I can upload that somewhere, though you might be able to reconstruct it yourself.

RicoBelo · January 5, 2018, 9:06am

Hello, I'd like to share my feedback regarding the issues I encountered while flashing the board.

So I received my Ali Express order with the SOIC8 clamp and 5 spare W25Q128 chips. I first tried to flash one again the board using the clamp and powering the chip from the Bus Pirate VCC but it failed while trying to write.

Then I tried to flash one of my spare chip (using the clamp connected to the Bus Pirate) and it worked fine without any error ! So I unsoldered the SPI chip from the board and replaced it with the flashed spare chip and then...

It booted LEDE !

So I wonder I fried something on the original chip. I don't know exactly how, maybe when I fried the RPI during my first attempts to flash the SPI chip using the RPI ?

By the way, I suggest you to update the OpenWRT RB750Gr3 page with the following mention:

avoid trying to flash the chip through the SPI headers as it will drive to much current for the Bus Pirate. Use a SOIC8 clamp instead.
flashrom refused to flash my image built with your instructions because the file size was smaller than the chip capacity. I had to pad the file with binary zeros to fit 16M and let flashrom be happy. I probably could have use flashrom's layout feature instead but I didn't tried...

Also, if anybody here need a spare W25Q128 chip, I can ship one for the cost of the stamp

Thanks for your help !

sidepipe · January 8, 2018, 4:06pm

For info, I've now added details of how to connect a programmer to the gr3 to the wiki so you can re-write the flash without taking it off the pcb. It's actually very simple. Couldn't upload any pictures ( just said "failed" ) but it's ok without.

I still think it's easier to install LEDE using netboot though

tkellen · May 28, 2018, 2:42pm

@sidepipe I just ran through your instructions for netbooting (trying to jailbreak rather than switch to openwrt, though). Thank you!

Wondering if you could share any insight on how to mount the flash? Notes below.

I was able to netboot to OpenWRT using the instructions in section "Replacing U-Boot Using LEDE" of this page

Of note, I had to revert to c089671 of http://github.com/openwrt/openwrt for the instructions to work (returning to a commit where linux-4.9 support was still available for this hardware).

Unfortunately, I can't mount the flash drive to continue the jailbreak.

root@OpenWrt:~# mount /dev/mtdblock3 /mnt
mount: mounting /dev/mtdblock3 on /mnt failed: Invalid argument

root@OpenWrt:~# mount -t jffs2 /dev/mtdblock3 /mnt

...yields the following:

[  223.368780] jffs2: Further such events for this erase block will not be printed                                                                                                            
[  223.389502] jffs2: Old JFFS2 bitmask found at 0x000f5ee0                                                                                                                                   
[  223.394805] jffs2: You cannot use older JFFS2 filesystems with newer kernels                                                                                                               
[  223.424386] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100000: 0x4550 instead
[  223.433842] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100004: 0xb87a instead
[  223.443296] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100008: 0x4b5a instead
[  223.452756] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0010000c: 0xd660 instead
[  223.462216] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100010: 0x05c6 instead
[  223.471676] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100014: 0xf425 instead
[  223.481139] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100018: 0xe580 instead
[  223.490599] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0010001c: 0x5fb7 instead
[  223.500066] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100020: 0x8ca6 instead
[  223.509501] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00100024: 0xfca6 instead

tkellen · May 28, 2018, 2:44pm

PS: jailbreak here:

sidepipe · May 28, 2018, 4:58pm

@tkellen Unfortunately Mikrotik use a version of a very old JFFS2 which just doesn't work with the later kernels. You'd have to take the jffs filesystem tree from the Mikrotik kernel and replace the one in the later kernel with it, making the appropriate patches. I did attempt this many moons ago and got it to work, but unfortunately don't have any of that code ( it was a real mess. )

legionnet · June 2, 2018, 8:26am

I succefully write openwrt on RB750GR3
Compiled vmlinux-initramfs.elf for boot in ram

Sometimes switch not work after reboot.

nathana · June 11, 2018, 3:19am

I'm not sure I understand why the strategy for this board thus far has been to replace the stock bootloader with a new one, which to me seems to have several downsides (increased difficulty esp. with hardware/SPI methods, it increases the risk of a brick even when you are doing it w/o a SPI programmer, it makes it difficult or impossible to go back to RouterOS if one wishes, and RouterBOOT is already very full-featured and robust).

The OWRT/LEDE builds for past single-core MIPS RouterBOARDs have never taken this tactic. Does multicore MIPS bootchain differ that much? That there is even the option to build a netbootable LEDE image that RouterBOOT on this model has no trouble booting suggests that U-Boot is not necessary, so what does switching to U-Boot gain users of this board? Just the ability to e.g. use stock OWRT/LEDE partition layout and (thus) sysupgrade and such?

@tkellen @sidepipe I'm not even sure that MikroTik uses JFFS2 on any RouterBOARD, which is likely your problem. I haven't dived into the hEX/750Gr3 yet so I don't know what it uses for r/w data, but in my experience back when I last looked at this years ago, most (older) MIPS-BE architecture models used YAFFS, as did some of the older PPC architecture ones, but then on newer models they started switching to UBIFS. (Also, on ROS 6.x, they switched to storing the actual OS files themselves within multiple concatenated SquashFS images that got loopback-mounted from a file on the read-write partition.) And, yes, you need to make sure that if you care about the contents of the existing RouterOS YAFFS instead of formatting and starting over, that you are using the YAFFS implementation from MikroTik's own kernel source tree, otherwise you risk FS corruption or outright destruction (ask me how I know). Finally, it will also do you no good to have a kernel with their version/fork of YAFFS if your kernel doesn't also compute the offsets of the partitions on flash in the same way that theirs does...there's no partition table as such written to the flash, but rather RouterBOOT and the kernel "agree" on / have the same algorithm for determining partition sizes and start/end offsets. If you try to mount a YAFFS partition from the middle of the partition, you're going to hose the data on it.

In short, it is very unlikely you can "jailbreak" ROS using a stock LEDE image...

sidepipe · June 11, 2018, 8:37am

@nathana Firstly yes, it was YAFFS I was messing with... managed to find bits of the code. However, it's very easy to know what partition scheme MikroTik uses and replicate it in a custom kernel - they supply their patch which contains that data. I've not looked for the gr3, but the info will be there ( or it will be passed by the bootloader, in which case how to read that info will be in there. )

Also, it's very easy to go back to RouterOS. You just have to make sure you save the whole flash before you write the new stuff, and simply write it back again if you want to, which can be done either from a booted system or using an SPI programmer.

Finally the reason I replaced the bootloader was that, unlike other MT devices, I didn't have the time to work out what format the standard bootloader needed the kernel in. It didn't seem to want to boot an elf image that works with other boxes, and when I was looking there had been very little work done in that area. I suspected MT had deliberately changed things to make it difficult to boot custom code, even to the extent they seemed to have disabled console output for the stock bootloader so you couldn't see what was happening.

Of course, it's been a while since I was playing with the gr3 so things could've changed.

nathana · June 11, 2018, 11:01am

@sidepipe Correct, after RouterBOOT finally implemented user-defined partitioning, it passed several parameters on the kernel command-line to communicate the partitioning structure to the kernel, and then they patched the kernel to look for those values. Before that time, AFAIK partition structure was just hard-coded into the kernel patches for a given board.

In RouterBOOT config, you would specify from 1-8 partitions, and then total NAND capacity would be equally divided into that many parts, except there would actually be 2 partitions for every configured one: one where the kernel lived by itself, and one where RouterOS lived. So for "2 partitions" there would be 4 (2 kernel and 2 OS). If partitions > 1, then "parts" would be # of RouterBOOT-configured partitions, "activepart" would be which 'partition' # was being booted, and "boot_part_size" would be the size of the kernel partition for that partition pair in octets (I don't know how RouterBOOT determines this as it is not user-configurable; perhaps it is hard-coded in a given board model's RouterBOOT).

So for example, on most mipsbe boards, boot_part_size is always 4194304 (4MiB), so on a 128MiB NAND with "2" partitions, there would be 4 literal partitions under-the-hood, arranged as:

4MiB (kernel 1)
60MiB (OS 1)
4MiB (kernel 2)
60MiB (OS 2)

All 4 would be the same underlying FS (YAFFS or UBIFS depending on board model). Kernel has to be called 'kernel' on the boot partition, and RouterBOOT knows how to read YAFFS on boards that use YAFFS, and how to read UBIFS on boards that use UBIFS.

Many moons ago, I got all of this to work on old Kamikaze builds. I took a version of the MikroTik kernel patches nearly verbatim and used that as the basis for the kernel in my own builds. With this OWRT frankenkernel, it was possible to dual-boot between RouterOS and OpenWRT on the same device.

Anyway, the main point I was trying to make is that as things stand, @tkellen isn't going to be able to take a stock LEDE image for this board and gain straightforward read-write access to the partitions on the NAND that RouterOS laid down. To your point, it would indeed be relatively easy to come up with a LEDE kernel that understands how to replicate the partition structure communicated to it by RouterBOOT, but nobody's done it yet.

As I recall, there is no difference from RouterBOOT's perspective between an ELF kernel image booted from flash and one booted from the network. You could literally extract a RouterOS kernel from an NPK and netboot the darn thing (though you'd better have an OS partition on flash that matches it, because it's going to try to mount it to finish the boot), and also it's no problem (assuming it is small enough to fit) to take an image intended for netbooting (complete with initramfs) and copy it to the boot partition while naming the file 'kernel'. It'll start. This being the case, what was puzzling me is the fact that clearly someone got working a bootable ELF image for this board, and ironically what it's being used for is wiping out the bootloader that it supports being booted by! Seems at that point like the thing to do would be to make building RouterBOOT-compatible ELF kernels a supported option in LEDE Buildroot.

(I don't know this for a fact, but my suspicion is that when it comes to bootloader console support, it doesn't exist in this particular RouterBOOT merely because the board has no user-exposed RS232 like some models do...RB7xx and RB9xx series boards have never had RS232 ports, while other RB series continue to supply them, even on new models being released in those series present-day. And on those models, RouterBOOT still supports the console. So I'm quite certain this is not an attempt by MT to make it harder to access or manipulate. I'd bet money all RB models without RS232 have a RouterBOOT built without console output.)

I'm hoping to get a hEXr3 myself to play with soon...if I manage to get this working myself I'll be sure to report back...

tkellen · June 11, 2018, 4:17pm

Thanks for all the additional information @nathana / @sidepipe. I'm a fair bit out of my depth here but I'm learning a lot just watching the discussion! I'd be happy to contribute as a tester for any new approaches either of you cook up.

sidepipe · June 18, 2018, 2:13pm

For anyone following this, just a heads up that I've come across some recent builds of the 750Gr3 which have a newer flash chip - a w28q128j. AFAICT this is pretty much identical to the previous one, with the main important difference being the JEDEC chip ID, which is 0xEF7018. This in turn means the current kernel doesn't recognise the flash chip and so won't boot. The fix is simple enough... you can use this patch:

diff -rupN old/drivers/mtd/spi-nor/spi-nor.c new/drivers/mtd/spi-nor/spi-nor.c
--- old/drivers/mtd/spi-nor/spi-nor.c   2018-06-15 10:15:59.840913823 +0100
+++ new/drivers/mtd/spi-nor/spi-nor.c   2018-06-15 10:17:19.212347239 +0100
@@ -1200,6 +1200,11 @@ static const struct flash_info spi_nor_i
                        SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
                        SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
        },
+       {
+               "w25q128j", INFO(0xef7018, 0, 64 * 1024, 256,
+                       SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+                       SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+       },
        { "w25q80", INFO(0xef5014, 0, 64 * 1024,  16, SECT_4K) },
        { "w25q80bl", INFO(0xef4014, 0, 64 * 1024,  16, SECT_4K) },
        { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },

This can be placed in a suitable file in, for example, the target/linux/generic/hack-4.14 directory. As usual, I don't have time to find out how to submit this as a "proper" patch or where/how the patch should even go, so just posting here in the hopes that it will save some people grief and maybe some kind soul can deal with the upstream stuff.

tmomas · June 18, 2018, 3:02pm

-> Pull request via Github or adress this to the devel mailing list.

tmomas · June 25, 2018, 10:30pm

After reading the devicepage and this thread, it's still not clear to me which initramfs image to use:

A) openwrt-ramips-mt7621-rb750gr3-initramfs-kernel.bin (mentioned under Downloads) or
B) self-built vmlinux-initramfs.elf (mentioned under Replacing U-Boot Using LEDE)?

I would like to be sure which one to use before updating the dataentry.

sidepipe · June 26, 2018, 8:59am

From memory, you need an elf image to be able to boot using netboot and the standard RouterBoot loader, whereas the .bin version works with u-boot. So, if you're flashing using a netboot kernel, you need the .elf image.

legionnet · June 27, 2018, 8:37am

tmomas, you need boot vmlinux-initramfs.elf to memory first. It make nand flash writeable.
Then you can write to mtd (nand flash) u-boot, u-boot-env, factory and openwrt-ramips-mt7621-rb750gr3-initramfs-kernel.bin
Compiled vmlinux-initramfs.elf you can download here: https://cloud.mail.ru/public/D2k6/tBmfv6joi

tmomas · June 27, 2018, 9:12am

A post was split to a new topic: RB750GR3 speedtest

jsalatiel · June 28, 2018, 1:15am

@legionnet your image wont boot in my hardware. After about seven minutes, the unit will reboot in routerOS. Maybe it is related to the JEDEC chip id mentioned by @sidepipe.
I will try to compile using his patch and report back here.