How to install to RB750GR3?

Installing and Using OpenWrt
36

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.

1 Like
37

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

1 Like
38

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.

39

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.

1 Like
40

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

1 Like
41

A post was split to a new topic: RB750GR3 speedtest

42

@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.

1 Like
43

It worked after patching JEDEC =)
Now i am gonna read carefully how to flash it.

44

@jsalatiel, please upload your version .elf firmware
You can simple flash it:

mtd write u-boot.bin /dev/mtd0
mtd write u-boot-env.bin /dev/mtd1
mtd write factory.bin /dev/mtd2
mtd write openwrt-ramips-mt7621-rb750gr3-initramfs-kernel.bin /dev/mtd3
1 Like
45

@legionnet don't i need to hexedit my mac address on factory.bin first ? i dont wanna brick the device because i dont have a spi programmer to flash.

The image is now here: https://nofile.io/f/CdSRRKUz2F0/vmlinux-initramfs.elf

46

I have a question:
According to openwrt's page, i have to hexedit my mac in position (0x)e000 and i can veryfy using hexdump.
"After inserting the mac address it should look like this (With an example mac address of AA:BB:CC:DD:EE:FF):
$ hexdump factory.bin
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
000e000 aabb ccdd eeff ffff ffff ffff ffff ffff
000e010 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000
"

The problem is that after editing my hexdump is returning the macaddress "reversed" like this:
$ hexdump factory.bin
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
000e000 bbaa ddcc ffee ffff ffff ffff ffff ffff
000e010 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000

Is this normal ?

47

@jsalatiel, yes you need to hexedit factory.bin first and I write a reversed mac, but when I check by hexdump it show me 000e000 aabb ccdd eeff ffff ffff ffff ffff ffff
I advise you to solder the UART
it can help a lot If U-boot worked.
And I have a trouble with switch after several reboot it doesn`t work until the next reboot.
But then the problem passed by itself. I even wrote a script to check the freezed switch but it was not needed now.
UART helped diagnose this problem.

1 Like
48

@jsalatiel - The reason for the reversing of bytes is you'll be looking it on an x86 platform, which uses a stupid scheme called little endian, which is where bytes are stored in reverse order in memory. So, 0xabcd would be stored as 0xcd in the lowest memory location followed by 0xab in the next. It probably made sense to someone in the very early days. Networks, and sensible processors, store the bytes in the more logical order, so things that need to be compatible across systems store things in that order. The bytes really aren't reversed, it's just how hexdump represents them because it's how your cpu would "see" them.

If you pass -C to hexdump it will show a byte at a time, and so show the correct order.

1 Like
49

Thanks for the info @sidepipe. So if @legionnet wrote a reversed mac, actually he's getting a wrong mac in the device, right?
Well, one last question:
Which file should i write on /dev/mtd3?
openwrt-ramips-mt7621-rb750gr3-initramfs-kernel.bin OR lede-17.01.2-ramips-mt7621-rb750gr3-squashfs-sysupgrade.bin ?

50

@jsalatiel - yes, if the MAC shows correctly using default hexdump mode on a little endian system ( and the 750gr3 uses a mips processor in little endian mode from memory ) then it is in fact reversed. You can easily check the MAC from the command line using ip link show dev eth0

The file to write to flash is the squashfs one. The initramfs is for netbooting - I believe it will work if written to flash, but everything runs from RAM rather than flash.

1 Like
51 
BusyBox v1.25.1 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01.2, r3435-65eec8bd5f)
    \________\/    -----------------------------------------------------------

=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@LEDE:~#

It worked. Thank you guys!
I think it would be nice if someone with write permissions on https://openwrt.org/toh/mikrotik/mikrotik_rb750gr3 updates there with some info from the thread.

1 Like
52

All registered users have write permission on this page, so why not do it yourself?

53

I didn't know that. Sure i can try!

@sidepipe there is one thing that i am not understanding , if i needed to patch my build of the .elf netboot image with the JEDEC chip ID to be able to netboot, how can LEDE 17.01.2 default image (which probably do not have that patch) boot successfully after flashing?

54

@jsalatiel That's a good question, and without looking further I wouldn't know the answer. If you flashed the initramfs image rather than the squashfs image, it would boot fine, because everything runs from RAM and doesn't need access to the flash ( other than booting, which is handled by u-boot. )

Does cat /proc/mtd show the mtd partitions? Also, does dmesg show the flash chip being recognised?

1 Like
55

I flashed the squashfs image.

cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 00165cd5 00010000 "kernel"
mtd5: 00e4a32b 00010000 "rootfs"
mtd6: 00c20000 00010000 "rootfs_data"

dmesg:

[    0.770000] MediaTek Nand driver init, version v2.1 Fix AHB virt2phys error
[    0.780000] spi-mt7621 1e000b00.spi: sys_freq: 50000000
[    0.800000] m25p80 spi32766.0: using chunked io (size=32)
[    0.810000] m25p80 spi32766.0: w25q128 (16384 Kbytes)
[    0.820000] 4 ofpart partitions found on MTD device spi32766.0
[    0.830000] Creating 4 MTD partitions on "spi32766.0":
[    0.840000] 0x000000000000-0x000000030000 : "u-boot"
[    0.850000] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.860000] 0x000000040000-0x000000050000 : "factory"
[    0.870000] 0x000000050000-0x000001000000 : "firmware"
[    0.920000] 2 uimage-fw partitions found on MTD device firmware
[    0.930000] 0x000000050000-0x0000001b5cd5 : "kernel"
[    0.940000] 0x0000001b5cd5-0x000001000000 : "rootfs"
[    0.950000] mtd: device 5 (rootfs) set to be root filesystem
[    0.960000] 1 squashfs-split partitions found on MTD device rootfs
[    0.970000] 0x0000003e0000-0x000001000000 : "rootfs_data"
1 Like