Hasivo switches

I was able to access u-boot prompt from the serial console.

After clicking Esc to interrupt the autoboot, use the password "Hs2021cfgmg" to enter into a configuration shell with a SCHS prompt (Intelligent Switch Mass Production Menu). From this prompt just type XXXX and you will enter the u-boot prompt!

Fro the SCHS prompt you can use hshelp to see available command.

In u-boot there is a rtk command I was not fully able to understand but I used the "upgarde runtime" command to replace the kermnel image on the SPI via tftp. Actually I did all that because I brick the router!

I wil be really intereted having OpenWrt running on this nice small hardware!

1 Like

Actualy using rtk init initialize the netwok!!! Tftp from 192.168.0.111 should then work for uploading any kernel

Wow, awesome. How did you find the password?

Do you still have uboot, or did you overwrite that also?

I’ll get a dump of the stock once a SOP clip i’ve ordered has arrived. Hopefully you could use that to restore your switch.

I've found a way to use uboot to dump out the flash, so hopefully I'll be able to provide that 'shortly' (uboot console at 38400 and byte at a time reads means the 16MBytes will take quite a while).

I'm using this info

Should hopefully get you going again.

1 Like

I have recovered the original firmware.
I dump the flash (still waiting for a clip so I soldier wires!) using a RPI and flasrom. I analyze the u-boot binary to find out how to have a u-boot prompt and then - I had a backup of the original firmware I did with the original UI - I use the command upgrade runtime to flash back the original firmware.
All is working again.
But I am no more able to ssh to the router using a newly created user named root and I am sure I was able to do it before!

I got the datasheet (https://drive.google.com/file/d/1SkrpLVgOYEkKjAsaMBoaBuU5IdppSejw/view?usp=share_link) and an demo layout (https://drive.google.com/file/d/1iPUzHLwc2ZYDAl3dsgVP8JQqGGFGflbV/view?usp=share_link) from Hasivo for their HS104PTI PoE chip.

I've gone back to request I2C register / addressing info also.

1 Like

I got the I2C register map for the HS104 chips also (put them up on https://svanheule.net/switches/)
Just working on a driver for this.
Hopefully this coming weekend I'll be able to give it a go trying it out from uboot tftpboot.
I've added some very basic info here: https://svanheule.net/switches/s1100wp-8gt_se
I'll try to add more tonight, would be great if you could add any additional information you've got also.

1 Like

I was able to boot Openwrt using the device tree put together by koreapyj for the F1100W-8S+. Obviously this is just a proof of concept we can compile and properly package the image. By the way I have a S600WP-5GT-SE (5 ports) which is probably running the same firmware version of the 8 port. There is only 4 POE port (one POE board only while the 8 ports has two I assume).

I plan to start working on the device tree (although it's my first time).

By the way I was also able to put modify the original initramfs and produce a modified firmware to boot into the busybox shell. Let me know if this could be useful lto you while you develop the POE driver.

2 Likes

I don't even own of these switches (yet) but watch this thread with enthusiasm. Great work all!

Absolutely that would be great if you could provide the info on Busybox shell access.

I’ve already made a start on PoE driver. Based on tps23861 code already existing from Robert Marko. In the hwmon subsystem.

I’ve also made a start on devicetree, but not a fan of the current arrangement of the rtl930x DTS situation, so I’d like to more fully flesh out the base SoC DTSI, and bring in pin-ctrl stuff for selection of the various peripherals.

I’m happy to push to a github/gitlab (either mine or yours) to collaborate more.

1 Like

I created an image that boot to the shell (on the serial console). Would be glad to upload to your Google drive (what is the best way to share the firmware?).
Few point to use it. The board as the IP 192.168.0.1 and is expecting an tftp server on 192.168.0.111 (obviously this can be changed in U-Boot but these are the defaults). You need to:

# rtk network on
# tftpboot 0x34f00000 <filename>
# bootm 0x34f00000

You should be in thh shell. You will see the busybox has been compiled with not much commands but at least this is a starting point.
I noticed several command have been "overwriten" by linking from /bin to /sqfs/bin this is the case for sshs that has the hardcoded shell /bin/cli. Note that I have removed the original ln from /bin/cli to /sqfs/bin/cli. This the default sandboxed shell.

I am investigation Openwrt (booting kernel for now) and would be glad to push to your Github - looks like you have one- we can create branch and try to make some progress.

@ariko I have a thread here on the forum U-Boot for XGS12xx switches (and others based on realtek rtl930x) where I compiled my own rtl930x U-Boot from the dump. We can always improve it to add support if needed (only net stuff is probably needed ...) The repo I have for it lives here: https://gitlab.com/olliver/openwrt/realtek_sdk

@bevanweiss I've added your switch based on the openwrt github dts you sent a while ago. https://gitlab.com/olliver/openwrt/openwrt/-/commit/a521116365bbb78b8e99f29d46e71708e64dce23 is the current state, if you could read it over? I'm not sure on the LED configuration, as I can't find a picture of it. Also, I don't see (m)any hasvio switches with 2 leds, yet you documented two. The led on GPIO0, is hardware controlled as the 'sys_led' normally. it can do rapid blinking during power-on and booting. You called it the 'pwr' led? What is the function of the led you called 'status led' then? or is there a 'fixed always on' led to indicate power (that is more common) which cannot be controlled at all (as its not connected to a GPIO).

Also, You mentioned 'RTL8221 and RTL8226 PHYs' in your DTS, but then list 8 entries. So which one is it? I'll read your wiki page to see if I can learn more :slight_smile:

I haven't added the flash chip yet, but that should be a triviality and not matter for initramfs booting. So if you can give the dts some views, that would be good :slight_smile:

I haven't yet tested my tree; so no guarantee's that the WIP tree works at all :slight_smile:

@bevanweiss you linked me the bootlog at somepoint where the 'unrecognized JEDEC id bytes' where printed. According to the datasheet it should be '0xa14018' can you confirm that that's what was printed? I got all the other data from the datasheet I think, so we should be good there.

Yes this is correct. I have a patch to have it recognized

--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -6,6 +6,7 @@ spi-nor-objs			+= catalyst.o
 spi-nor-objs			+= eon.o
 spi-nor-objs			+= esmt.o
 spi-nor-objs			+= everspin.o
+spi-nor-objs			+= fudan.o
 spi-nor-objs			+= fujitsu.o
 spi-nor-objs			+= gigadevice.o
 spi-nor-objs			+= intel.o
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -477,6 +477,7 @@ extern const struct spi_nor_manufacturer
 extern const struct spi_nor_manufacturer spi_nor_eon;
 extern const struct spi_nor_manufacturer spi_nor_esmt;
 extern const struct spi_nor_manufacturer spi_nor_everspin;
+extern const struct spi_nor_manufacturer spi_nor_fudan;
 extern const struct spi_nor_manufacturer spi_nor_fujitsu;
 extern const struct spi_nor_manufacturer spi_nor_gigadevice;
 extern const struct spi_nor_manufacturer spi_nor_intel;
--- /dev/null
+++ b/drivers/mtd/spi-nor/fudan.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/mtd/spi-nor.h>
+
+#include "core.h"
+
+static const struct flash_info fudan_parts[] = {
+	/* Shanghai Fudan Microlectronics -- fn25xxx */
+	{ "fm25q128",  INFO(0xa14018, 0, 64 * 1024,  256, 0) },
+};
+
+const struct spi_nor_manufacturer spi_nor_fudan = {
+	.name = "fudan",
+	.parts = fudan_parts,
+	.nparts = ARRAY_SIZE(fudan_parts),
+};
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1847,6 +1847,7 @@ static const struct spi_nor_manufacturer
 	&spi_nor_eon,
 	&spi_nor_esmt,
 	&spi_nor_everspin,
+	&spi_nor_fudan,
 	&spi_nor_fujitsu,
 	&spi_nor_gigadevice,
 	&spi_nor_intel

That's what I have :slight_smile: Though your flags are wrong.

Anyhow, any more (partially) finished DTS files that are hanging in this thread? I have 2 Hasvio switches, and one EZ-U dts now in the tree; though they all need testing :S (and I'm still build-fixing some stupid shit and need to test it on my switch too)

I have a DTS for the Hasivo S600WP-5GT-SE (5 ports) largely inspired from the S1100WP-8GT-SE (8 ports version). I am trying slightly different set-up that the 8 ports but I am not able to have the 2.5G working (just 1G). Eventually the 5 ports should a subset of the 8 ports but I guess we are trying to have it work.
It may be nice to have it in your tree.

1 Like

I'll happily put your commit in my tree, can you link it? Best base it of 'my latest' s1100wp; as the one from bevan had a few ... oddities :slight_smile:

I would be glad.. but I am not sure to know how to do it! I have a local git only, should I register to Gitlab? Should I e-mail the patch (form the base you suggest). Excuse my ignorance..

whatever works for you; you can even copy/paste the content here. Though e-mail is probably easiest, as I can then get your patch as a patch, and keep you as author :slight_smile:

(git format-patch -1 , attach to a forum post is probably easiest)

1 Like

I can confirm, that's the JEDECID.
I've put together a patch for it against 5.15.104 (and also the 64Mb version of the same)

diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index e347b435a038..ef4a4c792694 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -6,6 +6,7 @@ spi-nor-objs			+= catalyst.o
 spi-nor-objs			+= eon.o
 spi-nor-objs			+= esmt.o
 spi-nor-objs			+= everspin.o
+spi-nor-objs			+= fudan.o
 spi-nor-objs			+= fujitsu.o
 spi-nor-objs			+= gigadevice.o
 spi-nor-objs			+= intel.o
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 0a78045ca1d9..1ca748f31c65 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1620,6 +1620,7 @@ static const struct spi_nor_manufacturer *manufacturers[] = {
 	&spi_nor_eon,
 	&spi_nor_esmt,
 	&spi_nor_everspin,
+	&spi_nor_fudan,
 	&spi_nor_fujitsu,
 	&spi_nor_gigadevice,
 	&spi_nor_intel,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 25423225c29d..ab51ac388d5b 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -614,6 +614,7 @@ extern const struct spi_nor_manufacturer spi_nor_catalyst;
 extern const struct spi_nor_manufacturer spi_nor_eon;
 extern const struct spi_nor_manufacturer spi_nor_esmt;
 extern const struct spi_nor_manufacturer spi_nor_everspin;
+extern const struct spi_nor_manufacturer spi_nor_fudan;
 extern const struct spi_nor_manufacturer spi_nor_fujitsu;
 extern const struct spi_nor_manufacturer spi_nor_gigadevice;
 extern const struct spi_nor_manufacturer spi_nor_intel;
diff --git a/drivers/mtd/spi-nor/fudan.c b/drivers/mtd/spi-nor/fudan.c
new file mode 100644
index 000000000000..764fbadf1ba5
--- /dev/null
+++ b/drivers/mtd/spi-nor/fudan.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/mtd/spi-nor.h>
+
+#include "core.h"
+
+static const struct flash_info fudan_nor_parts[] = {
+	/* Fudan */
+	{ "fm25q64", INFO(0xa14017, 0, 64 * 1024, 128,
+					  SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB |
+					  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)},
+	{ "fm25q128", INFO(0xa14018, 0, 64 * 1024, 256,
+					  SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB |
+					  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)},
+};
+
+const struct spi_nor_manufacturer spi_nor_fudan = {
+	.name = "fudan",
+	.parts = fudan_nor_parts,
+	.nparts = ARRAY_SIZE(fudan_nor_parts),
+};

1 Like