How to install to RB750GR3?

#1

Initial conditions: There is a new router Microtik RB750GR3
I have the following files:
Lede-ramips-mt7621-rb750gr3-initramfs-kernel.bin 3.4M &&
Lede-ramips-mt7621-rb750gr3-squashfs-sysupgrade.bin 3.5M.

There is no file with the elf extension. Therefore, I can not perform the firmware by analogy with the RB951G device (by uploading the initramfs.elf via the tftp protocol).

There is an SPI programmer. It is unclear what software and what file and on what offset to program the flash manually.
Please help! Thank you in advance!

0 Likes

#2

Aren't the instructions on the OpenWrt wiki of any help? Or did you already go through those?

I'm not familiar with running LEDE from a ramdisk, so I can't comment on the extension thing.

0 Likes

#3

https://lede-project.org/toh/hwdata/mikrotik/mikrotik_rb750gr3
https://lede-project.org/docs/guide-quick-start/standardflashinginstructions

0 Likes

#4

Quoting from the message used when the source for this unit was committed to the LEDE Source Repository:

The MikroTik hEX v3 (RB750Gr3) is a MT7621AT board which is similar to most MT7621 reference designs, it can be easily supported by this patch; however, the stock RouterBOOT bootloader has to be replaced by a MT7621 SDK U-Boot such as https://github.com/ndoo/RB750Gr3-U-Boot - U-Boot configured for the RB750Gr3 (16MiB SPI flash, 256MiB DDR3 RAM at 1200MHz).

RouterBOOT, the stock bootloader, does not initialize the UART and boots silently, making it preferable to replace it with a MT7621 SDK U-Boot with UART (57600 8N1) that supports HTTP, TFTP or serial upload of sysupgrade firmware and U-Boot.

Furthermore, RouterOS, the stock firmware, is contained in a proprietary modification of SquashFS without GPL sources; UART is also disabled in stock firmware.

The combination of LEDE firmware generated by this PR and MT7621 SDK U-Boot expects the printed MAC address to reside at offset 0xe000 of the factory partition (absolute offset is 0x4e000); this is similar to the factory MAC address offset for several other MT7621 devices.

A 16MiB flash dump suitable for use with flashrom will be provided if/once this patch is accepted and binaries are built by LEDE buildbot. Alternatively, writing the U-Boot to the SPI flash starting at 0x0 offset and booting the board with serial console attached will allow TFTP, HTTP or serial upload of sysupgrade firmware.

0 Likes

#5

Link above to U-Boot is incorrect. This appears to be the correct U-Boot source for use with the LEDE firmware for the device: https://github.com/ndoo/skwb8_uboot

0 Likes

#6

There are 2 -files: mt7621_stage_sram.bin && mt7621_stage_L2.bin Which one I'm must flash
at 0x0 offset ?
Should I combine Lede source code and https://github.com/ndoo/skwb8_uboo together?
And compile IT ?

0 Likes

#7

The instructions for the RB75gr3 router are not detailed enough.
There remains some freedom of interpretation. Unfortunately, you need to flash the chip with an external hard-core SPI programmer.
At the same time, until the end it is not clear what file to fill in the flash mt7621_stage_sram.bin && mt7621_stage_L2.bin ?

0 Likes

#8

how to build iboot.bin ? Where I can read manual ?

0 Likes

#9

The binary required by the SPI programmer can be constructed by:

  1. u-boot(192KiB)
  2. u-boot-env(64KiB)
  3. factory(64KiB)
  4. kernel(lede-ramips-mt7621-rb750gr3-squashfs-sysupgrade.bin)

Here is the u-boot with a pre-built binary:

u-boot-env can be constructed by:

head -c 64KiB /dev/zero | tr '\000' '\377' > u-boot-env.bin

factory can be constructed as u-boot-env, however, the MAC address is required at 0xe000:

hexdump factory.bin

should gives

0000000 ffff ffff ffff ffff ffff ffff ffff ffff

000e000 3b6c bd6b 843a ffff ffff ffff ffff ffff
000e010 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000

where 6C:3B:6B:BD:3A:85 is the MAC address on label.

2 Likes

#10

Here is an example:
http://45.77.22.46/flash.bin
The link won't last for long and use at your own risk.
The SHA1 checksum should be: 150f0a7c7a37f0e468e5ffa9505373cb25499cec

1 Like

#11

Now I see the right way !!! Thanks very much !!! I will try !

0 Likes

#12

Thank you all very much! Without you, I would have a very long time to figure out how to install the system on my router. Now I can safely study the LEDE on the working device! Special thanks to buaawjw ! Everything OK, hurray!

0 Likes

#13

@buaawjw Thanks for your pointers!

Would you mind sharing how you know these things, and where I could learn them myself?

  1. I understand the u-boot.bin file which is compiled.
  2. u-boot-env, this must be the u-boot environment, which here is set to be empty?
  3. Factory, why have this if it's empty?
  4. You write this is the kernel, but then why use squashfs-sysupgrade.bin instead of the initramfs-kernel.bin?

Thanks in advance!

Edit: The layout seems to be based on/similar to this, which seems to be the origin of the uboot for this board (with a different config only): https://wiki.openwrt.org/toh/samknows/sk-wb8

0 Likes

#14

I've managed to create a netboot image that can be booted from the stock boot loader ( and hence used to flash one of these without a hardware programmer. ) I've added some information to the OpenWRT Wiki page in case anyone's interested.

2 Likes

#15

Why not make PR to merge it into official LEDE?

0 Likes

#16

Hey man. You are king. Thank you for update and for your hard work

0 Likes

#17

I updated the router's wiki page for detailed SPI flashing instructions.

However, that might now be unecessary since flashing the router via netbooting LEDE is arguably easier (patching the kernel vs SPI flashing the flash chip).

0 Likes

#18

Does anyone have the layout of the SPI flash programming connector present on this device?

I have managed to brick my device - I did manage to get the method by sidepipe to boot into RAM based Lede and I have followed the instructions about flashing the U-Boot, config and factory and firmware, but the device seems dead after that. I did get the pre-built U-Boot .bin from the Git repository mentioned in this thread. As far as I can tell, U-Boot is not working, as there is no activity on the serial port.

I have got soldered the missing header to the SPI connector, but I am not sure which pin is which (as the SOIC8 has only 8 pins and the header has 10).

Has anyone else tried to follow the sidepipe method and what U-Boot have you been using?

0 Likes

#19

I'm do't use SPI connector on board. I unsolder chip and connect SPI programmer directly to chip.

0 Likes

#20

Hi guys,

I'm trying to flash Lede firmware on my RB750Gr3 board for days now following instructions detailled here :
https://wiki.openwrt.org/inbox/mikrotik/mikrotik_rb750gr3 ...without any success until now :

  • I first tried to flash the firmware using flashrom and my Raspberry Pi 3 board, but I fried the RPI with a short-circuit (the Mikrotik board is much more resistant than the RPI :sneezing_face:)
  • then I purchased a Bus Pirate board, and I soldered HE-14 pins on the Mikrotik SPI header to avoid another short-circuit... I also made a nice ribbon cable to connect the cards, with a jumper to enable or disable 3.3V from the Bus Pirate

So I wonder my wiring is now pretty safe and things should run smoothly... but it doesn't !

flashrun is running now for more than 10 hours and it is still not completed. Even worse, there is a lot of error messages on the logs :

flashrom v0.9.9-r1954 on Linux 4.13.0-1-amd64 (x86_64)
flashrom was built with libpci 3.5.2, GCC 6.3.0 20170221, little endian
Command line (8 args): /usr/sbin/flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -o flashrom.log -V -f -w test.bin
Calibrating delay loop... OS timer resolution is 1 usecs, 3677M loops per second, 10 myus = 10 us, 100 myus = 106 us, 1000 myus = 1070 us, 10000 myus = 10184 us, 4 myus = 4 us, OK.
Initializing buspirate_spi programmer
Detected Bus Pirate hardware v3.5
Detected Bus Pirate firmware 6.2 ("v6.2-beta1")
Using SPI command set v2.
SPI speed is 8MHz
Raw bitbang mode version 1
Raw SPI mode version 1
The following protocols are supported: SPI.
Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4018
...
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xef, id2 0x17
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
Block protection is disabled.
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0x1fc
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Trying erase function 1... 0x000000-0x007fff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00007fff: 0x1fc
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Trying erase function 2... 0x000000-0x00ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0x1fc
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Trying erase function 3... 0x000000-0xffffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00ffffff: 0x1fc
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Trying erase function 4... 0x000000-0xffffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00ffffff: 0x1fc
ERASE FAILED!
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents...

I tried both powering options (I mean powering through the Mikrotik power unit, or powering through Bus Pirate's 3.3V Vcc) The logs I copied here are obtained with SPI chip powered by Bus Pirate, but they were exactly the same powered by Mikrotik power.

Of course the device is now bricked, so if I can't find a way to fix this, the device can go to the trash (where my dead RPI is waiting for it :disappointed_relieved:)

As you probably already guessed, i'm very newbie with hardware hacking and some help would be really appreciated as I really don't know what to do now... unless unsolder the Winbond chip, but I'm not equiped to remove this chip with no damage for the board (and the chip itself !)

Thanks

0 Likes