Interesting. The one I found listed itself as a JG927A but stated it had PoE+
Perhaps it was mis-labeled by the seller? I'll need to return it in that case.
Update: They have a separately listed JG928A for the same price. I suspect they mis-labeled this item
Hello Peoples, any progress on partition merge for gs1900-8 ? Could anyone know when a snapshot with included update will appear or when this could be included in an upcoming release?
Hi, I need some help:
I had a Zyxel XGS1250-12 running with an old snapshot. I upgraded to the latest stable release 23.05.5 and not it is stuck at the boot (same problem reported here: https://github.com/openwrt/openwrt/issues/16570.
I've access to serial, but no prompt. Is there any option to rescue and flash another version of operwrt?
Thanks
Would be good to get it merged, I'm running my Zyxel GS1900 with the merged partition layout and the extra space makes life much easier on kernel 6.6
I just noticed that it's been ages since I last saw mention of the XGS1210. Any new updates on its SFP+?
Merged with commit 35acdbe9095d ("realtek: merge Zyxel GS1900 firmware partitions"). As mentioned on the bug ticket, some caveats apply.
To change to the new layout, you will have to perform a factory install. So first run a new initramfs image with compatibility version 2.0 (as if going back to stock, or via tftpboot). The initramfs images have a size check, so they can also be installed from stock FW and from OpenWrt device compat v1.0.
It is possible to migrate your config from a 1.0 to a 2.0 install, but you must change the compatibility version in /etc/config/system when restoring a backup that was made from 1.0.
I succeeded to make working SFP+ ports on SKS8300-8X.
I'm working for OpenWrt installation to the spi-nor flash in the device now...
The encryption method of stock firmware is unknown... Please help.
Only the first 0x200 (512 bytes) are encrypted, but without 0xc - 0xf and 0x10c - 0x10f.
decryption test:
192.168.2.360x300Ctrl + BCtrl + F and enter the passphrase diagshell_unipoe_envdebug_unish_env commandrtk 10g 0 <fiber1g|fiber10g>
fiber1g, 10GBase-*R: fiber10grtk ext-devInit 0rtk ext-pinSet 2 0
exit commandrun tftp:<image> command
run tftp:stock.imgmd.l 0x81000000 0xc0I see that this is now cherry-picked in v24.10.0-rc4 as well. Nice!
And every time I'm "hit" by simple layout changes requiring re-install I have the exact same chain of thoughts (starting to get old, I guess):
Wondering if I'm the only one. I note that no one has created such a solution yet, so I guess not?
Today I ran into the compat_version issue you've already fixed in main. I was testing 24.10-rc4 coming form a stock GS1900-24E. This fix needs to be picked for the next 24.10 version as installing rc4 in it's current state will not work for "normal" users.
The fix was cherry-picked to 24.10 as well:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ec49df8692dfdb150c3a6808cf486ce328678d30
24.10-rc4 does need a small manual intervention now, but it's only a config update. Similar to an earlier commit, you should be able to edit /etc/config/system or run
uci set system.@system[0].compat_version='2.0'
uci commit
hi, i have lots of sg2210p v3.2 switches working for a while. neither of them could be flashed using official docs but writing firmware directly to soic chip worked for all of them (desolder -> write firmware -> solder it back)
do we get some improvements with upcoming 24.10 release?
maybe there is some chance we could get some built in sfp / poe management / led support ? currently have to use debugfs to enable sfps and leds. poe works after writing to broadcast i2c address and bringing tps23861 and its 'ports' up where poe is needed.
this is the config i had to do (i2cset seem to be preserved between reboots/firmware updates)
root@edgeswitch3:~# cat /etc/rc.local
# enable poe
echo 0-0030 > /sys/bus/i2c/drivers/tps23861/unbind
i2cset -y 0 0x30 0x12 0xff
echo tps23861 0x28 > /sys/bus/i2c/devices/i2c-0/new_device
echo 1 > /sys/class/hwmon/hwmon0/in0_enable
echo 1 > /sys/class/hwmon/hwmon0/in1_enable
echo 1 > /sys/class/hwmon/hwmon0/in2_enable
echo 1 > /sys/class/hwmon/hwmon0/in3_enable
echo 1 > /sys/class/hwmon/hwmon1/in0_enable
echo 1 > /sys/class/hwmon/hwmon1/in1_enable
echo 1 > /sys/class/hwmon/hwmon1/in2_enable
echo 1 > /sys/class/hwmon/hwmon1/in3_enable
# enable sfp
echo 0x0510ff00 > /sys/kernel/debug/rtl838x/led/led_p_en_ctrl
echo 0x140 > /sys/kernel/debug/rtl838x/led/led_sw_p_ctrl.26
echo 0x140 > /sys/kernel/debug/rtl838x/led/led_sw_p_ctrl.24
# enable system led
echo 0x005 > /sys/kernel/debug/rtl838x/led/led_sw_p_ctrl.20
# enable port leds
echo 0x00a4014f > /sys/kernel/debug/rtl838x/led/led_mode_ctrl
echo 0x0510ff00 > /sys/kernel/debug/rtl838x/led/led_p_en_ctrl
echo 0x00100000 > /sys/kernel/debug/rtl838x/led/led0_sw_p_en_ctrl
echo 0x00100000 > /sys/kernel/debug/rtl838x/led/led1_sw_p_en_ctrl
echo 0x0fffffff > /sys/kernel/debug/rtl838x/led/led2_sw_p_en_ctrl
exit 0
Shameless plug for my alternative RTL8231 driver:
Owners of a GS1900 with RTL8380/82 SoC can just build the provided changes for their device. Other people wishing to test the new driver will have to modify their DTS according to the changes in gs1900.dtsi
Happy testing! 
Ooh wow thanks!
So it retains pin config on warm boots?
Does it retain bootloader gpio config?
That's the main issue with the existing driver from a fan control perspective for JG922A/JG925A/JG926A/JG928A.
Hi all,
Trying to flash a JG927A. Looks like the eBay seller wiped the entire firmware off the thing so it just drops me to a bootloader on the serial console.
Trying to TFTP OpenWRT 23.05 or 24.10.0-rc4 to the device results in the error "Something wrong with the file"
Strangely it also does this with the "stock" CMW520-R1121 firmware bin file downloaded from HP's website.
I assume the switch may be faulty but wanted to confirm if this was a known issue or not
Make a new topic and post serial logs?
Are you doing basic bootloader on extended bootloader?
I ran jg928a and jg927a fine from tftp. example serial output on the wiki.
When loading stock firmware I haven't tftp booted to sdram, I've loaded the firmware image to flash then set the primary image, then booted.
https://openwrt.org/toh/hpe/1920-48g_jg928a
https://openwrt.org/toh/hpe/1920-48g_jg927a
Confirm please that it's a JG927A not a JG928A? Are you loading the right firmware?
I don't think jg928a/jg927a was in 23.05? Only snapshot and I guess now 24.10 RC's?
Extended bootloader.
I followed the instructions from the wiki.
Unit is a JG927A. I also have a JG928A but I have not tested it yet.
It is able to load the file over TFTP using the "load to SDRAM and run" but then simply gives the "Something wrong with the file" error
Tested with 23.05, 24.10 and a snapshot build. Same error on all
Attempted to boot a JG928A using the same openwrt snapshot via TFTP. Same error as the JG927A
I was able to upgrade its original firmware to the final R1121 build before testing OpenWRT (including updating the bootloader) but it's still unable to boot an image
Small update: Re-flashed both devices with the latest stock firmware. Set up TFTP from a physical Linux machine instead of a VM. OpenWRT booted and immediately began loading
Not sure what about talking to a VM upset TFTP but if anyone else hits the same wall I did hopefully this solution helps them 
Can you get to the bootware file manager? You will need to ensure that there's enough free space in the flash filesystem and after uploading the firmware you need to go into bootware and select which flash file the bootloader should use as it can contain multiple firmware files.
Edit - just saw your latest message - HPE firmware updates also included bootloader updates so looks like this has fixed the issue. Always update to the latest stock firmware before loading OpenWRT to get the latest bootloader.