Couldn't it be some kind of transparent hardware ECC which some of the later raw NAND flashes support?
Anyway, as for the PHY MDIO I should be able to sniff that one. My device should get delivered tomorrow. Let's see...
I doubt it, the NAND controller is quite an old one and the NAND used is just a standard ONFI which requires 4 ECC bits per 512 bytes of data
NAND:
Okay, so basically just a crappy driver omitting it on dumps.
Doubt that's the case, more likely they are just populating OOB with 0xFF
Otherwise there will be complaints from every customer using the SDK as ECC is kind of really important.
@sumo Has your board maybe arrived?
I didn't even touch RB5009 today
Yep, just firing up the soldering station so I can listen to the PHYs MDIO.
BTW: What's the most convenient way to currently boot mainline on it?
The only way so far is using U-boot, boot the jailbreaked ROS and replace the kernel file with u-boot ELF
and it will autoboot that, or set it to always boot from ethernet.
Then you can use USB or USB to ethernet to load the kernel and FDT and use booti as the built-in switch is being weird in u-boot to say the least.
2 Likes
Well friends, I have bad news - when you put the yaffs2 NOR kernel image on the NOR and reconfiguring the tag 3 parameter in the soft-config to value 7, nothing happens! At startup, RouterBoot simply corrects this value from 7 to 1. That is, it does not have support for loading the kernel from a NOR flash drive! So we have no choice but to completely replace the RouterBoot with our U-Boot!
There is also another interesting observation - when you start U-Boot from the NAND, its network subsystem always works correctly. But if the U-Boot is loaded via the network, then when it starts, the network subsystem will almost certainly be broken!
Yeah, I guess just like on the former ath79 devices with the YAFFS2 bad block issue also here it really would be the best to just ditch any of their stupidity completely. It's a bummer that such half way decent hardware is delivered with such crappy software by default. Luckily, in the RB5009 case, good mainline U-Boot support should really not be too big of a deal.
Can you please describe the whole process of creating an ATF image. I tried to repeat your path using this article, and the image is builded and even uploaded via UART(xmodem), but further on in the console there is silence. Thanks!
Of course, it was on my TODO list as you can't just use a random ATF as its embeds the DRAM training code and that will obviously fail then, especially since MikroTik is using 16 bit DRAM to save money.
You can find the working ATF for RB5009 here:
U-boot is here:
When it comes to building, you gotta build the U-boot first as ATF embeds that and runs it after itself.
For ATF you also need (master branch):
and (binaries-marvell-armada-SDK10.0.1.0 branch)
Then in ATF root you just point to their paths (Relative and absolute work fine):
make CROSS_COMPILE=~/Building/toolchains/armada7040-2021.08.1/output/host/usr/bin/aarch64-linux- PLAT=a70x0_rb5009 BL33=../u-boot/u-boot.bin SCP_BL2=../binaries-marvell/mrvl_scp_bl2.img MV_DDR_PATH=../mv-ddr-marvell/ mrvl_flash
That is what I use for building.
@adron Thanks for the writeup on the RouterBoot state, it's interesting to see that RouterBoot does some init to the switch if booting from flash.
I just hope that its not toggling a magic GPIO but just doing register read/writes, those we can kind of reverse engineer as its likely nothing complicated.
2 Likes
And ... it works. Now U-Boot is launched through the ATF flooded through the UART. Thank you very much!
And as far as I understand - this ATF U-Boot does not depend on the contents of the NOR flash drive? That is, even if I kill RouterBoot with my experiments, I can always use ATF U-Boot through UART?
No, it's a complete ATF+bootloader bundle in the end.
You don't want to try and use RouterBoot to boot it again as ATF will most likely crap out but you can replace the RouterBoot + ATF that comes by default.
The good thing about Marvell SoC-s is that SoC BootRom has UART (xmodem) based recovery so you cant really brick it.
Yes, that's exactly what I wanted to know. Great, because I'm going to start experimenting with replacing RouterBoot on a NOR flash!
It should just work (TM).
The one thing that we gotta figure out, is where would be a safe place to put the U-boot env?
I was thinking of the last 128k or so on the NOR
Cause, currently its nowhere(Please dont try to use saveenv) and that not really usefull.
Yes, the problem with not loading ATF turned out to be in the wrong type of RAM (as you wrote). For the purity of the experiment, I changed only the dram_port.c file in my sources and it all worked! Thanks again.
Yes, when starting U-Boot via UART (SoC BootRom) or when booting through RouterBoot NetBoot - the network does not work! But when you start U-Booth from NAND - it works.
I think that all the magic is in the initialization of 8081 phy. Without it, even the link does not up!
Yeah, there is some magic, but I dont think its the PHY, its the switch.
Cause if you boot the 5.15 OpenWrt from a network booted U-boot then the switch and the 8081 will work fine as the DSA driver will init the switch.
But no ports will work in U-boot, like none of them will even linkup
It is clear, well, it means 8081 is exactly connected to the switch GPIO(MDIO). If 8081 was on SoC GPIO, then DSA would not be able to initialize it.
No, DSA doesn't touch the 8081 at all, it has no clue it's there.
It only touches the switch but the 8081 will work fine by default as it's a standard PHY and in-band signaling is used.
@sumo Is there a chance you can record/sniff the MDIO commands that RouterBoot does?
Cause its kind of crazy that it only configures port 9 aka the 2.5G PoE port
Hmm, I made a dump of port 0 and port 9 registers when working and when not working.
The only thing that differs is the debug counters register at 0x1f.
Wait, it looks like this thing has a I2C controller as well as it supports using EEPROM for config.
2 Likes