Skip to content

Add support for HiSource K0402WS-V3.0.#97

Open
TylerDurden-23 wants to merge 1 commit intologicog:mainfrom
TylerDurden-23:hs-add-clean
Open

Add support for HiSource K0402WS-V3.0.#97
TylerDurden-23 wants to merge 1 commit intologicog:mainfrom
TylerDurden-23:hs-add-clean

Conversation

@TylerDurden-23
Copy link

@TylerDurden-23 TylerDurden-23 commented Jan 24, 2026

As discussed in #86.

The magic number LED approach is taken from #44 and can be reused there.

@logicog
Copy link
Owner

logicog commented Feb 1, 2026

Could you give PR #107 a try regarding the LED configuration? I see that the LED-pads are configured very differently, but the logical side, i.e. the led-sets and the led-ids could already be adapted. This then allows to assign different functions to the LEDs.

I will have to look into what to do about the LED-pads, which is the hardware configuration side, whereas the ledids/ledsets are the logic for the ASIC...

@logicog
Copy link
Owner

logicog commented Feb 1, 2026

I had thought, that maybe the values for RTL837X_REG_LED_GLB_MUX_1, RTL837X_REG_LED_GLB_MUX_2... were just default values from your version of the SoC, because there is no way these can be configured using at least the GPL-dumped SDK. Now, looking into your dumped flash, I see a routine which sets meticulously one LED-pad after the other using the rtl8373_setAsicRegBits function. So this is for real. The next problem is, there is no documentation for these settings...

I will look how to set this up in machine.c.

@TylerDurden-23
Copy link
Author

@logicog I tried the PR - and as expected it is not working correctly. I can only get 4 of the needed 12 needed LEDs working.

@logicog
Copy link
Owner

logicog commented Feb 3, 2026

Did you add the correct numbers for the LED-pad values in a "magic" configuration routine, or are already the LED-sets wrong? In the discussion for PR #107 it seems we may configure just the LED-sets with the de-magiced setup, but keep unstructured values for the LED-pads. But I am also working on configuring those via a mapping table pad <-> LED.

@TylerDurden-23
Copy link
Author

@logicog A "combined" approach seems to work - I can strip down the magic number function to:

	REG_SET(RTL837X_REG_LED_GLB_MUX_1, 0x08144040);
	REG_SET(RTL837X_REG_LED_GLB_MUX_2, 0x1037f309);
	REG_SET(RTL837X_REG_LED_GLB_MUX_3, 0x12454391);
	REG_SET(RTL837X_REG_LED_GLB_MUX_4, 0x19616555);
	REG_SET(RTL837X_REG_LED_GLB_MUX_5, 0x1c79d65a);
	REG_SET(RTL837X_REG_LED_GLB_MUX_6, 0x0002181d);

Plus run your new configuration, and I get a functional though not totally identical led signaling.

@logicog
Copy link
Owner

logicog commented Feb 3, 2026

You should be able to replace even the REG_SET(RTL837X_REG_LED_GLB_MUX_1-6, xy); with the correct setting for you device:

.led_mux_custom = 1,
	.led_mux = { 0x00, 0x01, 0x...},

6 bits of the LED_GLB_MUX registers give one of the entries in the .led_mux list. You can get them by configuring these register using the magic numbers during boot, and then printing them out once via leds_dump() and then putting the printed out list into .led_mux. Then you no longer need the magic numbers. Possibly with the exception of RTL837X_REG_LED_GLB_ACTIVE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants