Is there any wm8850 prebuild image or kernel?

[kez...@gmail.com]

I have small wm8850 netbook

[Fernando Cassia]

On Wed, 26 Feb 2025 at 14:13, kez...@gmail.com <kez...@gmail.com> wrote:

I have small wm8850 netbook

https://github.com/lrussell887/Debian-for-WM8505-Netbooks

FC

[kez...@gmail.com]

will it work on wm8850?

[Fernando Cassia]

On Thu, 27 Feb 2025 at 09:59, kez...@gmail.com <kez...@gmail.com> wrote:

will it work on wm8850?

Sorry, I misread the model number. Not sure about the differences between wm8850 and 8650.

You will have to ask. He already says for the 8650...

"I have been unable to test the WM8650 since I only have WM8505 devices. The kernel options should be the same, so I would expect it to work after changing wm8505-ref.dtb to wm8650-mid.dts in the build script. The wm8505fb.patch would likely need to be reverted as well since WM8650+ uses a different pixel format, which can be done by deleting the file from the patch folder. Please reach out if you run into issues or are able to get this working".

Many many ages ago there used to be a Debian image for 8505 devices at 4PDA forums but I checked now and the Yandex Disk links are dead/empty

https://4pda.to/forum/index.php?showtopic=226787&st=1560

Debian Live SD ENG (everything you need to create a bootable SD card. For all WM8505 versions)

_{Size: 137.42 MB}

FC

[Alexey Charkov]

WM8850 was ARMv7 based with NEON support (thus can run armhf images),
while WM8650 was ARMv5 based with no FPU (thus armel only).

It's best to just grab an up to date Debian armhf root filesystem
image, and compile a custom kernel from mainline enabling ARMv7 and
WM8850 config options, plus appended DTB support. Build a zImage,
append a suitable DTB, pack it into a legacy u-boot image with
mkimage, boot from SD using a custom u-boot script. Then we can take
it from there :)

Best,
Alexey

> --
> You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/CACGw4H4TmUOAD1i6%2BDfRhCHLV%3D2Y%3Dd68cHWF1dHMUFw2f-dh8w%40mail.gmail.com.

[Brigham Campbell]

It's been a couple months since I last repeated the process to compile the latest kernel, but I was able to compile Linux for the WM8650 not long ago.

Here's more information on what it took: https://groups.google.com/g/vt8500-wm8505-linux-kernel/c/L1Q6OHDGDcM

You'll likely find issues with the keyboard. There are other email threads in this group where Alexey has helped people find a workaround.

Cheers,

Brigham

On Mon, Apr 21, 2025 at 12:27 AM Michel Gomes <mic...@voltdata.info> wrote:

Hi! Can this GitHub repository be used to install the system on a device with a WM8650 CPU? I know it's similar to the WM8505, but I just wanted to confirm if it's compatible or if any changes are required. Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/cf594ef3-4537-4ece-86ed-1ade3cb9950cn%40googlegroups.com.

[Alexey Charkov]

On Mon, 21 Apr 2025 at 10:32, 'Brigham Campbell' via VT8500/WM8505 Linux Kernel <vt8500-wm8505...@googlegroups.com> wrote:

It's been a couple months since I last repeated the process to compile the latest kernel, but I was able to compile Linux for the WM8650 not long ago.

Here's more information on what it took: https://groups.google.com/g/vt8500-wm8505-linux-kernel/c/L1Q6OHDGDcM

You'll likely find issues with the keyboard. There are other email threads in this group where Alexey has helped people find a workaround.

Keyboards on WM8650 are internally connected to a USB 1.1 UHCI controller, and thus don’t need anything special to enable beyond what’s already in mainline kernels (unlike WM8505, which used a dedicated i8042 controller, for which my patch back in 2010 got acked but never merged upstream). Display settings in the WM8505fb driver are also by default optimized for WM8650+, so no changes are needed.

I would suggest simply building a kernel from mainline sources and trying that before going into any custom stuff. v6.14.x or some such. You’ll only need a cross-compiler for armel, common kernel build deps for your distro (gcc, ncurses-devel and such), dtc and u-boot-tools (mkimage specifically).

As for the root fs, you can use the same as for WM8505, as the CPU architecture didn’t change between them. 

Please shout if you need any support:)

Best,

Alexey

On Mon, Apr 21, 2025 at 12:27 AM Michel Gomes <mic...@voltdata.info> wrote:

Hi! Can this GitHub repository be used to install the system on a device with a WM8650 CPU? I know it's similar to the WM8505, but I just wanted to confirm if it's compatible or if any changes are required. Thanks in advance!

On Wednesday, February 26, 2025 at 4:53:40 PM UTC-3 Fernando Cassia wrote:

On Wed, 26 Feb 2025 at 14:13, kez...@gmail.com <kez...@gmail.com> wrote:

I have small wm8850 netbook

https://github.com/lrussell887/Debian-for-WM8505-Netbooks

FC

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/cf594ef3-4537-4ece-86ed-1ade3cb9950cn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/CAM-WoJzatYiXTGAEqabdPKFPLJTbZxa%3DqHFJ9kX2QieRTL4W%2Bg%40mail.gmail.com.

[Michel Gomes]

I modified the build script in https://github.com/lrussell887/Debian-for-WM8505-Netbooks by replacing wm8505-ref.dtb with wm8650-mid.dtb to target the correct device. However, during the build process, I'm encountering a compilation error when running make modules, specifically in the Mellanox mlx4 driver, which I believe is unrelated to my use case.

Here’s the error:

In function ‘check_copy_size’,
    inlined from ‘copy_to_user’ at ./include/linux/uaccess.h:168:6,
    inlined from ‘mlx4_init_user_cqes’ at drivers/net/ethernet/mellanox/mlx4/cq.c:317:9,
    inlined from ‘mlx4_cq_alloc’ at drivers/net/ethernet/mellanox/mlx4/cq.c:394:10:
./include/linux/thread_info.h:228:4: error: call to ‘__bad_copy_from’ declared with attribute error: copy source size is too small
make[6]: *** [scripts/Makefile.build:250: drivers/net/ethernet/mellanox/mlx4/cq.o] Error 1
make: *** [Makefile:2010: .] Error 2

I’ve also confirmed that this issue occurs even with the original, unmodified build.sh script, so it doesn’t seem to be caused by my changes.

Do you have any suggestions on how to work around this?

Any guidance would be greatly appreciated.

[Alexey Charkov]

On Wed, Apr 23, 2025 at 7:01 AM Michel Gomes <mic...@voltdata.info> wrote:
>
> I modified the build script in https://github.com/lrussell887/Debian-for-WM8505-Netbooks by replacing wm8505-ref.dtb with wm8650-mid.dtb to target the correct device. However, during the build process, I'm encountering a compilation error when running make modules, specifically in the Mellanox mlx4 driver, which I believe is unrelated to my use case.
>
> Here’s the error:
>
> In function ‘check_copy_size’,
> inlined from ‘copy_to_user’ at ./include/linux/uaccess.h:168:6,
> inlined from ‘mlx4_init_user_cqes’ at drivers/net/ethernet/mellanox/mlx4/cq.c:317:9,
> inlined from ‘mlx4_cq_alloc’ at drivers/net/ethernet/mellanox/mlx4/cq.c:394:10:
> ./include/linux/thread_info.h:228:4: error: call to ‘__bad_copy_from’ declared with attribute error: copy source size is too small
> make[6]: *** [scripts/Makefile.build:250: drivers/net/ethernet/mellanox/mlx4/cq.o] Error 1
> make: *** [Makefile:2010: .] Error 2
>
> I’ve also confirmed that this issue occurs even with the original, unmodified build.sh script, so it doesn’t seem to be caused by my changes.

Looks like the default config that the script produces enables lots of
stuff you don't have to care about. You may want to add the following
at the end of the file called "seed":

# CONFIG_MLX4_EN is not set

And yes, you need to use wm8650-mid.dtb, and also drop wm8505fb.patch

Best regards,
Alexey

[Alexey Charkov]

If you intend to use onboard wired Ethernet, you'll also need the
following at the end of "seed":

CONFIG_VIA_RHINE=y

and also this:

CONFIG_PINCTRL_WM8650=y

You'll probably also need to delete or comment out this whole block in build.sh:
https://github.com/lrussell887/Debian-for-WM8505-Netbooks/blob/3583567e00a54fe2e529bd9ec89f59ed5162aded/build.sh#L163-L168

Best regards,
Alexey

[Michel Gomes]

Thanks a lot for your detailed response, Alexey! I’ll go ahead and try the suggestions you mentioned, including modifying the seed file and adjusting the build.sh script.

I do have a quick question though, in the repository, I only see wm8650-mid.dts but not the compiled wm8650-mid.dtb. As I understand it, the .dts file is a Device Tree Source that describes the hardware layout (like addresses for peripherals, pins, etc.) so the kernel knows how to interface with the board. Is that correct?

To compile it into a .dtb, I used:

dtc -I dts -O dtb -o arch/arm/boot/dts/wm8650-mid.dtb arch/arm/boot/dts/wm8650-mid.dts
make -j"$(nproc)" zImage wm8650-mid.dtb
cat arch/arm/boot/zImage arch/arm/boot/dts/wm8650-mid.dtb > zImage_w_dtb

This is based on what I found in the script around https://github.com/lrussell887/Debian-for-WM8505-Netbooks/blob/3583567e00a54fe2e529bd9ec89f59ed5162aded/build.sh#L175-L176 . Just wanted to confirm that this is the right approach.

Thanks again for your help!

Best regards,
Michel

[Alexey Charkov]

On Wed, Apr 23, 2025 at 7:44 PM Michel Gomes <mic...@voltdata.info> wrote:
>
> Thanks a lot for your detailed response, Alexey! I’ll go ahead and try the suggestions you mentioned, including modifying the seed file and adjusting the build.sh script.
>
> I do have a quick question though, in the repository, I only see wm8650-mid.dts but not the compiled wm8650-mid.dtb. As I understand it, the .dts file is a Device Tree Source that describes the hardware layout (like addresses for peripherals, pins, etc.) so the kernel knows how to interface with the board. Is that correct?
>
> To compile it into a .dtb, I used:
>
> dtc -I dts -O dtb -o arch/arm/boot/dts/wm8650-mid.dtb arch/arm/boot/dts/wm8650-mid.dts
> make -j"$(nproc)" zImage wm8650-mid.dtb
> cat arch/arm/boot/zImage arch/arm/boot/dts/wm8650-mid.dtb > zImage_w_dtb

That's one way to do it, but if you simply replace all instances of
wm8505-ref.dtb with wm8650-mid.dtb inside build.sh it will do
everything for you (as the kernel's build system has all the necessary
recipes to compile .dtb files out of their corresponding .dts). The
first line calling dtc directly is redundant.

Best regards,
Alexey

[Michel Gomes]

While running the build.sh script from the repository, I encountered an issue at the following step:

log INFO "Bootstrapping rootfs"

multistrap -f multistrap.conf

At this point, the script failed due to missing GPG keys in the multistrap.conf file. The error was related to the line:

keyring=debian-archive-keyring

Following ChatGPT’s suggestion, I removed that line and manually imported the necessary keys by adding this to the script before running multistrap:

log INFO "Importing GPG keys"
gpg --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9 6ED0E7B82643E131 F8D2585B8783D481
gpg --export 0E98404D386FA1D9 6ED0E7B82643E131 F8D2585B8783D481 > debian-bookworm-archive-keys.gpg
mkdir -p rootfs/etc/apt/trusted.gpg.d
cp debian-bookworm-archive-keys.gpg rootfs/etc/apt/trusted.gpg.d/
log OK "GPG keys imported"

This allowed multistrap to proceed without key errors.

Does this seem like an acceptable workaround to you, or would you recommend a better approach?

I have a few beginner-level questions, I hope it's not too much to ask. I'm still learning, and I'd really appreciate some clarification:

1. What exactly is multistrap used for? I understand it's part of the build process, but I'm not entirely sure what its role is. Does it just prepare the root filesystem? Is it specific to Debian?
2. Does zImage automatically include the .dtb file? I'm a bit confused about this part, when building the kernel, do I need to manually append the device tree blob (.dtb) to the zImage, or is it handled automatically during the build process?
3. Since the linux-vtwm repo is a bit outdated, what would be necessary to maintain it for WM8xxx chips? If I wanted to keep the kernel tree updated and compatible with newer Debian userspace or toolchains, what parts of the repo or kernel should I be focusing on?
4. Is it possible to emulate this setup locally with QEMU? I was wondering if there’s any way to test this kernel and rootfs on my local machine using QEMU, just to avoid flashing the real device every time.

Thanks a lot in advance for your time and help!

[Michel Gomes]

Hi again,

I added the line # CONFIG_MLX4_EN is not set to the seed file in order to disable the Mellanox driver.

However, when running build.sh, I encountered an error during the "Building modules" step:

[INFO] Building modules
***
*** The present kernel configuration has modules disabled.
*** To use the module feature, please run "make menuconfig" etc.
*** to enable CONFIG_MODULES.
***
make: *** [Makefile:1953: modules] Error 1
[ERROR] Build error
[INFO] Cleaning up
Already on 'kernel'

To work around this, I tried commenting out the section in build.sh that merges configurations — as shown in this part of the script — because that also caused errors.

Here’s how I modified the script:

log INFO "Generating seeded default config"
cp ../seed .config
make olddefconfig
# log INFO "Creating default config seed"
# grep '=y' .config > .seed.defconfig
# log INFO "Merging with Debian config"
# scripts/kconfig/merge_config.sh -m .config.debian ../seed
# scripts/kconfig/merge_config.sh -m .config .seed.defconfig
# log INFO "Finalizing config"
# make olddefconfig
log OK "Config created"

But even after this change, it looks like CONFIG_MODULES is not being set properly, which prevents module compilation.

Do you have any suggestions on how to fix this or properly enable module support without breaking the rest of the build?

Thanks again!

[Michel Gomes]

I'm frustrated because i read in some old messages here on the forum and I've just realized another issue: my device only charges if it's wmt_scriptcmd and not script/scriptcmd.

[Alexey Charkov]

On Thu, Apr 24, 2025 at 7:41 AM Michel Gomes <mic...@voltdata.info> wrote:
>
> I'm frustrated because i read in some old messages here on the forum and I've just realized another issue: my device only charges if it's wmt_scriptcmd and not script/scriptcmd.
>
> On Wednesday, April 23, 2025 at 7:00:16 PM UTC-3 Michel Gomes wrote:
>>
>> Hi again,
>>
>> I added the line # CONFIG_MLX4_EN is not set to the seed file in order to disable the Mellanox driver.
>>
>> However, when running build.sh, I encountered an error during the "Building modules" step:
>>
>> [INFO] Building modules
>> ***
>> *** The present kernel configuration has modules disabled.
>> *** To use the module feature, please run "make menuconfig" etc.
>> *** to enable CONFIG_MODULES.

Not sure what's going on, because the Debian config for Marvell that
this script uses as the basis does include CONFIG_MODULES=y.

Did you do any further modification to the script? What's your
resulting .config?

>> To work around this, I tried commenting out the section in build.sh that merges configurations — as shown in this part of the script — because that also caused errors.

Did all the previous steps complete successfully? Especially the part
which downloads and unpacks a Debian config to serve as the basis. I
believe that one is quite fragile, because it uses lynx to find the
right file to download (which is not a standard tool and might not be
present on your system)

>> Here’s how I modified the script:
>>
>> log INFO "Generating seeded default config"
>> cp ../seed .config
>> make olddefconfig

This will result in an extremely limited kernel build and cause you
lots of pain after it boots, because modern distros require a number
of config options that are not present in the "seed" file but are
present in the Debian base config.

[...]

>> On Wednesday, April 23, 2025 at 5:28:05 PM UTC-3 Michel Gomes wrote:
>>>
>>> While running the build.sh script from the repository, I encountered an issue at the following step:
>>>
>>> log INFO "Bootstrapping rootfs"
>>> multistrap -f multistrap.conf
>>>
>>> At this point, the script failed due to missing GPG keys in the multistrap.conf file. The error was related to the line:
>>> keyring=debian-archive-keyring

Which distribution are you running this on? It might be that the
script was written with Debian in mind and not anything else (I
haven't used it myself, so can't be sure)

>>> Following ChatGPT’s suggestion, I removed that line and manually imported the necessary keys by adding this to the script before running multistrap:
>>>
>>> log INFO "Importing GPG keys"
>>> gpg --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9 6ED0E7B82643E131 F8D2585B8783D481
>>> gpg --export 0E98404D386FA1D9 6ED0E7B82643E131 F8D2585B8783D481 > debian-bookworm-archive-keys.gpg
>>> mkdir -p rootfs/etc/apt/trusted.gpg.d
>>> cp debian-bookworm-archive-keys.gpg rootfs/etc/apt/trusted.gpg.d/
>>> log OK "GPG keys imported"
>>>
>>> This allowed multistrap to proceed without key errors.
>>>
>>> Does this seem like an acceptable workaround to you, or would you recommend a better approach?

Looks reasonable.

>>> I have a few beginner-level questions, I hope it's not too much to ask. I'm still learning, and I'd really appreciate some clarification:
>>>
>>> What exactly is multistrap used for? I understand it's part of the build process, but I'm not entirely sure what its role is. Does it just prepare the root filesystem? Is it specific to Debian?

It's a tool to create a working Debian root filesystem from another
Linux machine. I personally only used debootstrap which does a similar
thing. There might be other alternatives too.

>>> Does zImage automatically include the .dtb file? I'm a bit confused about this part, when building the kernel, do I need to manually append the device tree blob (.dtb) to the zImage, or is it handled automatically during the build process?

No, a zImage is supposed to be usable on multiple devices, while .dtb
is specific to a particular device, so the standard kernel build
process doesn't merge them. In a "normal" setup the correct .dtb is
loaded by the bootloader and passed to the kernel at boot time. With
older bootloaders such as what we have on WonderMedia devices, a
correct .dtb needs to be manually appended to the zImage before you
pack it into a u-boot compatible uImage. The script does that for you
on line 176

>>> Since the linux-vtwm repo is a bit outdated, what would be necessary to maintain it for WM8xxx chips? If I wanted to keep the kernel tree updated and compatible with newer Debian userspace or toolchains, what parts of the repo or kernel should I be focusing on?

Do you need any particular functionality that is not present in
current mainline kernels? Have you tried building a kernel from
mainline sources to see if it works for your needs?

>>> Is it possible to emulate this setup locally with QEMU? I was wondering if there’s any way to test this kernel and rootfs on my local machine using QEMU, just to avoid flashing the real device every time.

You'd need to add WonderMedia emulation to the QEMU system emulator
code to be able to do that, which is somewhat involved. Definitely way
more involved than flashing the real device.

Best regards,
Alexey

[Michel Gomes]

Hey Alexey,

Thanks for the insights! You're probably right about the GPG key thing being related to my Ubuntu setup. The workaround I did seems to have gotten things moving for now.

That boot file naming issue is weird, right? But if "wmt_scriptcmd" is what it needs to boot, then "wmt_scriptcmd" it is! I've already changed the script to output that filename so I don't forget. Here's the part I modified in build.sh:

log INFO "Generating boot images"
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n linux -d $KERNEL_DIR/zImage_w_dtb boot/uzImage.bin
mkimage -A arm -O linux -T script -C none -a 1 -e 0 -n "script image" -d cmd boot/wmt_scriptcmd
log OK "Boot ready"

My seed file looks like this, and the options seem right for my WM8650:

# CONFIG_ARCH_MULTI_V7 is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_LOCALVERSION="-wm8505"
CONFIG_ARCH_WM8505=y
CONFIG_AEABI=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_PWM=y
CONFIG_PWM_VT8500=y
CONFIG_PINCTRL_WM8505=y
CONFIG_SERIAL_VT8500=y
CONFIG_SERIAL_VT8500_CONSOLE=y
CONFIG_FB=y
CONFIG_FB_VT8500=y
CONFIG_FB_WM8505=y
CONFIG_FB_WMT_GE_ROPS=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_VT8500=y
CONFIG_I2C=y
CONFIG_I2C_WMT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_HCD_PLATFORM=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_UHCI_PLATFORM=y
CONFIG_MTD=y
CONFIG_MTD_WMT_SFLASH=y
CONFIG_MMC=y
CONFIG_MMC_WMT=y
CONFIG_NET=y
CONFIG_NETDEVICES=y
CONFIG_VIA_VELOCITY=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042_DT=y
CONFIG_EXT4_FS=y
CONFIG_VIA_RHINE=y
CONFIG_PINCTRL_WM8650=y

# CONFIG_MLX4_EN is not set

Now, about that Mellanox driver... even with # CONFIG_MLX4_EN is not set in the seed, I was still running into issues. 

That's why I had to do that temporary fix by copying the modified cq.c file:

cp ../cq.c drivers/net/ethernet/mellanox/mlx4/cq.c

Definitely not ideal, but it allowed me to move forward.

I'll take a closer look at the .config file after running make olddefconfig to see if that Mellanox option is still somehow enabled. Maybe something else is pulling it in. I'll also re-examine the build script.
Thanks again for your help! I'll let you know if I find anything new.

[Michel Gomes]

and i trying to activate the built-in USB Wi-Fi adapter via the GPIO pins using wlan-gpio.service. However, after enabling the service with gpioset, I am unable to see the Wi-Fi interface when running ip link show.

Here are the steps I have tried so far:

1. Enabling the GPIO pin using the wlan-gpio.service with the gpioset command. The service is active, but the Wi-Fi interface does not show up.

2. Loading common Wi-Fi drivers, including brcmfmac, rtl8192cu, and ath9k via modprobe, but no interface is listed when checking with ip link show or nmcli device.

3. Checking the dmesg logs for any relevant output after activating the GPIO pin, but no messages related to the Wi-Fi device appear.

I suspect there may be a specific GPIO pin I need to activate or configure for the WM8650 version. Is there a different GPIO pin or configuration I should use to enable the internal USB Wi-Fi adapter?

Any suggestions or advice would be greatly appreciated!

[Alexey Charkov]

Different models used different GPIO pins to enable WiFi. You can either try them all, say, GPIO0~7, or try dumping the u-boot environment via fw_printenv inside Linux or printenv inside u-boot (then post it here)

--

You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/f2495230-7d72-4d6f-8963-30d5cdb8d642n%40googlegroups.com.

[Michel Gomes]

I created a Bash script to cycle through GPIO pins 0 to 7:

#!/bin/bash
for i in {0..7}; do
    echo $i
    gpioset gpiochip0 $i=1
    sleep 5
    ip a | grep wlan
    echo "--------------------------"
done

However, no wlan interface appears, and the command gpioset gpiochip1 2=1 returned a "device or resource busy" error. I believe this might be due to a configuration in the wlan-gpio.service (I found this link for reference https://github.com/lrussell887/Debian-for-WM8505-Netbooks/blob/master/ship/etc/systemd/system/wlan-gpio.service ).

I also tried using u-boot-tools and installed it with:

apt install u-boot-tools

However, it said that the /etc/fw_env.config file was not configured. Following a suggestion, I created the file with the following content:

/dev/mtd0 0x0000 0x1000

But when I tried to check the U-Boot environment, I noticed that I don’t have /dev/mtd0. When I run ls /dev/, I only see the following devices:

    mapper/ mem mmcblk0 mmcblkp1 mmcblkp2 mqueue/

Any advice or suggestions on what I might be missing would be greatly appreciated.

Thank you!

[Michel Gomes]

my  typo the command is gpioset gpiochip0 2=1 and also returned a "device or resource busy" error.

[Alexey Charkov]

Two suggestions:

1. Try also setting those GPIOs to output 0, as your device might have
an active-low logic
2. If you have serial console access, you could also type printenv at
the u-boot prompt, and it will show various vendor-specific variables,
including the GPIO configuration to enable power to the WiFi module

Best regards,
Alexey

> To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/59d9f0ad-1922-4fcc-8174-0b5fffea1f5an%40googlegroups.com.

[Michel Gomes]

I tried setting the GPIOs to output 0 using gpioset, but it didn’t help. This image lists the GPIOs.
 
Unfortunately, I’m not able to access the U-Boot console :(

[Alexey Charkov]

On Sat, 26 Apr 2025 at 08:35, Michel Gomes <mic...@voltdata.info> wrote:

I tried setting the GPIOs to output 0 using gpioset, but it didn’t help. This image lists the GPIOs.

Well that’s a bit weird. Does nothing at all change in dmesg or lsusb output as you toggle those?

It might appear on the USB bus, but the driver might be missing, or its firmware might be not installed, so please confirm if anything makes noise in either of those two places first.

Do you have the serial flash controller driver compiled and loaded? It should provide mtd* device nodes.

Mind posting your resulting device tree, such as via `dtc -I fs -O dts /proc/device-tree`?

Best,

Alexey

[Michel Gomes]

Hi,

Thanks a lot for the suggestions.

In figure_1.png, you can see the output of lsusb after toggling the GPIOs — it remains exactly the same. The last device connected is a USB keyboard that I physically plugged in to help with typing.

In lsmod.png, I ran both lsmod and ls /dev/ commands, searching for any mtd devices, but nothing was found. There’s no /dev/mtd* available.

I also ran dtc -I fs -O dts /proc/device-tree to dump the device tree.

I am sending the resulting file as device-tree-output.txt, but also attached is pre-dtc_command.png, which shows some warnings that appeared when running the dtc command.

Thank you again for your help!

[Alexey Charkov]

On Mon, 28 Apr 2025 at 15:52, Michel Gomes <mic...@voltdata.info> wrote:

Hi,

Thanks a lot for the suggestions.

In figure_1.png, you can see the output of lsusb after toggling the GPIOs — it remains exactly the same. The last device connected is a USB keyboard that I physically plugged in to help with typing.

In lsmod.png, I ran both lsmod and ls /dev/ commands, searching for any mtd devices, but nothing was found. There’s no /dev/mtd* available.

I also ran dtc -I fs -O dts /proc/device-tree to dump the device tree.

Alright, there is indeed no node for the serial flash controller. You’ll need to apply something along the lines of this patch but to wm8650.dtsi instead of wm8880.dtsi:

https://github.com/lrussell887/linux-vtwm/commit/91f6d587ea8e4cf4621eb8fc133e597cf6966382

Clock parameters appear to be the same for WM8650 as listed in that patch.

I am sending the resulting file as device-tree-output.txt, but also attached is pre-dtc_command.png, which shows some warnings that appeared when running the dtc command.

Nothing major there, no need to worry about those.

Best regards,

Alexey

[Michel Gomes]

From what I understand, applying this patch to wm8650.dtsi would mainly involve adding the sf@d8002000 node and the clksf: sf clock definition inside the clocks section under pmc@d8130000, as shown in the green parts of the patch. right ?

[Alexey Charkov]

On Tue, 29 Apr 2025 at 02:36, Michel Gomes <mic...@voltdata.info> wrote:

From what I understand, applying this patch to wm8650.dtsi would mainly involve adding the sf@d8002000 node and the clksf: sf clock definition inside the clocks section under pmc@d8130000, as shown in the green parts of the patch. right ?

Yes. You may also try to simply replace the filename being patched within the “diff” line and it might just work. Or edit wm8650.dtsi manually - whatever sounds easier to you.

Best,

Alexey

[Michel Gomes]

It seems the issue persists. I've attached the device-tree log for review.

Am I doing something wrong?

[Alexey Charkov]

The device tree looks good to me.

Do you now see any /dev/mtd* device nodes? It should have given you four MTD partitions, two of which contain redundant copies of U-boot environment variables.

--

You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/69a968bc-f26b-41eb-98c6-7a621d4cca70n%40googlegroups.com.

[Michel Gomes]

nothing yet

[Alexey Charkov]

Something’s quite wrong here. Could you please post the contents of your resulting /proc/config.gz and full dmesg?

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/2c27cd45-423b-43ce-9566-da6bba8eea7bn%40googlegroups.com.

[Michel Gomes]

Hi, the file /proc/config.gz does not exist on the system.
Please find the dmesg log attached

Could you explain what exactly we’re trying to find here — like I’m 12 years old? (LOL) XD

[Alexey Charkov]

Okay, here it is in dmesg:

[ 0.870000] wmt-sf d8002000.sf: Unknown flash id (00010212)
[ 0.880000] wmt-sf d8002000.sf: Failed to initialize SF hardware
[ 0.880000] wmt-sf: probe of d8002000.sf failed with error -5

The serial flash controller doesn’t recognize your SPI flash chip - need to tell it about it.

Once we get the serial flash controller up and running we can read out U-boot environment variables which WonderMedia used in their somewhat hacky pre-devicetree setup to tell the system which GPIOs need to be put into which configuration for various stuff to work. 

WiFi power is one of those things controlled by a GPIO pin, so being able to read MTD partitions will help us know which exact pin to set to which state on your particular machine for the USB WiFi adapter to show up.

Best,

Alexey

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/9c2519a4-a972-40fa-87d5-79f7f266f338n%40googlegroups.com.

[Alexey Charkov]

Please try the following patch. It should get your flash chip
recognized by the driver (though the driver probably needs conversion
to standard JEDEC probing of flash chips - later)

diff --git a/drivers/mtd/devices/wmt_sflash.c b/drivers/mtd/devices/wmt_sflash.c
index ff6de557837d..2e5b94b6daff 100644
--- a/drivers/mtd/devices/wmt_sflash.c
+++ b/drivers/mtd/devices/wmt_sflash.c
@@ -82,6 +82,7 @@
*/

/* Spansion */
+#define SPAN_SL004A 0x0212 /* 512 KB */
#define SPAN_FL016A 0x0214 /* 2 MB */
#define SPAN_FL064A 0x0216 /* 8 MB */

@@ -131,6 +132,7 @@ struct wmt_flash_id {
};

static struct wmt_flash_id flash_ids[] = {
+ { SF_ID(MFR_SPANSION, SPAN_SL004A), 512 },
{ SF_ID(MFR_SPANSION, SPAN_FL016A), 2048 },
{ SF_ID(MFR_SPANSION, SPAN_FL064A), 8192 },
{ SF_ID(MFR_EON, EON_25P16), 2048 },

[Michel Gomes]

Apparently it worked, what are the next steps?

[Michel Gomes]

used the commands
strings /dev/mtd1

and these are the results.

[Alexey Charkov]

Okay, here is the line we’re looking for:

wmt.gpo.wifi=6:1:6:d8110040:d8110080:d81100C0

This translates into:

GPIO name=6

active=high

Register bit=6

GPIO enable control register=0xd8110040

GPIO output enable register=0xd8110080

GPIO output data register=0xd81100C0

So you need to request GPIO 6 as function GPIO (or just enabled, as far as gpiod is concerned), direction out, value 1. Try setting those with gpioset, then we can verify if it did its job by dumping the three registers listed above using `busybox devmem`

Once done, your WiFi module should power up and appear on the bus (usually USB 2.0 on these machines, but technically it could also be SDIO)

Best regards,

Alexey

To view this discussion visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/f4634a45-42bd-49b9-9fe1-eacb259a5c51n%40googlegroups.com.