How to install to RB750GR3?

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

@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

@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

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 ?

@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

@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

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 ?

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

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

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?

@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

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

That's a bit odd then - it may be your gr3 doesn't have the new chip and some other issue prevented it from working the first time, or it could be that LEDE has already been patched ( though last time I looked it hadn't. )

Are you sure you are on the initramfs image ?

Anyone have a compiled initramfs image with @sidepipe's patch? I tried compiling it myself but wound up with an unbootable image.

So I have been playing with hEXr3 a fair bit recently, and RouterBOOT does behave differently (not altogether unexpected) on this "new architecture" (what MikroTik calls "mmips", which I assume means multiprocessor MIPS) than it does on other RouterBOARDs I've experimented on in the past.

After some false starts, I managed to get a kernel built with MikroTik's own patches + a small OWRT userland (from the Chaos Calmer era, embedded as Initramfs) to boot on the thing. Since this kernel has MT's version of YAFFS, I had no trouble examining -- and even messing with -- the flash contents.

First, the "mmips" version of RouterBOOT doesn't give users the option to custom-partition the flash storage. I imagine this is because they have been slowly moving to smaller SPI (I believe NOR) flash chips in newer models, and RouterOS barely fits in the 16MiB it is equipped with. I guess because "dynamic" partitioning is no longer a thing, not to mention the space constraints of the flash, there is now only one partition that holds everything, not separate kernel and root partitions. In fact, RouterBOOT still passes a boot_part_size parameter to the kernel, but it is equal to the total flash size (16MiB, but expressed in bytes) since there is no longer any distinguishing between "boot_part" and the main partition.

Even so, what the RouterOS mmips kernel does is take boot_part_size, subtract 256KiB from it, and then registers the first 256KiB of NOR as mtd1 and the remaining space as mtd0. Why the heck it does this, I don't know. It calls mtd1 "RouterBootFake". RouterBOOT itself actually lives on a separate (and smaller...on my board it is 512KiB apparently) flash chip from RouterOS, and seems to fit inside a MTD partition (enumerated as mtd2 by the kernel) that is 256KiB in size...I guess they wanted to reserve the right/ability to source flash parts even smaller than 512KiB for RouterBOOT. "RouterBootFake", though, was just filled with zeros when I checked. Maybe they plan to do something with that space later; I dunno.

Where it gets interesting is that there was no file called "kernel" anywhere on the RouterOS partition. Turns out that as of RouterOS 6.x, NPKs are now just SquashFS images with a custom header at the front, but for "routeros-[arch]-6.xx.x.npk" or "system-[arch]-6.xx.x.npk", they also concatenate the kernel image(s) on the end of that file. And when you install RouterOS, that NPK is written to a part of the filesystem, and then also hard-linked to '/bootimage'. RouterBOOT looks for /bootimage in the YAFFS filesystem that starts at offset 0x40000, checks to see if it is a valid NPK, and if so, goes searching for the kernel ELF image in the NPK and boots that. And where it gets REALLY weird is that if you delete all references to the file (even /bootimage as well as the native place where the NPK is stored, /var/pdb/.../image) except for at least one (e.g., 'ln /bootimage /lost+found/qwerty' or some such thing), RouterBOOT will still be able to locate the kernel and boot it. And this still works even if you wipe out RouterBOOT settings/reset to defaults. It's as if once it has found the file on the YAFFS partition, it is "marking" it somehow in a non-visible or non-obvious way within the YAFFS structures itself.

Fortunately, mmips RouterBOOT will still also look for '/kernel' on mtd0 and boot an ELF image sans-NPK-header stored there, too, though a '/bootimage' with valid NPK header takes precedence if both are present.

It also appears as though the RBM11G and RBM33G boards (both based around the very same SoC) are supported by OpenWRT now, and the support assumes that the stock bootloader is present. There really is no reason at this point why the hEXr3/750Gr3 support can't be made to work the same way rather than require a U-Boot flash, and indeed from reading the mailing list, it sounds like things are headed in that direction. In fact, I think that the RBM11G/33G support even lays out the flash partitions the same way that RouterOS' kernel does. So the only thing that would potentially hold one back from using a stock, netbootable OpenWRT kernel with an embedded initramfs userland to monkey around with ("jailbreak") an installed RouterOS is the right set of modifications to YAFFS.

1 Like

I have gotten this working on 18.06 head.

The patches are here (for 18.06 head):
http://swm.pp.se/openwrt-rb750g3/0103-MIPS-ralink-rb750gr3-routerboot-append-dtb.patch
http://swm.pp.se/openwrt-rb750g3/0103-MIPS-ralink-rb750gr3-routerboot-append-dtsi.patch

An image that has support for the latest flash chip and can be tftp booted from Mikrotik bootloader can be found here:

http://swm.pp.se/openwrt-rb750g3/18.head.vmlinux-initramfs.elf

Then I was able to use above instructions on how to update to uboot etc, and then I used uboot to tftp flash the 18.06 squashfs nightly (not 18.06.1, didn't have support for the new flash chip). This required me to solder in a serial console though.

That yielded mtd0-mtd6 and I can then use the installation normally with opkg update/install etc.

There is really no need for all this error-prone, warranty-voiding hassle:

There's a native support patch here:
https://patchwork.ozlabs.org/patch/953454/

It's been reported working here:
https://lists.openwrt.org/pipermail/openwrt-devel/2018-October/014443.html

T.

which branches of openwrt realeses does this patch compatible with? i've tried unsuccessfully to apply the patch to 18.06.1 source code.