OpenWrt Forum Archive

Topic: Hacked Support for Mikrotik rb750r2 ( also known as hEX Lite )

The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I don't really have time to do this properly, but I needed OpenWRT on this box so I've managed to do that in a way that isn't at all elegant. It works, but I'm hoping that someone else can do it properly using what I've done as a start. I've not yet tried to make the LEDs work, but it shouldn't be too hard.

The major problem with this hack is the yaffs support. Essentially, the 750r2 has a nor flash, which causes the standard kernel yaffs to crash. To get around this, I've modified Mikrotik's version of yaffs to compile with the kernel in Barrier Breaker - this obviously causes all sorts of issues and probably breaks other devices. Really, someone needs to mod the kernel's yaffs to work with the rb750r2.

Since the flash is only 16M, I've chosen to make the kernel partition 2M, which may be too small for some configs - but should be ok. Obviously it's wasy enough to change this.

My files are here - the patch is against Barrier Breaker and the 3.10.49 kernel. You will need to:

rm target/linux/generic/patches-3.10/50[^0]*yaffs*
rm target/linux/generic/files/fs/yaffs2/*
untar the Mikrotik-Modded-Yaffs.tar.bz2 file in the target/linux/generic/files/fs/yaffs2/ directory
copy the file 826-MIPS-ath79-add-rb750r2-and-rb2011-rm-support-openwrt.patch to target/linux/ar71xx/patches-3.10/

You'll also need to make the simple changes mentioned in the QCA9533 patch mentioned here

You have to make with "V=s" for some reason ( asks about "new" YAFFS config options. ) Not sure why - I guess that there's a file somewhere that's out of sync.

(Last edited by sidepipe on 17 Jun 2015, 18:32)

Pretty good job man.

So, I thought that I was going completely mad with this. I suddenly couldn't get the box to boot from flash again ( netboots fine. ) What I've found is that:

1) It won't cold boot from flash
2) It will only warm boot from flash if it was netbooted with the same image that is on the flash ( which sort of also implies 1) anyway. )

So, if you netboot, write the netboot initramfs image to flash, remove the Ethernet cable, reboot from the console, the device will boot. It will then continue to boot every time you reboot from the console, but not if you power cycle. Furthermore, I added a "hello.txt" file to /root of the initramfs image, but other than that it was ( should be ) identical. Netbooting from this modified image and rebooting from the console means that the flash image no longer boots. Going back to netboot from the original image means that a soft reboot works again ( or flashing the new image means that it can be netbooted and rebooted from that one. )

This is driving me nuts. Clearly the boot loader is setting something up with the netboot that isn't being set up when cold booting from flash... but is this likely to be something that the kernel isn't doing, or some sort of boot loader bug? Anyone got any ideas?

For anyone who is interested in this, I found an alternative boot loader for the QCA9533  here. This can be used to replace the standard boot loader in the hEX lite, and this one DOES work. Its web interface is in Chinese, and it's closed source, so it would be nice if someone could make U-Boot work with this chip. The other issue is that now the MT750r2 uses a completely different boot loader and so there are various implications such as the need to save the MAC address and to use a different image format.

I'm working on making all of this work but it won't be pretty....

Update here

The discussion might have continued from here.