The Linux 5.15 kernel has a DTB for the Reform 2 now. I have been unable to build a bootable kernel from it, or from the current master of Torvald’s repo. Is there a process for compiling a working mainline kernel.
Secondarily, I have only been able to use uncompressed kernels made from the Reform Image kernel. Is it possible to use a compressed kernel, or an initrd?
Thirdly, is there a good way to view and alter the environmental variables of the u-boot or to build and use an upstream u-boot or other bootloader?
Das U-Boot: hook up a serial console (3.3V, 115200bps), power up the Reform, and interrupt the boot at the prompt. Type
=>setenv bootargs ‘foo bar baz’
If that works, do it again with
prior to “boot” to keep the changes.
U-Boot has a built-in help system, fwiw.
If You are trying a new U-Boot, install it to an SD card and test it from there before screwing up the eMMC (source: embedded Arm dev/SBC bring-up with a JTAG programmer that gets used too often).
Well, I was hoping I didn’t have to use a second computer and plug a USB UART adapter on, but that’ll be fine. thanks for the info.
Anything further about why the compiled (vanilla) kernels aren’t working, or do you think this more of an exercise in u-boot troubleshooting?
(Sorry,I have been away hiking for ~week.)
I am getting ready to do similar (5.15 upgrade, Slackware; then OpenBSD on Reform).
When You bounced the kernel, did You use /proc/config* as a guide?
I did. Without an initrd I can boot the kernel just fine over serial. The screen never initializes. With an initrd (from Fedora, with a Fedora kernel, initrd wrapped by mkimage, kernel extracted via zcat), it never hits a login/shell, but appears to boot, again, no screen.
I’ve only had video on the panel with the 5.12 kernel that is patched by the image build scripts (and the initial preload from the uSD that came with the machine).
It appears that u-boot changed their API again and threw away support for this board in 2020.01. So, I guess if we want a newer u-boot, it’ll have to go back in the tree after being fixed up.
I’ll spend some more time on it later.
Hi, there is no support for any display yet in the mainline DTB.
Edit: last time I checked, a patch like this would be necessary LKML: Guido =?iso-8859-1?Q?G=FCnther?=: Re: nwl-dsi: fixup mode only for LCDIF input, not DCSS
That means when using the DCSS engine (as in the single-display dts), these 2 lines need to be disabled: nwl-dsi.c - drivers/gpu/drm/bridge/nwl-dsi.c - Linux source code (v5.15.6) - Bootlin
The codepath and functions in these have changed by the 5.15 kernel, guarding, or even commenting the lines that appear to be their equivalents to that patch, does not end up enabling the display.