U-Boot for XGS12xx switches (and others based on realtek rtl930x)

Hey all,

I've managed (painfully) to compile the SDK's U-Boot for our realtek rtl93xx. To make life easier for other devs, I've wrapped it all up in a docker container, so the build environment should be identical to all. The repo is over on gitlab. Feel free to poke around and try it out.

Anyway, more interestingly, I've actually changed it a bit too. For example, ZyXEL made some weird partitioning, and are writing some bytes in certain cases into strange area's of flash. Even worse, is they also have a boot-check to some of these bytes.

I've taken a hatched, and ripped that quirkiness all out (see the history in the above link). The build now produces a more 'generic' U-Boot, with only 3 partitions (from U-Boot's point of view anyway). All the dual-image stuff is gone, and only u-boot, u-boot-env and firmware remain, giving us a big fat 15Megs of storage. The self-test can be still run; and it is still destructive (flash-write test, maybe someday I'll fix it to read the data, write some thing, test it, write back the original data, test that, so it's a slower, but non-destructive write test ... 'hey McFly, anybody home?'

I've tagged and spun a release (per gitlab manually, not via CI yet) which can be downloaded.

Some words of wisdom and warning. Have backups of your flash!
Really, backup your flash. If anything, the output of printenv or fw_env. While the environment partition isn't touched in an upgrade, better have a backup of this partition regardless.

Secondly, I've only tested this on my switch, an XGS1010-12. I would love however to see if this works on a real XGS1210-12 and more importantly an XGS1250-12. Those are the main targets. I don't think the 10G and SFP ports work, but I've heard they don't work in U-Boot anyway ... For me, this is a non-issue, but thoughts.

Anything else is fair game however, but realize, that the memory timings and flash settings are specific to this board/build, so I would expect only boards with the same DDR RAM and SPI NOR Flash chips to work, as well as the network PHY if ethernet is important :stuck_out_tongue:

If anything fails to work; be sure to be open to using a clip and burn the factory bootloader back :frowning:

Some "screenshots" :slight_smile:

U-Boot 2011.12.001-owrt (Aug 12 2022 - 14:40:05)

Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
DRAM:  128 MB
SPI-F: MXIC/C22018/MMIO16-1/ModeC 1x16 MB (plr_flash_info @ 83f5a148)
Loading 65536B env. variables from offset 0xe0000
Net:   Net Initialization Skipped
No ethernet found.
Hit Esc key to stop autoboot:  0 
RTL9300# # flshow
=============== FLASH Partition Layout ===============
Index  Name       Size       Address
 0     LOADER     0xe0000    0xb4000000-0xb40dffff
 1     BDINFO     0x10000    0xb40e0000-0xb40effff
 2     RUNTIME1   0xd00000   0xb40f0000-0xb4deffff

Just a note to drop; the XGS1010-12 doens't have any data provisioned, after all, it is an unmanaged switch. The XGS1210-12 and XGS1250-12 however, have some data provisioned, that U-Boot or the kernel don't seem to know about, such as mac_start and mac_end. The solution ultimately will be simple, either keep that second partition JUST for that piece of data, or 'migrate' the data (setenv) to the primary environment partition in that case are the most logical actions.

Having a second parittion just for provisioned data, and RO protected is great and preferred, but it also wastes some space, so might as well consider keeping the data in the primary environment. Downside however is, an env-wipe would reset this as well, so on second thought ... having a provisioning partition is not so bad after-all, assuming we can properly write-protect it.

1 Like