Getting the latest kernel running on a WM8650 laptop in 2020

[Brigham Campbell]

Hey, folks! Not sure if anyone is still lurking around here, but I'm trying to get the latest kernel up and running on this WM8650 laptop.

I've configured the kernel to target the WM8650. Aside from that, it's default. When I go to load it up, I get no output on the UART peripheral or the screen. My theory is that U-Boot 1.1.4 isn't passing the device tree to the kernel correctly.

I'm looking into workarounds and fixes now... I might have to figure out a way to update U-Boot to a more recent version (yikes!). I'm open to suggestions.

Thanks,

Brigham

[Alexey Charkov]

Hey Brigham!

Would you mind posting your U-boot script and kernel .config?

I'm afraid you won't be able to update u-boot here, as no one bothered porting mainline u-boot to these devices and it doesn't sound like a trivial thing to do. So you get to resort to the "appended DTB" scheme as the only viable workaround.

Best,

Alexey

вт, 29 сент. 2020 г. в 11:31, Brigham Campbell <m...@brighamcampbell.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 on the web visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/1227da85-3bb6-4cf9-82e2-6793c9e0da76n%40googlegroups.com.

[J T Dsouza]

I have several WM8650 tablets. The last kernel I compiled and ran was 3.16.04. Would be great to upgarde to a new kernel.

To view this discussion on the web visit https://groups.google.com/d/msgid/vt8500-wm8505-linux-kernel/CABjd4Yzb50Hh%2Bw10XK_Tc1avon4kFDk2wZjjGnQE7mKL6mrm%3DA%40mail.gmail.com.

[Brigham Campbell]

Wow, I didn't really expect a response... Definitely not a response 7 minutes after my first message. This is exciting!

Anyways, here's a link to the .config I've generated. As I said, it's pretty much all default. For the "appended DTB" workaround, do I need to change a config option? Does that change the location the kernel expects the device tree to be at? If I understand correctly, it typically expects it to be in r2 on startup.

Regarding a U-Boot script, I've just been loading the kernel into memory, loading the .dtb into memory a little after the kernel, then calling `bootm $kernel_addr - $dtb_addr`. However, looking at the code for U-Boot 1.1.4, it looks like formatting a bootm call that way won't really work unless we're on a more recent version of U-Boot. I'll type up a U-Boot script if it's useful, but I can tell you right now that I'm doing something wrong with making bootm pass in the device tree correctly.

Thanks so much!

Brigham

[Alexey Charkov]

вт, 29 сент. 2020 г. в 12:01, Brigham Campbell <m...@brighamcampbell.com>:

>
> Wow, I didn't really expect a response... Definitely not a response 7 minutes after my first message. This is exciting!
>
> Anyways, here's a link to the .config I've generated. As I said, it's pretty much all default. For the "appended DTB" workaround, do I need to change a config option? Does that change the location the kernel expects the device tree to be at? If I understand correctly, it typically expects it to be in r2 on startup.

It's enabled in your config:
CONFIG_ARM_APPENDED_DTB=y

WMT stock u-boot is so old it doesn't know about DTB at all. So it can
only load the kernel and initrd, and you need to do something like
this before making your uImage:
cat zImage your_dtb.dtb > zImage_with_dtb
mkimage [bla-bla...]

See the Wiki page here:
https://github.com/linux-wmt/linux-vtwm/wiki/Build-the-source

> Regarding a U-Boot script, I've just been loading the kernel into memory, loading the .dtb into memory a little after the kernel, then calling `bootm $kernel_addr - $dtb_addr`. However, looking at the code for U-Boot 1.1.4, it looks like formatting a bootm call that way won't really work unless we're on a more recent version of U-Boot. I'll type up a U-Boot script if it's useful, but I can tell you right now that I'm doing something wrong with making bootm pass in the device tree correctly.

Most likely your bootm command doesn't work at all, as this old u-boot
version doesn't support the three-parameter syntax. Thus your blank
screen :)

By the way, you'll likely want to change these to make the kernel do
meaningful stuff:
# CONFIG_AEABI is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_PINCTRL_VT8500 is not set
# CONFIG_PINCTRL_WM8505 is not set
# CONFIG_PINCTRL_WM8650 is not set

Also check that you have something like 'rootwait' in your kernel
command line, because both USB and SD take time to initialize and find
the root filesystem.

Let me know if it works!

Best,
Alexey

[Brigham Campbell]

Ah, yes... That seems to get me much further than before! I was confused about how to include the device tree binary... It looks like it's much more simple than I expected! Hahah

Now I have the kernel booting with the U-Boot 1.1.4 script which I've appended to the bottom of this message. It outputs the kernel boot sequence messages to the screen. After loading a couple modules and starting up a little, it panics:

VFS: Cannot open root device "(null)" or unknown-block(0,0)

After testing a couple things, I wonder if the kernel isn't receiving the arguments for some reason... I would expect the kernel panic to output "Cannot open root device 'PARTUUID=912f9265-02' or..." instead of '(null)'. Also, even though I'm passing in `panic=3`, Linux doesn't restart the device 3 seconds after it panics.

Any ideas? I'll keep fiddling...

display init force

mmcinit 0

textout -1 -1 \"Loading kernel...\" FFFFFF

fatload mmc 0 0 uzImage.bin

textout -1 -1 \"Starting Linux...\" FFFFFF

setenv bootargs 'mem=214M root=PARTUUID=912f0265-02 noinitrd rw rootfstype=ext4 rootwait panic=3'

bootm 0

[Alexey Charkov]

пт, 2 окт. 2020 г. в 14:51, Brigham Campbell <m...@brighamcampbell.com>:

>
> Ah, yes... That seems to get me much further than before! I was confused about how to include the device tree binary... It looks like it's much more simple than I expected! Hahah

Porting recent U-boot versions to get proper DT handling would have
been awesome, but that's quite an effort unfortunately. As you can
see, there's not much developer attention going into these beasts in
the last 6-7 years ;-)

> Now I have the kernel booting with the U-Boot 1.1.4 script which I've appended to the bottom of this message. It outputs the kernel boot sequence messages to the screen. After loading a couple modules and starting up a little, it panics:
>
> VFS: Cannot open root device "(null)" or unknown-block(0,0)
>
> After testing a couple things, I wonder if the kernel isn't receiving the arguments for some reason... I would expect the kernel panic to output "Cannot open root device 'PARTUUID=912f9265-02' or..." instead of '(null)'. Also, even though I'm passing in `panic=3`, Linux doesn't restart the device 3 seconds after it panics.
>
> Any ideas? I'll keep fiddling...
>
> display init force
> mmcinit 0
> textout -1 -1 \"Loading kernel...\" FFFFFF
> fatload mmc 0 0 uzImage.bin
> textout -1 -1 \"Starting Linux...\" FFFFFF
> setenv bootargs 'mem=214M root=PARTUUID=912f0265-02 noinitrd rw rootfstype=ext4 rootwait panic=3'

I personally never got the PARTUUID-style specification to work on
these, although there doesn't seem to be any valid reason for it not
to. Try specifying the device name directly, such as
'root=/dev/mmcblk0p3' (change the last "3" to the partition number of
your root fs on the SD card)

You can also use 'mem=256M' to use the full memory. That 214M thing
was needed for the stock kernels to reserve part of the memory for the
frame buffer, but upstream kernels allocate that separately now.

Best,
Alexey

[Brigham Campbell]

Sorry, I should've said I've tried both formats. root=/dev/mmcblk0p2 doesn't seem to work either.

Is there any way I can verify that the kernel is receiving the parameters I'm passing in? Even though I'm passing in 'panic=3', it doesn't restart automatically after the kernel panics...

Thanks again! It's really cool that you would help me get Linux up on such an old device!

[Alexey Charkov]

пт, 2 окт. 2020 г. в 15:10, Brigham Campbell <m...@brighamcampbell.com>:

>
> Sorry, I should've said I've tried both formats. root=/dev/mmcblk0p2 doesn't seem to work either.
>
> Is there any way I can verify that the kernel is receiving the parameters I'm passing in? Even though I'm passing in 'panic=3', it doesn't restart automatically after the kernel panics...

Good point. Try flipping this option in your config:
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set

Or you can try building the cmdline directly into the kernel image here:
CONFIG_CMDLINE=""

> Thanks again! It's really cool that you would help me get Linux up on such an old device!

You're most welcome :)

[Adrien Destugues]

>> Ah, yes... That seems to get me much further than before! I was confused about how to include the
>> device tree binary... It looks like it's much more simple than I expected! Hahah
>
> Porting recent U-boot versions to get proper DT handling would have
> been awesome, but that's quite an effort unfortunately. As you can
> see, there's not much developer attention going into these beasts in
> the last 6-7 years ;-)

Hi there,

I've not been much around lately for various reasons, the most recent one being that I had misplaced the power supply for my own WM8880 device (but I just found it yesterday).

I'm now looking into u-boot a bit as my interest is mainly in running non-Linux things, and a more modern version of u-boot would be of great help.

However, there doesn't seem to be a way to test changes without reflashing uboot and it's quite likely that I'll brick my device while experimenting with that.

Is there some documented recovery mode somewhere that would allow me to get out of that situation? Preferrably without having to repeatedly disassemble the device to reach the serial eeprom to reflash it :) (but I guess I could just have a hole in the case to make that more easily reachable, if all else fails...)

Also, is it even possible to build the existing uboot from sources? Would the one from the APC Rock II work on other devices or is there a better source to start from?

--
Adrien.

[Alexey Charkov]

пт, 2 окт. 2020 г. в 16:23, Adrien Destugues <pulko...@pulkomandy.tk>:

>
> >> Ah, yes... That seems to get me much further than before! I was confused about how to include the
> >> device tree binary... It looks like it's much more simple than I expected! Hahah
> >
> > Porting recent U-boot versions to get proper DT handling would have
> > been awesome, but that's quite an effort unfortunately. As you can
> > see, there's not much developer attention going into these beasts in
> > the last 6-7 years ;-)
>
> Hi there,
>
> I've not been much around lately for various reasons, the most recent one being that I had misplaced the power supply for my own WM8880 device (but I just found it yesterday).
>
> I'm now looking into u-boot a bit as my interest is mainly in running non-Linux things, and a more modern version of u-boot would be of great help.
>
> However, there doesn't seem to be a way to test changes without reflashing uboot and it's quite likely that I'll brick my device while experimenting with that.
>
> Is there some documented recovery mode somewhere that would allow me to get out of that situation? Preferrably without having to repeatedly disassemble the device to reach the serial eeprom to reflash it :) (but I guess I could just have a hole in the case to make that more easily reachable, if all else fails...)

I think you can chain-load your new u-boot from the existing u-boot by
loading the raw binary into memory and jumping to its entry point, but
there isn't any recovery mode that I know of. Might be good to dump
the SPI flash chip content as a backup somewhere and then solder a
socket in its place if you are really inclined to tinker with the
bootloader :)

> Also, is it even possible to build the existing uboot from sources? Would the one from the APC Rock II work on other devices or is there a better source to start from?

Never tried, frankly. The version difference is so huge though that it
might be easier to just start with a clean upstream source tree, and
then add bits of required code on top of it - looking at WMT sources
selectively rather than directly copying them across.

Note that u-boot is the second stage bootloader here (the first thing
that runs upon powerup is the closed-source w-load), so you shouldn't
really need to deal with low-level stuff such as memory controller
initialization. Pinctrl, serial, graphics and SD should be more
straightforward to add to upstream sources, given that there are
working upstream Linux drivers for them.

Best,
Alexey

[Brigham Campbell]

Hmm... I tried flipping that option and it didn't work with it enabled or disabled... I'm not sure why, though. I included "panic=3" in the CONFIG_CMDLINE option, but it still doesn't reboot after a kernel panic. This indicates to me that the kernel isn't getting the parameters either from U-Boot or when they're compiled into the kernel... Very strange. Maybe the "panic" boot parameter is broken because of my configuration somehow?

I've updated the .config

Perhaps it would also be useful to get the kernel outputting the boot sequence to serial instead of the screen. That way, I can copy and paste the output for all to inspect. I'll check the config options to see if I can do that easily.

[Adrien Destugues]

> I think you can chain-load your new u-boot from the existing u-boot by
> loading the raw binary into memory and jumping to its entry point, but
> there isn't any recovery mode that I know of.

Well, that's the first thing I'd try (and if I could do that, maybe I won't
even bother reflashing the SPI and just boot this way), but u-boot FAQ
insists that this is a bad idea and they don't want to document it. Not
that it would stop me, but it means I need to spend more time figuring it out.

>> Also, is it even possible to build the existing uboot from sources? Would the one from the APC Rock
>> II work on other devices or is there a better source to start from?
>
> Never tried, frankly. The version difference is so huge though that it
> might be easier to just start with a clean upstream source tree, and
> then add bits of required code on top of it - looking at WMT sources
> selectively rather than directly copying them across.

That would be the second step, but I would like to first make sure that
I'm able to reflash uboot built from "known good" sources, otherwise there
are too many unknowns in the process (especially without any kind of jtag
or similar debugging for the early boot process).

>
> Note that u-boot is the second stage bootloader here (the first thing
> that runs upon powerup is the closed-source w-load), so you shouldn't
> really need to deal with low-level stuff such as memory controller
> initialization. Pinctrl, serial, graphics and SD should be more
> straightforward to add to upstream sources, given that there are
> working upstream Linux drivers for them.

That depends on how much work w-load actually does. But yes I assume the most
low-level (and most difficult to debug) things will be already done.

I guess I'll first look into how to load another uboot version, that on its own could already be useful.

--
Adrien.

[Alexey Charkov]

пт, 2 окт. 2020 г. в 16:44, Brigham Campbell <m...@brighamcampbell.com>:

>
> Hmm... I tried flipping that option and it didn't work with it enabled or disabled... I'm not sure why, though. I included "panic=3" in the CONFIG_CMDLINE option, but it still doesn't reboot after a kernel panic. This indicates to me that the kernel isn't getting the parameters either from U-Boot or when they're compiled into the kernel... Very strange. Maybe the "panic" boot parameter is broken because of my configuration somehow?
>
> I've updated the .config

Maybe enable all the others too, just in case?

# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER is not set
# CONFIG_CMDLINE_FROM_BOOTLOADER is not set
# CONFIG_CMDLINE_EXTEND is not set

> Perhaps it would also be useful to get the kernel outputting the boot sequence to serial instead of the screen. That way, I can copy and paste the output for all to inspect. I'll check the config options to see if I can do that easily.

Should be something like 'console=ttyWMT0,115200n8 earlyprintk' - but
for that you need command line parameters to work :)

[Brigham Campbell]

No, it looks like fiddling around with the others doesn't help either... This is a strange issue.

I'm starting to wonder if it really is because the kernel parameters aren't being passed in. Is there any way I could test it? Maybe a parameter that would force the kernel to panic before even trying to boot?

[Brigham Campbell]

Oh! And I'm getting a warning near the end of kernel compilation. I'm not sure which version of my .config introduced it or if it's been there all along. I can test the earlier configs if the error is of interest:

WARNING: modpost: vmlinux.o (.noinit): unexpected non-allocatable section.

Did you forget to use "ax"/"aw" in a .S file?

Note that for example <linux/init.h> contains

section definitions for use in .S files.

[Alexey Charkov]

пт, 2 окт. 2020 г. в 23:59, Brigham Campbell <m...@brighamcampbell.com>:

>
> Oh! And I'm getting a warning near the end of kernel compilation. I'm not sure which version of my .config introduced it or if it's been there all along. I can test the earlier configs if the error is of interest:
>
> WARNING: modpost: vmlinux.o (.noinit): unexpected non-allocatable section.
> Did you forget to use "ax"/"aw" in a .S file?
> Note that for example <linux/init.h> contains
> section definitions for use in .S files.

This looks weird. Maybe backup your .config and do make mrproper on
the whole tree, then rebuild for a good measure?

[Brigham Campbell]

Alright, I'm rebuilding the source after a `make mrproper` now. I'll try loading up the resulting kernel tomorrow to see what it does. (Looks like the build just finished... I still get the same warning. I can package up the config and the compile output to share here if that would be of any interest. That aside, it must be something with my config. Is there any mailing list which I might be able to ask for more details on this warning? It's very possible that it's not even related to the issue of no boot arguments, but I wouldn't really know...)

It does kind of seem like we're grasping at straws here, though. It's strange to me that we're getting so much trouble when simply trying to pass in boot arguments... Maybe I should try building an earlier kernel? One that we know was working for this device?

Also, I think I've said this before, but for the sake of clarity, it should be noted that I'm building the mainline 5.8.0 kernel. Torvalds's repo.

Latest .config I'm using available here: https://gist.github.com/Xeyler/f6d6411d3b044767ceb07f24ab5d3629

[Alexey Charkov]

пн, 5 окт. 2020 г. в 11:51, Brigham Campbell <m...@brighamcampbell.com>:

>
> Alright, I'm rebuilding the source after a `make mrproper` now. I'll try loading up the resulting kernel tomorrow to see what it does. (Looks like the build just finished... I still get the same warning. I can package up the config and the compile output to share here if that would be of any interest. That aside, it must be something with my config. Is there any mailing list which I might be able to ask for more details on this warning? It's very possible that it's not even related to the issue of no boot arguments, but I wouldn't really know...)

The thing is that ARMv5 doesn't seem to be that widely tested these
days at all, let alone anything that might be specific to the
multilevel combo of workarounds we have to use on our devices to get
them running.

The proper way would be of course to start with a known-good toolchain
that builds a known-working kernel version in a known-working config,
then iteratively update the parts you care about. The problem might
well be in each of these three (and perhaps more).

So:
1. What's the toolchain you're using? Is it a distro standard
cross-compilation package - if so, which distro and version? Have you
ever built other kernels for this architecture with it successfully?
2. Have you tried earlier kernel versions? The latest one I've tried
in any shape or form was the one here:
https://github.com/linux-wmt/linux-vtwm, branch testing-alchark
3. Have you tried any of the configs people posted for WM8650 in this
group before?

> It does kind of seem like we're grasping at straws here, though. It's strange to me that we're getting so much trouble when simply trying to pass in boot arguments... Maybe I should try building an earlier kernel? One that we know was working for this device?

Have a look through the earlier threads here. At least some of the 4.x
kernels should have worked on WM8650 - maybe use those as the basis to
reduce the number of moving parts in your setup.

> Also, I think I've said this before, but for the sake of clarity, it should be noted that I'm building the mainline 5.8.0 kernel. Torvalds's repo.

Technically, it should work. But you can never know :)

> Latest .config I'm using available here: https://gist.github.com/Xeyler/f6d6411d3b044767ceb07f24ab5d3629

Nothing immediately worrying here, but for the sake of conservatism
I'd probably change these:
CONFIG_EMBEDDED=y (risk of disabling some obscure option that's needed
for a proper user-facing system)
# CONFIG_VFP is not set (risk of something in your root fs issuing fpu
instructions and crashing)
# CONFIG_VIA_RHINE is not set (your ethernet adapter depends on this)
# CONFIG_EXT4_FS_POSIX_ACL is not set (recent distros may use ACLs
extensively within the root fs - e.g. Fedora does)

I also usually disable debug options that I don't plan on deliberately
using, as debug codepaths might introduce extra problems / noise of
their own, so removing them may make life easier unless you need some
specific debug functionality.

It's often also easier to try booting with a built-in known-working
recovery initramfs. That way you can at least poke around and see
which devices got recognized by the kernel, what's the cmdline it got,
etc. Much better than shooting in the dark without access to the
console.

By the way, you still don't list the console device in your cmdline -
is that intentional?
CONFIG_CMDLINE="mem=256M root=/dev/mmcblk0p2 noinitrd rw
rootfstype=ext4 rootwait boot_delay=500"

Best,
Alexey

[Brigham Campbell]

I'm using arm-none-eabi-gcc 10.2.0-1 from the Arch Linux package repo. Here's `arm-none-eabi-gcc --version`: 
arm-none-eabi-gcc (Arch Repository) 10.2.0

To be honest, I haven't successfully cross-compiled any kernel... at all before! This is the first time I've tried. I've compiled kernels for x86 on x86. But even then, I don't think I've ever compiled a kernel for a system other than the one I was compiling the kernel on. I'm definitely a beginner in this regard (If you couldn't tell by now. hahah). For this reason, I imagine building a kernel with a known working config/kernel version for this device would probably be helpful for me. I'll take a look through the older threads here.

At the moment, if I understand correctly, I'm not trying to boot with an initrd or an initramfs. If I wanted to boot with an initramfs, could I build that into the kernel or should I load it into memory with u-boot? What if I wanted to use an initrd instead? Sorry, I'm not very familiar with the startup sequence of Linux and how an initrd or initramfs relate to it. If you could point me towards some text/documentation, I'd really appreciate it!

I haven't updated the boot script with the serial console yet because I'm not sure that the boot parameters are even working yet... But I guess I might as well, right? Here's the latest:

display init force

mmcinit 0

textout -1 -1 \"Loading kernel...\" FFFFFF

fatload mmc 0 0 uzImage.bin

textout -1 -1 \"Starting Linux...\" FFFFFF

setenv bootargs 'mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext4 rootwait console=ttyWMT0,115200n8 earlyprintk'

bootm 0

Thanks for your help! There's a lot I don't know, but I hope I can learn just enough to pull this off...

[Alexey Charkov]

вт, 6 окт. 2020 г. в 03:10, Brigham Campbell <m...@brighamcampbell.com>:

>
> I'm using arm-none-eabi-gcc 10.2.0-1 from the Arch Linux package repo. Here's `arm-none-eabi-gcc --version`:
> arm-none-eabi-gcc (Arch Repository) 10.2.0

Sounds safe, although it might be helpful to also try older stable
compiler versions (perhaps later - one thing at a time).

> To be honest, I haven't successfully cross-compiled any kernel... at all before! This is the first time I've tried. I've compiled kernels for x86 on x86. But even then, I don't think I've ever compiled a kernel for a system other than the one I was compiling the kernel on. I'm definitely a beginner in this regard (If you couldn't tell by now. hahah). For this reason, I imagine building a kernel with a known working config/kernel version for this device would probably be helpful for me. I'll take a look through the older threads here.

It's alright, we've all been there :-)

> At the moment, if I understand correctly, I'm not trying to boot with an initrd or an initramfs. If I wanted to boot with an initramfs, could I build that into the kernel or should I load it into memory with u-boot? What if I wanted to use an initrd instead? Sorry, I'm not very familiar with the startup sequence of Linux and how an initrd or initramfs relate to it. If you could point me towards some text/documentation, I'd really appreciate it!

There frankly isn't any real reason to use initrd instead of initramfs
here - the latter is just better no matter how you look at it. I
prefer to compile mine directly into the kernel image, because then
you don't have to trust the bootloader to load and pass it correctly.

Something like Buildroot with a statically linked busybox would
probably be my first choice for debugging/poking purposes. Use
Buildroot to create the cpio initramfs archive, then include it into
your kernel build through the respective kernel config option.

> I haven't updated the boot script with the serial console yet because I'm not sure that the boot parameters are even working yet... But I guess I might as well, right? Here's the latest:
>
> display init force
> mmcinit 0
> textout -1 -1 \"Loading kernel...\" FFFFFF
> fatload mmc 0 0 uzImage.bin
> textout -1 -1 \"Starting Linux...\" FFFFFF
> setenv bootargs 'mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext4 rootwait console=ttyWMT0,115200n8 earlyprintk'
> bootm 0

Looks good to me. Still no output on the serial port?

Best,
Alexey

[Brigham Campbell]

> Something like Buildroot with a statically linked busybox would
> probably be my first choice for debugging/poking purposes. Use
> Buildroot to create the cpio initramfs archive, then include it into
> your kernel build through the respective kernel config option.

Ok, I configured Buildroot to create a cpio initramfs with busybox. It's
building now. Apparently, Buildroot doesn't quite support 5.8.0 kernel
headers yet, so I selected 5.7.x. That's not likely to cause any issues,
is it? I've heard of Buildroot before, but this is my first time using
it.

> Looks good to me. Still no output on the serial port?

Nope, no serial output with those arguments (strangely enough). I've
seen "ttyWMT0" fly by in the initial kernel output, so it seems to be
enumerating the serial port... I guess this indicates that the kernel
still isn't getting the arguments for some reason? Hopefully the cpio
initramfs can shed some light on this one.

Thanks,
Brigham

[Brigham Campbell]

Oh, now this is exciting! I built the resulting cpio into the kernel and
rebuilt the kernel. Now after booting, I'm dropped into a busybox shell!
I guess my first Buildroot configuration worked... If that isn't a
miracle, then I don't know what is.

Now, with the busybox shell, I can mount the ext4 partition on the SD
card (the one which I'm trying to pass into the kernel's `root`
parameter). It looks like there are no issues with it... I can view the
files (and presumably write to them. I'll test this).

Interestingly, when I `cat /proc/cmdline`, a blank line is printed. I
guess this confirms our suspicions that the kernel parameters are
getting dropped somewhere along the line. Is there any way I can modify
them with busybox? I would assume not, but I'll try it.

This is awesome!

Thanks,
Brigham

[Brigham Campbell]

It looks like I can read and write the ext4 partition which means I can
now save the kernel messages via `dmesg` for all to see! I wouldn't
really know what to look for here, but I can see that devices are being
enumerated and there are no glaring issues. The warning near the
beginning is kind of interesting, but what's most interesting to me is
the empty kernel command line:

[ 0.000000] Kernel command line:

(I know, I probably shouldn't be building the kernel as root... I run
`make zImage` as a part of a script which copies the kernel to my SD
card... Which requires root privileges because I can't be bothered to
set up my Arch Linux installation properly)

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.8.0 (root@mystery-machine) (arm-none-eabi-gcc (Arch Repository) 10.2.0, GNU ld (GNU Binutils) 2.35) #5 Mon Oct 5 23:55:37 MDT 2020
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Wondermedia WM8650-MID Tablet
[ 0.000000] OF: fdt: No chosen node found, continuing without
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 64 MiB at 0x04000000
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] On node 0 totalpages: 32768
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32768 pages, LIFO batch:7
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line:
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 49652K/131072K available (9405K kernel code, 814K rwdata, 2684K rodata, 1116K init, 271K bss, 15884K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] vt8500-irq: Added interrupt controller
[ 0.000000] vt8500-irq: Added interrupt controller
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:242 __irq_startup+0xa0/0xac
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0 #5
[ 0.000000] Hardware name: VIA/Wondermedia SoC (Device Tree Support)
[ 0.000000] [<c00159c0>] (unwind_backtrace) from [<c0012f08>] (show_stack+0x10/0x14)
[ 0.000000] [<c0012f08>] (show_stack) from [<c001ffcc>] (__warn+0xc0/0xf4)
[ 0.000000] [<c001ffcc>] (__warn) from [<c0020384>] (warn_slowpath_fmt+0x74/0xa4)
[ 0.000000] [<c0020384>] (warn_slowpath_fmt) from [<c006253c>] (__irq_startup+0xa0/0xac)
[ 0.000000] [<c006253c>] (__irq_startup) from [<c0062584>] (irq_startup+0x3c/0x5c)
[ 0.000000] [<c0062584>] (irq_startup) from [<c005f2a8>] (enable_irq+0x44/0xa0)
[ 0.000000] [<c005f2a8>] (enable_irq) from [<c0c2ce3c>] (vt8500_irq_init+0x164/0x1a8)
[ 0.000000] [<c0c2ce3c>] (vt8500_irq_init) from [<c0c45e1c>] (of_irq_init+0x184/0x2f8)
[ 0.000000] [<c0c45e1c>] (of_irq_init) from [<c0c13be4>] (start_kernel+0x2b4/0x508)
[ 0.000000] [<c0c13be4>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x24/0x50 with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] vt8500-irq: Enabled slave->parent interrupts
[ 0.000000] clocksource: vt8500_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] printk: console [tty0] enabled
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
[ 0.060000] Calibrating delay loop... 298.59 BogoMIPS (lpj=1492992)
[ 0.070000] pid_max: default: 32768 minimum: 301
[ 0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070000] CPU: Testing write buffer coherency: ok
[ 0.070000] Setting up static identity map for 0x8400 - 0x8458
[ 0.070000] EFI services will not be available.
[ 0.070000] devtmpfs: initialized
[ 0.070000] VFP support v0.3: not present
[ 0.070000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.070000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.090000] pinctrl core: initialized pinctrl subsystem
[ 0.090000] thermal_sys: Registered thermal governor 'step_wise'
[ 0.090000] DMI not present or invalid.
[ 0.090000] NET: Registered protocol family 16
[ 0.090000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.090000] cpuidle: using governor menu
[ 0.100000] No ATAGs?
[ 0.100000] Serial: AMBA PL011 UART driver
[ 0.140000] AT91: Could not find identification node
[ 0.140000] SCSI subsystem initialized
[ 0.140000] libata version 3.00 loaded.
[ 0.140000] usbcore: registered new interface driver usbfs
[ 0.140000] usbcore: registered new interface driver hub
[ 0.140000] usbcore: registered new device driver usb
[ 0.140000] pps_core: LinuxPPS API ver. 1 registered
[ 0.140000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giom...@linux.it>
[ 0.140000] PTP clock support registered
[ 0.150000] clocksource: Switched to clocksource vt8500_timer
[ 2.550000] random: fast init done
[ 2.600000] NET: Registered protocol family 2
[ 2.600000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 2.600000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 2.600000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 2.600000] TCP: Hash tables configured (established 1024 bind 1024)
[ 2.600000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 2.600000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 2.600000] NET: Registered protocol family 1
[ 2.600000] RPC: Registered named UNIX socket transport module.
[ 2.600000] RPC: Registered udp transport module.
[ 2.600000] RPC: Registered tcp transport module.
[ 2.600000] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.800000] Initialise system trusted keyrings
[ 2.800000] workingset: timestamp_bits=30 max_order=15 bucket_order=0
[ 2.810000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 2.810000] NFS: Registering the id_resolver key type
[ 2.820000] Key type id_resolver registered
[ 2.820000] Key type id_legacy registered
[ 2.820000] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 2.820000] ntfs: driver 2.1.32 [Flags: R/O].
[ 2.820000] Key type asymmetric registered
[ 2.820000] Asymmetric key parser 'x509' registered
[ 2.820000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 2.820000] io scheduler mq-deadline registered
[ 2.820000] io scheduler kyber registered
[ 2.820000] pinctrl-wm8650 d8110000.pinctrl: Pin controller initialized
[ 2.820000] Enabled support for WMT GE raster acceleration
[ 2.850000] Console: switching to colour frame buffer device 100x30
[ 2.870000] fb0: wm8505-fb frame buffer at 0x4100000-0x4276fff
[ 3.080000] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 3.090000] STMicroelectronics ASC driver initialized
[ 3.100000] d8200000.serial: ttyWMT0 at MMIO 0xd8200000 (irq = 28, base_baud = 923076) is a VT8500 UART-1
[ 3.150000] brd: module loaded
[ 3.180000] loop: module loaded
[ 3.200000] libphy: Fixed MDIO Bus: probed
[ 3.210000] CAN device driver interface
[ 3.220000] via-rhine d8004000.ethernet (unnamed net_device) (uninitialized): Reset not complete yet. Trying harder.
[ 3.230000] via-rhine d8004000.ethernet eth0: VIA Rhine III at (ptrval), 00:40:63:31:04:18, IRQ 30
[ 3.250000] via-rhine d8004000.ethernet eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
[ 3.260000] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[ 3.270000] usbcore: registered new interface driver pegasus
[ 3.280000] usbcore: registered new interface driver asix
[ 3.280000] usbcore: registered new interface driver ax88179_178a
[ 3.290000] usbcore: registered new interface driver cdc_ether
[ 3.300000] usbcore: registered new interface driver smsc75xx
[ 3.310000] usbcore: registered new interface driver smsc95xx
[ 3.310000] usbcore: registered new interface driver net1080
[ 3.320000] usbcore: registered new interface driver cdc_subset
[ 3.330000] usbcore: registered new interface driver zaurus
[ 3.340000] usbcore: registered new interface driver cdc_ncm
[ 3.340000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.350000] ehci-platform: EHCI generic platform driver
[ 3.360000] ehci-platform d8007900.ehci: EHCI Host Controller
[ 3.360000] ehci-platform d8007900.ehci: new USB bus registered, assigned bus number 1
[ 3.370000] ehci-platform d8007900.ehci: irq 25, io mem 0xd8007900
[ 3.410000] hrtimer: interrupt took 35333 ns
[ 3.410000] ehci-platform d8007900.ehci: USB 2.0 started, EHCI 1.00
[ 3.420000] hub 1-0:1.0: USB hub found
[ 3.430000] hub 1-0:1.0: 4 ports detected
[ 3.430000] ehci-orion: EHCI orion driver
[ 3.440000] SPEAr-ehci: EHCI SPEAr driver
[ 3.450000] ehci-atmel: EHCI Atmel driver
[ 3.450000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 3.460000] SPEAr-ohci: OHCI SPEAr driver
[ 3.460000] ohci-atmel: OHCI Atmel driver
[ 3.470000] uhci_hcd: USB Universal Host Controller Interface driver
[ 3.470000] platform-uhci: probe of d8007b00.uhci failed with error -2
[ 3.480000] usbcore: registered new interface driver usb-storage
[ 3.490000] vt8500-rtc d8100000.rtc: registered as rtc0
[ 3.500000] vt8500-rtc d8100000.rtc: setting system clock to 2000-01-01T07:45:38 UTC (946712738)
[ 3.500000] i2c /dev entries driver
[ 3.510000] sdhci: Secure Digital Host Controller Interface driver
[ 3.520000] sdhci: Copyright(c) Pierre Ossman
[ 3.520000] Synopsys Designware Multimedia Card Interface Driver
[ 3.560000] wmt-sdhc d800a000.sdhc: WMT SDHC Controller initialized
[ 3.560000] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.570000] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.580000] usbcore: registered new interface driver usbhid
[ 3.580000] usbhid: USB HID core driver
[ 3.590000] drop_monitor: Initializing network drop monitor service
[ 3.600000] NET: Registered protocol family 10
[ 3.610000] Segment Routing with IPv6
[ 3.620000] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 3.620000] NET: Registered protocol family 17
[ 3.630000] can: controller area network core (rev 20170425 abi 9)
[ 3.640000] NET: Registered protocol family 29
[ 3.640000] can: raw protocol (rev 20170425)
[ 3.650000] can: broadcast manager protocol (rev 20170425 t)
[ 3.660000] can: netlink gateway (rev 20190810) max_hops=1
[ 3.660000] Key type dns_resolver registered
[ 3.670000] Loading compiled-in X.509 certificates
[ 3.700000] Freeing unused kernel memory: 1116K
[ 3.710000] Kernel memory protection not selected by kernel config.
[ 3.710000] Run /init as init process
[ 3.720000] with arguments:
[ 3.720000] /init
[ 3.720000] with environment:
[ 3.720000] HOME=/
[ 3.720000] TERM=linux
[ 3.760000] mmc0: new high speed SDHC card at address 59b4
[ 3.770000] mmcblk0: mmc0:59b4 SD 29.4 GiB
[ 3.790000] mmcblk0: p1 p2
[ 4.200000] random: dd: uninitialized urandom read (512 bytes read)
[ 4.640000] usb 1-3: new high-speed USB device number 3 using ehci-platform
[ 4.860000] hub 1-3:1.0: USB hub found
[ 4.870000] hub 1-3:1.0: 4 ports detected
[ 86.140000] usb 1-3.2: new full-speed USB device number 4 using ehci-platform
[ 86.320000] input: USB-HID Keyboard as /devices/platform/soc/d8007900.ehci/usb1/1-3/1-3.2/1-3.2:1.0/0003:04D9:0207.0001/input/input0
[ 86.400000] hid-generic 0003:04D9:0207.0001: input: USB HID v1.11 Keyboard [USB-HID Keyboard] on usb-d8007900.ehci-3.2/input0
[ 86.440000] hid-generic 0003:04D9:0207.0002: device has no listeners, quitting
[ 86.510000] input: USB-HID Keyboard System Control as /devices/platform/soc/d8007900.ehci/usb1/1-3/1-3.2/1-3.2:1.2/0003:04D9:0207.0003/input/input1
[ 86.590000] input: USB-HID Keyboard Consumer Control as /devices/platform/soc/d8007900.ehci/usb1/1-3/1-3.2/1-3.2:1.2/0003:04D9:0207.0003/input/input2
[ 86.600000] input: USB-HID Keyboard as /devices/platform/soc/d8007900.ehci/usb1/1-3/1-3.2/1-3.2:1.2/0003:04D9:0207.0003/input/input3
[ 86.620000] hid-generic 0003:04D9:0207.0003: input: USB HID v1.11 Keyboard [USB-HID Keyboard] on usb-d8007900.ehci-3.2/input2
[ 94.520000] random: crng init done
[ 252.410000] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

[Alexey Charkov]

Congrats on the progress! If worst comes to worst, you can now at
least hack up a quick and dirty init script in the initramfs to mount
your SD card and pivot root there :-)

вт, 6 окт. 2020 г. в 11:53, Brigham Campbell <m...@brighamcampbell.com>:
> [ 0.100000] No ATAGs?

This one looks particularly suspicious. Looks like legacy ATAG
bootloader parameters are not added to the device-tree based boot
arguments, thus your command line that u-boot passes through the ATAGs
gets overwritten by the (blank) DT command line.

Are you sure flipping these options gives no effect?
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set

# CONFIG_CMDLINE_EXTEND is not set

Maybe even try this one to completely overwrite whatever the
bootloader specifies:
# CONFIG_CMDLINE_FORCE is not set

Best,
Alexey

[Brigham Campbell]

No, I've tried several combinations of these options and none seem to be working very well... Not even CONFIG_CMDLINE_FORCE, strangely enough...

I've just noticed the following in the compiler output:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':

arch/arm/boot/compressed/atags_to_fdt.c:100:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

Does this seem suspect at all?

Thanks,

Brigham

[Alexey Charkov]

вт, 6 окт. 2020 г. в 15:17, Brigham Campbell <m...@brighamcampbell.com>:

>
> No, I've tried several combinations of these options and none seem to be working very well... Not even CONFIG_CMDLINE_FORCE, strangely enough...
>
> I've just noticed the following in the compiler output:
> arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
> arch/arm/boot/compressed/atags_to_fdt.c:100:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

Sounds relevant: you might be running into some kind of a stack
overflow. However, this function is not even called when
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is disabled.

Maybe disable support for all the other platforms aside from WM8650 in
your config, to make sure the early startup code is as lean as
possible? It's tricky to track down a stack overflow in early kernel
decompression code without even any kind of debug access to the board.

Best,
Alexey

[Brigham Campbell]

So I've disabled every system type except VIA/Wondermedia 85xx and 8650 processors.

Unfortunately, it looks like it hasn't helped the behavior. This is a very strange issue. Certainly not the kind I'd expect to be having...

[Brigham Campbell]

Okay, here's some (good?) progress:

I can now pass in parameters and boot into arch linux arm on the second partition of my SD card. I did this by applying the following patch to the device tree. But there's an important catch! The "bootargs" I've defined in the device tree aren't what's being passed into the kernel... It looks like the parameters defined in my .config are the ones being put into effect.

Why on earth would updating the device tree with an unused "bootargs" parameter allow me to pass in arguments defined in a different way?! Any clue what could be causing this?

I'm currently working on setting up arch properly on this device... I'm running into some seg faulting while installing software and I'm not sure why. Right now, I'm looking through the pacman logs to see if there's anything relevant. Any idea why I'd be getting segfaulting on software that should be working?

Thanks for all the help! Getting Linux up on this thing has taught me a ton about the kernel and arm devices. I hope I can get the segfaulting under control and get the majority of the peripherals working!

---

diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi

index bc057b6f7d16..af4d28b51d1c 100644

--- a/arch/arm/boot/dts/wm8650.dtsi

+++ b/arch/arm/boot/dts/wm8650.dtsi

@@ -10,6 +10,10 @@ / {

  #size-cells = <1>;

  compatible = "wm,wm8650";

 

+ chosen {

+ bootargs = "mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext4 rootwait console=ttyWMT0,115200 earlyprintk";

+ };

+

  cpus {

  #address-cells = <0>;

  #size-cells = <0>;

[Alexey Charkov]

ср, 7 окт. 2020 г. в 12:56, Brigham Campbell <m...@brighamcampbell.com>:

>
> Okay, here's some (good?) progress:
>
> I can now pass in parameters and boot into arch linux arm on the second partition of my SD card. I did this by applying the following patch to the device tree. But there's an important catch! The "bootargs" I've defined in the device tree aren't what's being passed into the kernel... It looks like the parameters defined in my .config are the ones being put into effect.
>
> Why on earth would updating the device tree with an unused "bootargs" parameter allow me to pass in arguments defined in a different way?! Any clue what could be causing this?

Sounds like a possible bug with the code that converts ATAGs into the
DT node - if it e.g. fails to allocate a string for the non-existing
"chosen" node and its leaves then you have a null string there and it
concatenates with your cmdline defined in the config... Or something
of that sort. Given that you probably have CMDLINE_EXTEND enabled, you
just end up concatenating the (empty) string that somehow ends up in
the DT. Just random thoughts :)

If you are by any chance willing to go down that rabbit hole, it might
be helpful to try rebuilding your kernel with an older version of
scripts/dtc/libfdt/ and all its contents (say, something from 2017 or
so). If it fixes your problem, then we can try and locate the faulty
commit by bisecting.

Best,
Alexey

[Brigham Campbell]

I'd be happy to track down the issue! Before this issue was introduced, we would expect CMDLINE_EXTEND to append the parameters passed in via the old version of U-Boot to the parameters built into the kernel, right? So I just need to determine whether an early 2017 release still has this issue. If it doesn't, I'll traverse half the commit history which modified anything in "scripts/dtc/libfdt/" and try again. If it's still broken, I'll try an earlier version. Do I have the right idea? Tracking down an issue in the kernel sounds like fun!

Also, I have Xorg up and running now. This is super cool! But the trackpad, keyboard, wifi, and (presumably) audio don't work. Are they supported at all?

Thanks,

Brigham

[Alexey Charkov]

ср, 7 окт. 2020 г. в 18:55, Brigham Campbell <m...@brighamcampbell.com>:

>
> I'd be happy to track down the issue! Before this issue was introduced, we would expect CMDLINE_EXTEND to append the parameters passed in via the old version of U-Boot to the parameters built into the kernel, right? So I just need to determine whether an early 2017 release still has this issue. If it doesn't, I'll traverse half the commit history which modified anything in "scripts/dtc/libfdt/" and try again. If it's still broken, I'll try an earlier version. Do I have the right idea? Tracking down an issue in the kernel sounds like fun!

That's exactly the way :)

> Also, I have Xorg up and running now. This is super cool! But the trackpad, keyboard, wifi, and (presumably) audio don't work. Are they supported at all?

No support for audio. For wifi you need to toggle some GPIO pin to
power up the internal USB wifi adapter (look through some of the older
threads here for which is the right one on WM8650). Trackpad and
keyboard on WM8650 are connected through the internal UHCI root hub
AFAIR - your kernel logs showed some error with its initialization
(though it used to work before, so again sounds like a regression in
recent kernels)

Best,
Alexey

[Brigham Campbell]

The purpose I started this thread for has been met! Therefore, I think
it would make sense to end this thread for historical purposes.

To clarify, I've configured and compiled Linux
kernel 5.8.0 in a way such that it successfully boots on a WM8650
laptop. I have not yet figured out how to enable wifi with the new
chardev gpio userland interface. I have not figured out why the built-in
trackpad and keyboard aren't working. And I have not figured out a way
to get audio working (although, Alexey indicates that audio was never
supported for this device, so it's not likely that I'll be able to get
it working).

The topic of my next thread will be tracking down the issue related to
passing boot parameters into the kernel. It's working for now, but it
seems to be working in a very precarious, unexplained way. The thread
after that (assuming I get that far) will be about selecting sane kernel
configuration options, making more of the peripherals on this laptop
work, and coping with the changes that Linux v5.8 and drivers have made
to userland (it would seem that nobody has really tried to get a kernel
beyond version 3 on this device, so I expect there are a couple
important differences).

If you want to replicate what I've done to get the latest kernel working
on a WM8650, read on:

The VT8500/WM8505 community GitHub wiki was instrumental to me as a
relative beginner. Check it out here:
https://github.com/linux-wmt/linux-vtwm/wiki

To get v5.8.0 running, most of the steps are the same. Just use my
kernel config and apply my patch to the wm8650 device tree (which
resides in the kernel source). I've attached both to this message.

In following threads, I'll work to make these instructions more general
and more straightforward. Alexey was super patient with me getting this
kernel working and I learned a ton! Please let me know if you could use
some help so I can contribute back to the community!

Thanks,
Brigham

[Xlaits Xavier]

Reporting in from 2022!
Is there any way to make this work for a WM5805?