Switch Upgrade XGS1010-12 nach XGS1210-12

[Franz (Gast)]

Hallo

Ich habe die beiden im Titel angegebenen Switches:
XGS1010-12 und
XGS1210-12.
Leztere ist managebar, der erst nicht.
Bei beiden ist die Hardware identisch und der Debug UART ist von aussen 
erreichbar.

Somit ist meine Neugierde geweckt, ob man den XGS1010-12 auf einen 
XGS1210-12 upgraden kann.

Auf beiden System ist jeweils ein UBoot und ein Linux drauf. Beides ist 
jedoch nicht identisch. So fehlt dem 1010-12er im uboot die 
Ethernet-Unterstützung. bootp/tftpboot geht z.B. nicht, obwohl der 
Befehl angezeigt wird:

U-Boot 2011.12.(TRUNK_CURRENT)-svn99721 (Oct 24 2019 - 09:15:40)

Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
DRAM:  128 MB
SPI-F: MXIC/C22018/MMIO16-1/ModeC 1x16 MB (plr_flash_info @ 83f831e4)
Loading 65536B env. variables from offset 0xe0000
Net:   Net Initialization Skipped
No ethernet found.
Hit Esc key to stop autoboot:  0
RTL9300# # help
?       - alias for 'help'
base    - print or set address offset
boota   - boota  - boot application image from one of dual images partition automatically
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
env     - environment handling commands
erase   - erase FLASH memory
flerase - Erase flash partition
flinfo  - print FLASH memory information
flshow  - Show flash partition layout
go      - start application at address 'addr'
help    - print command description/usage
iminfo  - print header information for application image
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing address)
mtest   - simple RAM read/write test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
printsys- printsys - print system information variables

protect - enable or disable FLASH write protection
reset   - Perform RESET of the CPU
reset_all- Perform whole chip RESET of the CPU
rtk     - rtk     - Realtek commands

run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
savesys - savesys - save system information variables to persistent storage

setenv  - set environment variables
setsys  - setsys  - set system information variables

sf      - SPI flash sub-system
sleep   - delay execution for some time
sys     - sys     - Realtek HTP test commands

tftpboot- boot image via network using TFTP protocol
upgrade - Upgrade loader or runtime image
version - print monitor, compiler and linker version

Vom 12010-12er gibts ein Firmware-Update-Datei. Die größe entsprich in 
etwa die des Linux-Systems. Die Dateienden ist jedoch .bix. Davon hab 
ich noch nie was gehört. Ich hab einfach mal blind versucht, die mittels 
loady hochzuladen. Die Datei wurde an Adresse 0x80000000 kopiert.

Der Versuch das Image auszuführen schlägt jedoch fehl:

RTL9300# # go 0x80000000
## Starting application at 0x80000000 ...
## Application terminated, rc = 0x2A

Ich hätte erwartet, dass bootm auch von dieser Adresse startet, tut es 
aber leider nicht:

RTL9300# # bootm
## Booting kernel from Legacy Image at 34000000 ...

Mit fehlt leider mit uboot die Erfahrung. Meine Idee war, die Firmware 
ins Ram zu kopieren, den Flash erstmal in Ruhe zu lassen  und schauen, 
wie weit ich komme.

Hat jemand eine Idee, wie man weiter machen könnte?

Vermutlich wäre es für mich einfacher, die beiden 16MB SPI-Flashs 
auszulöten und einfach den Inhalt zu kopieren. Das zerlegen würde ich 
mir aber gerne ersparen.

Vielen Dank,

Franz

[Franz (Gast)]

Kernel Log beim Booten:

U-Boot 2011.12.(TRUNK_CURRENT)-svn99721 (Oct 24 2019 - 09:15:40)

Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
DRAM:  128 MB
SPI-F: MXIC/C22018/MMIO16-1/ModeC 1x16 MB (plr_flash_info @ 83f831e4)
Loading 65536B env. variables from offset 0xe0000
Net:   Net Initialization Skipped
No ethernet found.
Hit Esc key to stop autoboot:  0
## Booting image from partition ... 0
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   RTK_SDK
   Created:      2019-10-24   9:16:10 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    4577343 Bytes = 4.4 MB
   Load Address: 80000000
   Entry Point:  80283510
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

console [ttyS0] enabled
bootconsole [early0] disabled
Calibrating delay loop... 531.66 BogoMIPS (lpj=2658304)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
NET: Registered protocol family 16
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 2, 20480 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 12288 bytes)
UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
NET: Registered protocol family 1
futex hash table entries: 256 (order: 0, 7168 bytes)
msgmni has been set to 239
random: modprobe urandom read with 0 bits of entropy available
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 39, base_baud = 10764700) is a 16550A
RTK_SPI_FLASH_MIO driver is bypassed
RTK_NORSFG3 driver is used
=================================================================
init_luna_nor_spi_map: flash map at 0xb4000000
SPI NOR driver probe...
MXIC/C22018/MMIO16-1/ModeC add SPI NOR partition
MTD partitions obtained from built-in array
Creating 7 MTD partitions on "rtk_norsf_g3":
0x000000000000-0x0000000e0000 : "LOADER"
0x0000000e0000-0x0000000f0000 : "BDINFO"
0x0000000f0000-0x000000100000 : "SYSINFO"
0x000000100000-0x000000200000 : "JFFS2 CFG"
0x000000200000-0x000000300000 : "JFFS2 LOG"
0x000000300000-0x000000980000 : "RUNTIME"
0x000000980000-0x000001000000 : "RUNTIME2"
=================================================================
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
rtk_gen1_hcd_cs_init: rtk_gen1_hcd_cs_init()!
rtk_gen1_hcd_cs_init: register rtk_gen1_ehci ok!
usb_phy_configure_process: usb_phy_configure_process()!
rtk_gen1-ehci rtk_gen1-ehci: Realtek On-Chip EHCI Host Controller
rtk_gen1-ehci rtk_gen1-ehci: new USB bus registered, assigned bus number 1
rtk_gen1-ehci rtk_gen1-ehci: irq 20, io mem 0x18021000
rtk_gen1-ehci rtk_gen1-ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usbtmc
usbcore: registered new interface driver usb-storage
TCP: cubic registered
NET: Registered protocol family 17
Freeing unused kernel memory: 3316K (803a3000 - 806e0000)
init started:  BusyBox v1.00 (2019.10.23-06:17+0000) multi-call binary
Starting pid 25, console : '/etc/rc'
RTCORE LKM Insert...

allocate mem to rtcore_devices[0].rt_data=0x87c8f000
RTCORE Driver Module Initialize
  IOAL init
  Log init
  Hardware-profile probe    (Forced profile: RTL9302B_8218D_2x8226_2xGE)
 (RTL9302B_8218D_2x8226_2xGE)
  Hardware-profile init
  GPIO probe (unit 0): (found)
  GPIO Init
Reset PHY gpio OK!
  SPI init (unit 0) (type3)
    SPI Master init
  TC probe (unit 0): (found)
  TC init (unit 0)
    TC util init (unit 0)
    TC util init (isr)
  Watchdog probe (unit 0): (found)
  Watchdog init (unit 0)
  I2C probe (unit 0)
  I2C init (unit 0)
  RTL8231 probe (unit 0): (found)
  RTL8231 init (unit 0)
  NIC probe (unit 0)
  IOAL init
  L2Ntfy probe (unit 0): (found)
RTK Driver Module Initialize
  MAC probe (unit 0)
    Chip 9302 (found)
  MAC init (unit 0)
  SMI protocol probe (unit 0)
  PHY probe (unit 0)
  Chip Construct (unit 0)
    Chip Construct
    Disable PHY Polling
    PHY Reset
    MAC Construct
    Turn Off Serdes
    Serdes Construct
    PHY Construct
    Turn On Serdes
    Enable PHY Polling
    Misc
  PHY init (unit 0)
  Mgmt_dev init (unit 0)
  I2C device init (unit 0)
  I2C device init (unit 0)
RTNIC Driver Module Initialize
RTDRV Driver Module Initialize
route: not found
RTK.0>

[Axel S. (a-za-z0-9)]

Franz schrieb:
> Ich habe die beiden im Titel angegebenen Switches

Schön.

Wenn du jetzt noch erklären könntest, was das im Forum
"Mikrocontroller und Digitale Elektronik" zu suchen hat?

[Franz (Gast)]

Uboot und Low Level gehört wohl eher zu "Microcontroller und Digitale 
Elektronik" als in die anderen Bereiche oder?

Spätestens, wenn es auf SPI-Flash kopieren raus läuft, passt es 100%.

[Viktor P. (lordnitro)]

Hi,
I also have the XGS1010-12 and find your post here interesting. Any 
progress on this? Do you have a description how to connect to the debug 
UART on the switch?

The *.bix firmware file is LZMA compressed.

You can uncompress the file using "binwalk -y 'lzma compressed data' -re 
XGS1210-12_V1.00(ABTY.3)C0.bix". That will give you an uncompressed 
file.

The you could use, binwalk --extract  40. Looks like there is two 
different the linux filesystem is under 350A20 & 3C21D0. You can extract 
them using cpio -i -F  350A20.

I havnt had time to dig around any more, but by the looks of it 
everything you need should be in this firmware file.

BR
Viktor

[Franz (Gast)]

Hello Viktor

Thank you for your response.
I didn’t continue because it was not very important for me.
You information sounds very useful.
Unfortunately I have to move and all my tools are already packed.
I will continue after it.


Best regards, Franz

[Franz (Gast)]

About the description:
There is a 4 pin header which is reachable without opening the device. 
It carries a standard 3.3V Uart with 115200 bps and 8N1 coding.

[Gregory Popp (Gast)]

Vorab eine Frage. Lässt sich das Netzwerk in u-boot eventuell durch 
folgenden Befehl "beleben"?

rtk network on

Das Image des XGS1210 hat einen 40 Byte uImage Header mit einer nicht 
Standard Magic Number (0x93001210). Anschließend folgt der LZMA 
komprimierte Linux Kernel.

XGS1210-12; V1.00(ABTY.3)C0; July 06, 2020

93 00 12 10  // Image Header Magic Number
0C 2B 26 FD  // Image Header CRC Checksum [crc32 of header with this field masked to all 0x0 == 0x0C2B26FD]
5E DE 38 AF  // Image Creation Timestamp [Monday, 8. June 2020 13:10:07 UTC]
00 55 74 4C  // Image Data Size [0x40 to 0x557488B == 0x55744C]
80 00 00 00  // Data   Load  Address
80 2B 73 80  // Entry Point Address
08 B1 6B AC  // Image Data CRC Checksum [crc32 of 0x40 to 0x557488B == 0x08B16BAC]
05    // Operating System [0x05 == IH_OS_LINUX]
05    // CPU architecture [0x05 == IH_ARCH_MIPS]
02    // Image Type [0x02 == IH_TYPE_KERNEL]
03    // Compression Type [0x03 == IH_COMP_LZMA]
56 31 2E 30 30 28 41 42 54 59 2E 33 29 43 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Image Name == 32V1.00(ABTY.3)C0

Franz schrieb:
> Vom 12010-12er gibts ein Firmware-Update-Datei. Die größe entsprich in
> etwa die des Linux-Systems. Die Dateienden ist jedoch .bix. Davon hab
> ich noch nie was gehört. Ich hab einfach mal blind versucht, die mittels
> loady hochzuladen. Die Datei wurde an Adresse 0x80000000 kopiert.

An der Adresse wird der dekomprimierte Kernel erwartet.

> Der Versuch das Image auszuführen schlägt jedoch fehl:RTL9300# # go
> 0x80000000
> ## Starting application at 0x80000000 ...
> ## Application terminated, rc = 0x2A
>
> Ich hätte erwartet, dass bootm auch von dieser Adresse startet, tut es
> aber leider nicht:RTL9300# # bootm
> ## Booting kernel from Legacy Image at 34000000 ...

bootm kann ein Image von einer anderen Adresse laden, man muss es dem 
Befehl aber mitgeben.

Folgendes sollte funktionieren:

# per uart zu ladendes LZMA komprimiertes Image (XGS1210-12_V1.00(ABTY.3)C0.bix)
# an RAM Position 64MByte speichern
loady 0x84000000

# bootm mitteilen wo uimage header + lzma komprimierter kernel im RAM zu finden
# ist, damit bootm den Kernel nach 0x80000000 (Data Load Address) entpackt, zur
# "Entry Point Address" springt und den dort zu findenden Code startet
bootm 0x84000000

Franz schrieb:
> Befehl angezeigt wird:U-Boot 2011.12.(TRUNK_CURRENT)-svn99721 (Oct 24
> 2019 - 09:15:40)
> Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
> DRAM:  128 MB
> SPI-F: MXIC/C22018/MMIO16-1/ModeC 1x16 MB (plr_flash_info @ 83f831e4)
> Loading 65536B env. variables from offset 0xe0000
> Net:   Net Initialization Skipped
> No ethernet found.
> Hit Esc key to stop autoboot:  0
> RTL9300# # help
> ...
> sf      - SPI flash sub-system

Die Befehle zum schreiben eines in den RAM geladenen Images auf den 
Flash scheinen im u-boot zu sein. 'printenv' sollte Auskunft geben wo 
auf dem Flash das Image erwartet wird.

Das ganze sollte grob wie folgend ablaufen:

# per uart zu ladendes LZMA komprimiertes Image (XGS1210-12_V1.00(ABTY.3)C0.bix)
# an RAM Position 64MByte speichern
loady 0x84000000

# start: 0x300000, Anzahl: 0xd00000; von 0x300000 bis zum Ende des 16MByte Flashchip
sf erase 0x300000 0xd00000

# lese 0x55748C Byte ab Speicheraddresse 0x84000000 und schreibe sie an Position
# 0x300000 des Flashchip
#
# die genau Anzahl der empfangenen/zu schriebenden Bytes sollte loady ausgeben
#
# wenn der u-boot nicht kaputt gepatched ist, sollte loady eine variable mit der
# Dateigröße anlegen, dann geht auch 'sf write 0x84000000 0x300000 ${filesize}'
sf write 0x84000000 0x300000 0x55748C

Alles komplett ungetestet! Spätestens wenn es an das schreiben des Flash 
geht, empfiehlt sich ein Backup des Flashchip.

[muetzekoeln (Gast)]

Hello,

any news on this? I'm also interested in upgrading xgs1210 to xgs1210 by 
firmware-upgrade. Does it work by starting the network (rtk network on) 
followed by starting upgrade web-service ("httpd" command)?

Is there a way to save original flash image with on board commands (e.g. 
"cp")?

Where can I find "rtk" commands documentation?

regards,
Christoph

[WRT54G (Gast)]

muetzekoeln schrieb:

> any news on this?

Compile openwrt yourself, or wait for a release - its wip:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/1170