Yeah, I just saw the error.
I removed the password, user is the default admin
The files are uploaded. I sent it to reboot with launch via tftp.
Yeah, I saw it.
It fetched your ELF kernel and no telnet again.
Yes, all is right, but for some incredible reason it doesn't work!
My device does not have disk1 or disk3 directory. If I try to delete it, it reappears immediately.
Perhaps my device has some other markup of the file system, I initially brick it and restored through NetInstall.
1 Like
Those disk1 and disk3 are leftover from plugging in a USB drive.
I will try Netinstalling then 7.2rc1.
@adron And boom, after Netinstalling it worked on the first try.
Thanks a lot, now the real fun can start
1 Like
Yeah, me as well.
I have made a ticket to get ROSv7 GPL, MTIK obviously disabled debugfs.
1 Like
I wanted to suggest a fresh Netinstall also at some stage,
But was having a strange issue with the Linux CLI NetInstall package on a hAP AC2 myself
If i specify the key file with the command line, it would not start with the "Sending image" step just show MAC Address a couple of times.
netinstall-7.2rc1$ sudo ./netinstall -r -k XYXY-YXYX.key -a 172.16.2.13 routeros-7.2rc1-arm.npk
Will reset config
Using server IP: 172.16.2.10
Starting PXE server
Waiting for RouterBOARD...
PXE client: XX:XX:XX:XX:XX:XX
PXE client: XX:XX:XX:XX:XX:XX
PXE client: XX:XX:XX:XX:XX:XX
PXE client: XX:XX:XX:XX:XX:XX
Not specifying the key file, it suddenly worked?
netinstall-7.2rc1$ sudo ./netinstall -r -a 172.16.2.13 routeros-7.2rc1-arm.npk
Will reset config
Using server IP: 172.16.2.10
Starting PXE server
Waiting for RouterBOARD...
PXE client: XX:XX:XX:XX:XX:XX
Sending image: arm
Discovered RouterBOARD...
Formatting...
Sending package routeros-7.2rc1-arm.npk ...
Ready for reboot...
Sent reboot command
Not sure if it is the actual issue, but it kept me also wasting a good amount of time.
Haven't actually tried the Linux client, I have a Win10 VM for stuff like this which works.
Now we are hit with the design decision that ARM64 doesn't support appending the DTB to the kernel in any way, it's solely the responsibility of the bootloader to pass it on.
This isn't usually a problem with U-boot and like but is an issue when you are just passing the factory DTB (Especially since it's based on the vendor SDK and then the whole idea that dt-bindings are ABI and must not be broken gets void).
So, a way without adding stuff to the kernel that will never get merged would be to replace the DTB that is shipped with our DTB on sysupgrade
Yes, it makes sense to replace the DTB on sysupgrade with issue you raised
I noticed building your added u-boot support, that CONFIG_OF_EMBED=y is enabled, is this just to debug until a final build is done ? ie CONFIG_OF_SEPARATE=y
Or is this not how it is done?
===================== WARNING ======================
CONFIG_OF_EMBED is enabled. This option should only
be used for debugging purposes. Please use
CONFIG_OF_SEPARATE for boards in mainline.
See doc/README.fdt-control for more info.
====================================================
CFGCHK u-boot.cfg
binwalk u-boot
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 64-bit LSB shared object, version 1 (SYSV)
908668 0xDDD7C Unix path: /usr/lib/gcc-cross/aarch64-linux-gnu/10/include
1461856 0x164E60 Unix path: /usr/lib/gcc-cross/aarch64-linux-gnu/10/include
1659272 0x195188 Intel x86 or x64 microcode, sig 0x00010605, pf_mask 0x6050107, 1A00-01-06, rev 0x50d81b, size 4509467
4444212 0x43D034 Intel x86 or x64 microcode, pf_mask 0x68000100, 2068-01-09, rev 0x10000, size 2048
4444355 0x43D0C3 Intel x86 or x64 microcode, pf_mask 0x67000100, 2067-01-09, rev 0x10000, size 2048
4444413 0x43D0FD Intel x86 or x64 microcode, pf_mask 0x6a000100, 206A-01-09, rev 0x10000, size 2048
4444493 0x43D14D Intel x86 or x64 microcode, pf_mask 0x64000100, 2064-01-09, rev 0x10000, size 2048
4452441 0x43F059 Intel x86 or x64 microcode, pf_mask 0x63000100, 1C51-01-14, rev 0x10000, size 2048
4455920 0x43FDF0 Intel x86 or x64 microcode, pf_mask 0x65000100, 2065-01-17, rev 0x10000, size 2048
4456044 0x43FE6C Intel x86 or x64 microcode, pf_mask 0x66000100, 2066-01-17, rev 0x10000, size 2048
4461821 0x4414FD Intel x86 or x64 microcode, pf_mask 0x30000200, 2050-01-21, rev 0x10000, size 2048
4462539 0x4417CB Intel x86 or x64 microcode, pf_mask 0x63000100, 1B50-01-18, rev 0x10000, size 2048
4463078 0x4419E6 Intel x86 or x64 microcode, pf_mask 0x67000100, 1C50-01-19, rev 0x10000, size 2048
4463166 0x441A3E Intel x86 or x64 microcode, pf_mask 0x63000100, 1C51-01-19, rev 0x10000, size 2048
4463312 0x441AD0 Intel x86 or x64 microcode, pf_mask 0x64000100, 1C52-01-19, rev 0x10000, size 2048
4463394 0x441B22 Intel x86 or x64 microcode, pf_mask 0x65000100, 1C53-01-19, rev 0x10000, size 2048
4463762 0x441C92 Intel x86 or x64 microcode, pf_mask 0xf3000400, 2064-01-22, rev 0x10000, size 2048
4464060 0x441DBC Intel x86 or x64 microcode, pf_mask 0xf3000600, 2063-01-22, rev 0x10000, size 159
4464782 0x44208E Intel x86 or x64 microcode, pf_mask 0xf3000400, 2067-01-23, rev 0x10000, size 291
4466438 0x442706 Intel x86 or x64 microcode, pf_mask 0xf3000400, 1C50-01-25, rev 0x10000, size 2048
4467119 0x4429AF Intel x86 or x64 microcode, pf_mask 0x65000100, 1C51-01-26, rev 0x10000, size 2048
4467484 0x442B1C Intel x86 or x64 microcode, pf_mask 0x66000100, 2053-01-26, rev 0x10000, size 2048
4469302 0x443236 Intel x86 or x64 microcode, pf_mask 0x91000300, 1B50-01-28, rev 0x10000, size 2048
4478380 0x4455AC Intel x86 or x64 microcode, pf_mask 0x50000100, 2064-01-32, rev 0x10000, size 2048
4478528 0x445640 Intel x86 or x64 microcode, pf_mask 0x51000100, 2063-01-32, rev 0x10000, size 2048
4479627 0x445A8B Intel x86 or x64 microcode, pf_mask 0x69000100, 1C69-01-33, rev 0x10000, size 2048
4479748 0x445B04 Intel x86 or x64 microcode, pf_mask 0x66000100, 1C66-01-33, rev 0x10000, size 2048
4480192 0x445CC0 Intel x86 or x64 microcode, pf_mask 0xf3000400, 1C50-01-34, rev 0x10000, size 2048
6152664 0x5DE1D8 mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
6560922 0x641C9A LZMA compressed data, properties: 0x64, dictionary size: 0 bytes, uncompressed size: 65024 bytes
vs CONFIG_OF_SEPARATE=y
binwalk u-boot
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 64-bit LSB shared object, version 1 (SYSV)
658352 0xA0BB0 Flattened device tree, size: 12824 bytes, version: 17
921340 0xE0EFC Unix path: /usr/lib/gcc-cross/aarch64-linux-gnu/10/include
1474203 0x167E9B Unix path: /usr/lib/gcc-cross/aarch64-linux-gnu/10/include
1671619 0x1981C3 Intel x86 or x64 microcode, sig 0x00010605, pf_mask 0x6050107, 1A00-01-06, rev 0x50d81b, size 4509467
2285181 0x22DE7D mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
4456222 0x43FF1E Intel x86 or x64 microcode, pf_mask 0x68000100, 2068-01-09, rev 0x10000, size 2048
4456365 0x43FFAD Intel x86 or x64 microcode, pf_mask 0x67000100, 2067-01-09, rev 0x10000, size 2048
4456423 0x43FFE7 Intel x86 or x64 microcode, pf_mask 0x6a000100, 206A-01-09, rev 0x10000, size 2048
4456503 0x440037 Intel x86 or x64 microcode, pf_mask 0x64000100, 2064-01-09, rev 0x10000, size 2048
4464451 0x441F43 Intel x86 or x64 microcode, pf_mask 0x63000100, 1C51-01-14, rev 0x10000, size 2048
4467930 0x442CDA Intel x86 or x64 microcode, pf_mask 0x65000100, 2065-01-17, rev 0x10000, size 2048
4468054 0x442D56 Intel x86 or x64 microcode, pf_mask 0x66000100, 2066-01-17, rev 0x10000, size 2048
4473831 0x4443E7 Intel x86 or x64 microcode, pf_mask 0x30000200, 2050-01-21, rev 0x10000, size 2048
4474549 0x4446B5 Intel x86 or x64 microcode, pf_mask 0x63000100, 1B50-01-18, rev 0x10000, size 2048
4475088 0x4448D0 Intel x86 or x64 microcode, pf_mask 0x67000100, 1C50-01-19, rev 0x10000, size 2048
4475176 0x444928 Intel x86 or x64 microcode, pf_mask 0x63000100, 1C51-01-19, rev 0x10000, size 2048
4475322 0x4449BA Intel x86 or x64 microcode, pf_mask 0x64000100, 1C52-01-19, rev 0x10000, size 2048
4475404 0x444A0C Intel x86 or x64 microcode, pf_mask 0x65000100, 1C53-01-19, rev 0x10000, size 2048
4475772 0x444B7C Intel x86 or x64 microcode, pf_mask 0xf3000400, 2064-01-22, rev 0x10000, size 2048
4476070 0x444CA6 Intel x86 or x64 microcode, pf_mask 0xf3000600, 2063-01-22, rev 0x10000, size 159
4476792 0x444F78 Intel x86 or x64 microcode, pf_mask 0xf3000400, 2067-01-23, rev 0x10000, size 291
4478448 0x4455F0 Intel x86 or x64 microcode, pf_mask 0xf3000400, 1C50-01-25, rev 0x10000, size 2048
4479129 0x445899 Intel x86 or x64 microcode, pf_mask 0x65000100, 1C51-01-26, rev 0x10000, size 2048
4479494 0x445A06 Intel x86 or x64 microcode, pf_mask 0x66000100, 2053-01-26, rev 0x10000, size 2048
4481312 0x446120 Intel x86 or x64 microcode, pf_mask 0x91000300, 1B50-01-28, rev 0x10000, size 2048
4490390 0x448496 Intel x86 or x64 microcode, pf_mask 0x50000100, 2064-01-32, rev 0x10000, size 2048
4490538 0x44852A Intel x86 or x64 microcode, pf_mask 0x51000100, 2063-01-32, rev 0x10000, size 2048
4491637 0x448975 Intel x86 or x64 microcode, pf_mask 0x69000100, 1C69-01-33, rev 0x10000, size 2048
4491758 0x4489EE Intel x86 or x64 microcode, pf_mask 0x66000100, 1C66-01-33, rev 0x10000, size 2048
4492202 0x448BAA Intel x86 or x64 microcode, pf_mask 0xf3000400, 1C50-01-34, rev 0x10000, size 2048
4780241 0x48F0D1 mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
4780255 0x48F0DF mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
4780389 0x48F165 mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
4780403 0x48F173 mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
6572938 0x644B8A LZMA compressed data, properties: 0x64, dictionary size: 0 bytes, uncompressed size: 67328 bytes
**658352 0xA0BB0 Flattened device tree, size: 12824 bytes, version: 17**
CONFIG_OF_EMBED is intentionally enabled so that U-boot will embed its DTB inside of the ELF image.
Otherwise you would have to append it manually after building.
Ok, understood
Ok, so I managed to dump the COMPHY registers and figure out the SERDES lane config, USB3 is actually on lane 3 instead of and now works in SS mode.
They have configured all of the remaining lanes in PCIe mode, which makes sense as there are 2 M.2 slots unpopulated, one labeled for SSD (So NVME) and one for WLAN cards (For the future WiFi model)
Pushed the updated U-boot.
Still have no clue how to boot an OpenWrt generated kernel without using U-boot as booting manually via it works just fine and honestly, that looks much less painful than adding appended DTB to the kernel.
It could have its own small NAND partition, RouterBoot will boot it instead of the kernel and then U-boot can properly boot OpenWrt with a normal UBI
1 Like
That sounds like a very good way.
It's only good if RouterBoot doesn't require it to be in YAFFS as well.
Also, somebody is gonna need to backport the 88E6393X switch support from newer kernels as OpenWrt is on the old 5.10.
I can't seem to find where is the QCA8081 MDIO connected to, I thought it was to the switch but on its MDIO I cant find anything.
Managed to figure out the I2C GPIO pins (Why FFS MikroTik are you using bitbanged I2C with 2 HW controllers completely unused) for SFP but still have no idea about the status GPIO-s, I see that there is also a switch reset GPIO in the driver but it's all hardcoded internally and there is no debugfs to read it from.
Oh... U-Boot packed in yaffs... So you need a minimal U-Boot in yaffs that's loading an complete U-Boot to load a kernel in ubi...
I would never have guessed that this is such a mess to liberate a simple router 
Or simply get completely rid of RouterBoot using jailbroken ROS as the requirement, but this also requires that we port everything precisely and that is a guessing game at this point as there isn't a GPL dump of ROS v7.
ATF version that they are using looks really old and broken for newer kernels anyway (Its also reports 2GB of RAM)
Sad to see that also european manufacturers are playing the gpl violation game.
Hope you will have enough stamina to puzzle it all together!
They are playing their usuall trick that they take their time so you usually give up
Really sad. But who could be a better alternative?