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

For Developers
1

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
======================================================
7 Likes
2

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
3

Are you also looking to migrate some of this into a commit against the current mainline Uboot?
It would be great to be able to piggyback on some of this for the Hasivo switch I've got (rtl930x also).

4

'not a chance' :stuck_out_tongue:

In the sense, it'll take years of work to do; doable, but a lot of effort.

The problem is, realtek doesn't patch u-boot, realtek calls their sdk from u-boot, by adding 1 or 2 functions to u-boot, and hacking the stuff that doesn't suit them.

And until we have the actual linux bits in mainline, this will have to wait until then ... (even though I would love to hack around and make it happen, its just a lot of work :p)

5

Which big ticket items are left from your perspective?

I figured with UART / SPI / NET (MAC, SERDES, MDIO) support that was pretty much Uboot done.
So the RTL838x / RTL839x were close to this already.

The RTL930x / RTL931x series appear to have a bit more work to do on the SPI / NET side of things.

6

Not at all, all those drivers/interfaces need to be re-written. Upstream would never accept these drivers in their current hacked together form.

e.g. to initialize gpio, uboot basically is hacked to do 'sdk_init(); sdk_gpio_init().

Yes, functionally, we have all these things, and we also have the code for it. But that's pretty much all there is.

8

8 posts were split to a new topic: Support for Horaco ZX-SWTG3424S switches

14

You are correct on the Mestechs. Mine is like the 9424 (L3, 9301+8218D) in the body of 8424 (24GE) :smiley:
leds - array & number is 1:1
case, sn label on the top lower left corner - 1:1
dumb text on the front panel - almost 1:1 managed ethernet switch <-> gigabit managed switch
online demo - almost 1:1 blue backgnd

reset, console & USB is between the GE & SFP ports.

17

@ olliver & @ bevanweiss
pls check this, and let me know.
Shall I edit and delete all the comments here those are not related to the U-boot topic ?

18

nah, let me see if I can split it into its own thread :slight_smile:

btw, I saw you routed out the USB port; and it leads to a max232 ic? the 'go to' serial -> UART converter chip? :slight_smile: looks like they are using a USb port for their serial console. Nice to offer a choice, but WTF :stuck_out_tongue: so confusing!

If you really wanted to though; you could probably re-solder the connector to the real USB pins!! :slight_smile:
But are you 100% sure? they are running the RJ45 serial and USB serial in parallel? After R101 and R102 I mean ...
The upside, I did find just this in the BSP: https://gitlab.com/olliver/openwrt/realtek_sdk/-/blob/openwrt-dev/sdk/system/linux/linux-3.18.24.x/arch/mips/realtek/boards/rtlSwitch-universal-bsp/model/34kc/bsp/usb.c but a bit too many OTG references to my liking; but who knows, maybe it IS a usb otg port; but then, where's the USB ID pin that sets direction ...
nvm, found this based on your log output; https://gitlab.com/olliver/openwrt/realtek_sdk/-/blob/openwrt-dev/sdk/system/linux/linux-3.18.24.x/drivers/usb/host/ehci-rtk_gen1.c which nicely prints the memory address and correct irq :slight_smile:

Also, on the bottom, I can't make out U25 but it looks very much like a RTL8231. So probably for the GPIO's there. Interesting, using both RTL8231 for leds and for GPIO. The soc does support 2 differently connected RTL8281's. ... The leds are daisy chained though for sure.

edit: I traced them out; and no, it really looks like a genuine USB port; lucky you :slight_smile: the controller is probed as you can see int he logs; maybe DTS magic isn't even needed (i don't think USB does generally).

image
image1069×1139 110 KB

i've attached the full pic to the wiki; the gimp file is like 80 megs; so not sharing that (uncompressed probably, but geez)

So studying your photo's, it looks very much like U13 is used as a clock splitter/buffer. e.g. 1 i2c in; 4 out. Obvious also from the traces, you see them going under the SFP cages, first 4, then 3, then 2 and then just the 1; so it drops a line after each SFP. Also my switch uses the same trick to share the SFP line.

The SDA line will be a little harder to trace, but not that much, also unless they are doing the same mistake fullriver did, and offset the I2C pins by 1, thus having to rely on bitanging, we kinda know the obvious pins that they are using. It is unlikely they are using anything other then sda0 - sda3, but who knows.

As an excersize, it's probably a very good idea to trace out the rtl8231 gpio's. We know the pinout, so seeing which SFP pins they use makes life a little easier later.

It seems also that they are using the rtl8231 for the reset pin, though I'm not sure, can't see clear enough (it helps to play with the opacity setting and trace out the line, but I'm on my laptop and don't have the xcf right now :p) anyway, by dumping the register address of the GPIO block in u-boot; and pressing/releasing the button while dumping, it is easy to figure out. the same trick works for the sfp cages to find the 'presence' pin (if it is not routed to the rtl8231). We can dump the rtl8231 (ext-gpio) register for that though.

Leds I have no idea about yet, I defined them as my switch; but first question is; how many colors do each have? e.g. are they different for 10/100/1000/10000? My guess is, it's the same as everywhere, a green/amber led, 10/100 amber, 1000 green; 1000 amber, 10000 green on the SFP ports.

Anyway, with your info, I've created the dts files with some holes where we need to add your stuff :slight_smile: so feel free to try (I haven't compile-tested it yet) and see how far you get!

19

ok, so I think I was able to backup the flash.

dd all mtd partitions, and then concatenate them on the host (cat mtd*.bin > mtd.bin)

become 16.8 MB (16777216 bytes). Is this ok for a 16MB flash?

1 Like
20

Thank you for making this so easy to build using Docker!
I have created what I think should be a working file for my TEG-S750 but there are obviously no guarantees that it works given the bcm8489x PHYs. Unsurprisingly, I haven't had great success... I'm not 100% sure on which phy mode I should choose, but am thinking RTK_MII_USXGMII_10GSXGMII is probably the right one.

I was wondering if on a known-working device, such as the Zyxel xgs1250, ping is expected to work? Say when U-Boot comes up and I issue rtk network on followed by ping 192.168.1.111 would that work? And if so, would it work on any switch port?

21

I don't think you need to do a custom build, but who knows.

I have to do rtk network on and then set up some env variables. But with those in place, ping does work, on any (supported :p) port. E.g. for the XGS1250 any behind one of those octal PHY's.

1 Like
22

Which env vars specifically?
The stock u-boot only had a handful, none of which stand out to me:

RTL9300# # printenv
baudrate=115200
boardmodel=RTL9303_2x84892_1x84891
bootcmd=boota
bootdelay=1
ethact=rtl9300#0
ethaddr=78:2D:7E:13:EE:BC
ipaddr=1.1.10.100
ledModeInitSkip=0
serverip=1.1.10.111
stderr=serial
stdin=serial
stdout=serial
stop_ip=1

Environment size: 254/65532 bytes

I've kept ethact=rtl9300#0 and ping uses it but can't reach anything.

23

since your not using dhcp, you need to self-assign. You said you tried to ping 192.168.x.x, but your ipaddr is setup to 1.1.10.100 (weird one that). ipaddr=192.168.1.1 is probably what you want, and ipaddr=192.168.1.10 or something for the server (or vice versa or whatever) :slight_smile:

24

Oh sorry, that's just the old env from stock U-Boot. With your U-Boot build I inherited the 192.168.1.1 IP, so if the hardware was willing that should work... I'm thinking it's probably the unsupported bcm8489x PHY.

I'll keep poking at that from the kernel end in the other thread. Worst case scenario I've had a look at the stock kernel module in Ghidra but I'd really like not to have to go there :slight_smile:

25

I am not able to put this R-9300 MG switch on network can anyone help?