Hi, has anyone managed to use openwrt on the hp 1910-16g JE005A? I'm trying to see if I can make a build for this switch.
This model doesn't use a Realtek SoC, see here: https://svanheule.net/switches/hpe_1910_series
1 Like
Thanks, I saw some comment about that switch is on hidden list, sad..
I took the heatsink off of a dead JE006A recently and it's a marvell switch and phy that I can't find datasheets for.
98DXH325A1 with 88E1340Q copper phy's and 88E1340 for the SFP's.
Hi All.
I have now acquired a JG926A 370W model just started working on a patch for HP 1920 24G PoE models this afternoon.
Now I have learnt of the issue with getting kernel 6.6 otherwise target is dropped? Reading the pull request on github.
Wiling to help test?
I have HP 1920-8G PoE (65W/180W) targets as well to help test.
I'm willing to obtain the 48G model if you need a tester for that? I think someone on github was testing already though.
Simply compiling the PR series, installing and doing basic network tests (maybe VLAN configuration) will be sufficient to get things going. Please report your finding afterwards in the PR.
2 Likes
Thank you @plappermaul for doing the work.
As reported in the pending PR.
With the latest fixes, everything works for my devices.
As soon as this is merged and we get more test coverage I would love to see this kernel as default.
I've updated the PR for HPE 1920-48G and 1920-48G-PoE switches to work with the new 6.6 kernel directory layout. Had to clear some desk space and put the big switches away temporarily but it builds alright.
2 Likes
I need some testers for this pull request. It includes two critical fixes:
- The proper detection of external RTL8218B PHYs
- Initialization of RTL8218B PHYs on RTL839x
These might break already working RTL838x and RTL839x devices. At least two test cases are required to verify proper implementation:
- Someone with a RTL839x device with external RTL8218B that currently works
- Someone with a RTL8382 device with external RTL8218B that currently works
Compile & boot from TFTP/initramfs should be sufficient. Report back in the PR:
- if network on RTL8218B ports is working
- Output of syslog: initialize external RTL8218B version ..., romid ..."
Thanks in advance.
1 Like
Right now the Zyxel 1920 are effectively 8MB targets, which means they have a limited lifespan on kernel 6.6 and beyond.
However these devices do have a 16MB flash chip, and are only limited by the strict adherence to the original vendor dual-boot partitioning.
Would it be acceptable to repartition the Zyxel 1920 devices in the main branch to prolong their lifespan?
If this isn't viewed as a bad idea I'll submit a PR to extend the partition size to cover firmware and firmware2 partitions. I saw some errors when moving the start of the partition but moving the end seems fine.
2 Likes
I support that idea. IIRC there was some "feature" to leave the partition definition as is and to combine multiple ones into the OpenWrt root.
1 Like
Yeah, the problem on the ZyXEL GS1920 series is that we are going to lose recovery options if we use the second image. As there is only BootBase (not BootExt), we don't have recovery options similar to U-Boot.
Looks like janh on the PR already tested for you but:
Do you still need a tester for RTL839x device?
I can test with SFP's on HPE-1920-24G-PoE+ 370W if required.
Yes still feedback needed. As the first version was not perfect and I need som register info. See my feedback in PR.
1 Like
Looks like we're cutting it close with the dual partition layout with kernel 6.6. I think there's a case to be made for the U-boot based devices to be moved to a single partition layout?
1 Like
Any way around this? I am not averse to using the UART console for emergencies if it keeps the switch receiving updates through 24.x and beyond.
I looked and found mtd-concat but that seems to imply the joining of separate hardware mtd device instead of joining multiple partitions. Think we would need to update the partition structure here.
Anyone know if the new 6.6 kernel improves handling of LACP bonding?
It's been a while, but if I remember correctly, the problem is that the checksum that BootBase uses to determine if an image is intact or corrupt, is calculated over BootExt + Firmware. That's the reason why my ongoing OpenWrt port uses lzma-loader instead of BootExt and I calculate the checksum only over lzma-loader and not the whole image.
IMHO there are at least two ways around that:
- Modify the checksum of the OEM image to span only over BootExt during installation of OpenWrt. I don't know, however, if BootExt can be booted without a valid image. Using this approach, it might even load the kernel without
lzma-loader. A separate utility for on-device checksum update would need to be written (that's rather easy, the algorithm is already implemented in C). - Replace BootExt by U-Boot. That was my initial approach and I do have a somewhat working U-Boot port, but it's based on an ancient Realtek SDK. Getting it to compile is really a PITA. I never tried chain-booting from BootBase, in my experiments I wrote U-Boot directly to the flash and replaced BootBase, too.
- I modified
lzma-loaderto be able to load BootExt of the second image. This doesn't validate the checksum, hence it might be possible to start a plain BootExt with an invalid checksum / invalid firmware image that could be used for recovery purposes.
All of this needs to be tested. Unfortunately, I'm a bit short on dev time at the moment, but I hope that I'll have more time for this in a couple of days.
That's the way this is implemented in a lot of other devices. The advantage is that the original partition structure is kept and that it can cover partitions not adjacent to each other. I used that, for instance, on the ZTE MF287 series.
If we keep BootExt on the ZyXEL GS1920, mtd-concat is the only option as BootExt would be inbetween the firmware images.
1 Like
U-Boot sounds like the cleanest route. How much effort to compile against a recent Realtek SDK?