@robimarko thanks for testing. As expected this is dependant on firmware version.
@flygarn12: My A1 switch version has no official user management. I'm very surprised that I found a guest user baked in. With the admin account i cannot even choose privilege change.
Playing around a little more it seems to be even easier:
DGS-1210-16 login: root
Password: ilovecameo (hard coded ...)
DGS-1210-16# show privilege
Current privilege level is 15
The firmware doesn't work for any newer hardware than F1 anyway.
this is great news !!
however, i tried to do the same on top of 21.03.02 branch and for me the config is still not working.
can you share your full DTS, please?
@bmork: the 2 µs was a stupid copy-n-paste error from my side 
tnx for spotting...
IIRC i found the string ilovecameo in firmware for F1/G1 too. Maybe login root/ilovecameo works there too.
Unfortunately not, most likely the username is different, its really weird for the guest account to work.
Yeah, here is the branch I am working on:
thanks.
After peeking into your DTS as well as changing to recent mainline githash, the fans are now working for me, and i can even steer the fans by writing the PWM values into the /sys/ directories.
@robimarko: from what i see, some things are missing in your DTS
@all
in general:
I am aware that UART1 is disabled, and the last SFP is missing as I havent traced that one out so far
There are in total 5 i2c(SDA,SCL) pairs:
6,7
1,2
22,23
11,12
32,31 (that is the fan one)
the first 4 follow the same logic:
i2c3: i2c-gpio-3 {
compatible = "i2c-gpio";
sda-gpios = <&gpio1 11 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
scl-gpios = <&gpio1 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
};
I figured out the image format for HPE 1910/1920 switches (based on the HPE 1910 u-boot source that was posted earlier in this thread, and the actual images). I've created a Git repository to document the information. This also includes the flash layout, a few notes about the boot process, and Python scripts for unpacking and creating images.
This branch contains a patch for building an OpenWrt initramfs image for HPE 1920-16G (which seems to be identical to 1920-24G except that the first external PHY is missing). I had to remove the LED initialization in arch/mips/rtl838x/setup.c, as the system LED output is connected to a hardware watchdog (which causes a reset after about a second if the system LED is configured not to blink). The actual LED is controlled via LED_SW_CTRL on this device.
The resulting image still needs to be manually packaged into a image that the bootloader understands using the Python script. It is then possible to run it via FTP/TFTP from the bootloader (without flashing), by selecting 3 (Ethernet), and then 1 (Download to SDRAM and run) in the Extended BootWare menu (before doing it for the first time, the network parameters need to be configured using option 5 in the Ethernet submenu).
Now, the question is how to go from here to a proper image with persistent storage. On this device, most of the flash is occupied by a filesystem called "VFS", which stores both firmware images and configuration files. The bootloader can only boot from this filesystem (or as mentioned above by loading an image to RAM). Access to the u-boot shell is disabled in non-debug builds (and even if it was enabled it wouldn't help for actually installing OpenWrt, as there is no permanent u-boot environment). So far, I thought of a few different options:
Using the filesystem to store kernel and rootfs images looks like the obvious solution at a first glance. But it doesn't seem like it would be easy to do, as it would require kernel support as well as special handling for sysupgrade (and all that just for these devices), so I don't think this is a good idea.
Another possibility would be to replace the secondary bootloader (Extended BootWare) by a regular u-boot. As the primary bootloader (Basic BootWare) allows to reflash the secondary one via XMODEM this should be doable without risking to brick the device. Of course, that would still require building the actual bootloader. Doing this based on existing u-boot sources may be possible, but I guess the result would be unlikely to get merged into OpenWrt.
Depending on how the filesystem actually works, it may be possible to use a fixed partition layout where the kernel image is actually a full filesystem image including a firmware image. The idea being that after initial installation from a initramfs image the bootloader would just see a small filesystem containing the kernel image and the remaining part of the flash could be used by OpenWrt for rootfs (reverting to the original state should still be possible via the format option in the bootloader menu). This way, only the image builder would have to understand the filesystem. But I still have to check if the actual filesystem format allows to do this.
Not sure why you don't think option 2 is a possibility. There are other OpenWrt ports that replace the stock u-boot with a new u-boot. See many of the kirkwood devices.
I have a few of the HPE devices and might be able to help with testing. I have the 1910-24 (JG539A), 1910-8 (JG537A), 1920-16G (JG923A) and 1920-8G (JG922A).
This is some great work! Could you add this information on the wiki? I created a placeholder link/page a long time ago, but never got around to figuring out how this works: https://svanheule.net/switches/image_formats/start
@sumo For the record, I've repackaged the u-boot archive to hpe-1910-uboot.tar.gz, and am now hosting it on the wiki too.
I was specifically referring to using the vendor u-boot as a base there, and I'm not sure if this would be acceptable. Most of the existing u-boot packages seem to be built by applying patches onto a relatively recent upstream u-boot.
I've received the source for the ZyXEL GS1900-24EP (GS1900-24EP(V2.70(ABTO.1)C0). How can I get the file to you to host on https://svanheule.net? I wasn't able to find an option on the site for uploading anything other than image files.
These (rather large) archives aren't hosted on the wiki themselves, so I manually upload them to a different directory. I'll PM you a link where you can upload the archive.
I added documentation and scripts for the filesystem in my Git repository. The approach of using a filesystem image for the kernel and storing the rootfs at a fixed location seems to work (tested with manually created images flashed via mtd, as creating proper images including sysupgrade support is going to require some additional work).
Of course, this is still a bit of a hack, as the bootloader has no idea of the rootfs, and the size of the filesystem is fixed. But as long as one doesn't perform any filesystem operations using the bootloader this should be fine (marking the kernel image as main boot application is ok, as it only writes to the bootloader data, and not to the filesystem itself).
I like to be power conscious of the devices I have powered on 24/7, and am wondering if the RTL838x is a power hungry SoC, or simply, more ports = more power.
I only have a 28 port model in my possession for comparisons sake, so for those of you with a "Kill A Watt TM" (or equivalent AC power meter), I'm curious what desktop models (8 or 10 ports, especially with PoE capability) typically consume?
DGS-1210-28MP
11W during Boot
14W booted with the fans on auto (Medium?)
15W with one Yealink T23G connected
GS308P (Link to thread on BCM53128 switch hacking)
1W at Idle
3W with one Yealink T23G connected
You cannot deduce anything about the power thirst of the RTL838x or even about the ports from this. The 1210-28MP has a power budget of 370W, whereas the GS308P has a maximum of 53W. You are using the 1210 at it's extreme low end of the power budget and that means the efficiency is likely to be in the area of 10% - 20%, it could even be lower. The power supplies I saw in these switches do not raise confidence in their efficiency levels. So probably you merely see the efficiency of these power supplies at work.
That said I did experiments in the past. An inactive port does not seem to use any power, the PHYs are typically only luke-warm in this state. Every active 1G port is about 1W, every 10G port about 10W. This can be massively reduced by enabling EEE via ethtool, to about 0.1-0.2W for the 1G links. There is quite good support for the RTL838x HW and typical PHYs found with them for EEE, unfortunately this is not enabled by default in OpenWRT and there was not much interest in this in the past. At that point I completely ignored this topic for the RTL93xx devices, because this is significant work to be done for every PHY. Maybe with the change of times there is renewed interest.
I have a Netgear GS108Tv3 with OpenWrt which I'm powering from a Cisco 3560CX. According to the Cisco switch, the GS108Tv3 consumption when idle (link on two ports, but almost no traffic) is around 2.3W
c3560cx#sh power inline police Gi1/0/1
Interface Admin Oper Admin Oper Cutoff Oper
State State Police Police Power Power
--------- ------ ---------- ---------- ---------- ------ -----
Gi1/0/1 auto on none n/a n/a 2.3
I believe this is pretty accurate. I also have two similar swithces (8-port with PD support) using other chips. Also powered by the same Cisco switch. Both use significantly more with about the same traffic and number of active links.
Linksys SLM20008 (really old - bought 2009. don't know SoC vendor):
c3560cx#sh power inline police Gi1/0/3
Interface Admin Oper Admin Oper Cutoff Oper
State State Police Police Power Power
--------- ------ ---------- ---------- ---------- ------ -----
Gi1/0/3 auto on none n/a n/a 5.1
Cisco SG250-08 (from 2019, Marvell SoC I believe):
c3560cx#sh power inline police Gi1/0/4
Interface Admin Oper Admin Oper Cutoff Oper
State State Police Police Power Power
--------- ------ ---------- ---------- ---------- ------ -----
Gi1/0/4 auto on none n/a n/a 4.2
The above numbers are consistent with the regular measurements I run.