Is it planned for devterm kernel to be packaged for manjaro linux?
3 Likes
i’d love this as well
I’m going to start taking a look at building images for A06 based on the kernel and uboot patches, and devicetree overlays provided by the Clockwork folks for the Armbian port that shipped with the DevTerm.
Upstream ArchLinux ARM and Manjaro ARM seems to both have support for the A06’s RK3399, so I am optimistic it is doable.
Some reference material, for other intrepid souls:
6 Likes
if you need any help let me know, i’m also interested in getting ALARM/manjaro/endeavourOS going on my DT
1 Like
Are you going to add official device support for the DevTerm so we can build our own images using the Manjaro ARM tools?
If so, do you have a repository we I can look at how you are doing this and try your work from time to time?
1 Like
That’s my hope, but I’m not too clear on the process towards official support. I’ve got PKGBUILDs for u-boot and post-install complete that I can share out once I finish up getting the kernel up to 5.15 and reducing the delta between mainline a bit. The patch set put out by Clockwork depend on a few patches that are only in Armbian so I need to finish tracking all those down to get a 5.15 build that will compile. Going well, just slow.
2 Likes
That sounds great. When you have the PKGBUILD for u-boot ready that is something I would want to take a look at as well. I’d like to have some custom boot splash as well as other stuff that can be enabled in u-boot.
How do you build your PKGBUILDs. Are you using the “buildarmpkg” for the Manjaro ARM tools on a u-boot build directory that you setup on your machine for the rk3399?
1 Like
Yeah, pretty much that’s my setup right now.
u-boot repo is here: GitHub - maxfierke/uboot-clockworkpi-a06: PKGBUILDs for u-boot w/ clockworkpi DevTerm A06 patches, for Manjaro ARM
Compiles fine, but haven’t tested it yet (but it’s just the Clockwork patches applied, so barring some missing thing from Armbian I missed, it probably works)
3 Likes
Awesome! Not too familiar with building full Manjaro but really want to try it, are you going to upload an image sometime?
Cool. Exactly what I was hoping for. Nice and clean. I will try to build it as well and tinker with it a while.
When you are playing with u-boot, are you building the whole manjaro image and flashing it to the sd-card or are you just quickly flashing the u-boot to the sd-card and testing it? There is probably also a way to make u-boot wait so you can update it via uart on the fly just for playing around with it. That way there is no need to remove the sd-card every time. I am interested on how you want to test it on the device.
Many thanks!
1 Like
Haven’t tested it yet (waiting to have a kernel for it to boot into) but will probably end up using buildarmimg to build a test build and flash to the SD. Might do more localized stuff w/ u-boot if there are issues but haven’t really thought too hard about that yet. I’ve been finding the UART to be a bit unreliable so far, unfortunately.
2 Likes
yeah, when I get something working I’ll share a build out. Will try to setup a Pacman repo too, probably.
2 Likes
Yes true. It is not very reliable, also at insane speed. Maybe when thinking about the future one can try to enable USB and DFU in u-boot. So with some key combination it would be possible to upgrade all stuff on the SD via USB DFU.
Maybe I will try to just flash u-boot without anything else and see how far I get via UART.
yeah, might be worth dropping it to 115.2 kbps and seeing if that improves things. I just kept the 1.5Mbps to keep everything the same with the Clockwork Armbian port before I started tinkering too much.
1 Like
Alrighty, got an image built, but definitely something missing for u-boot. buildarmimg does not write either stage of the bootloader at the correct locations (or possibly at all). I wrote them manually at the right spots, and was able to get some output from u-boot to verify it did in fact at least hit the first stage:
$ sudo picocom /dev/ttyUSB0 -b 115200 -f n -d 8 -p 1
picocom v3.1
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
hangup is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is :
emap is : crcrlf,delbs,
logfile is : none
initstring : none
exit_after is : not set
exit is : no
Type [C-a] [C-h] to see available commands
Terminal ready
U-Boot TPL 2021.10-1 (Nov 25 2021 - 01:35:12)
rk3399_dmc_of_to_plat: Cannot read rockchip,sdram-params -1
DRA
and that’s it for today.
Kernel source is here: GitHub - maxfierke/linux-clockworkpi-a06: Linux kernel PKGBUILD for ClockworkPI DevTerm A06
Contains some untested audio code that may or may not fry your audio/entire device. Trying to avoid porting the es8323 drivers, some old mailing list post seem to indicate the es8328 is probably compatible and it has upstream-supported drivers, so I made some dts changes to use that instead. I’m pretty sure I wired up the correct regulators, based on my reading of the power schematics, but cannot be sure.
Post-install package is here: GitHub - maxfierke/clockworkpi-a06-post-install: Post-install package for ArchLinux ARM/Manjaro ARM
3 Likes
I am struggling to build the image with buildarmimg possibly because my lack of knowhow in this area. The packages itself I was able to build smoothly but how can I tell buildarmimg to install these packages when building the image?
When I use the “-i” option and try for e.g. with uboot the buildarmimg finally says:
:: uboot-clockworkpi-a06 and uboot-rockpro64 are in conflict (uboot). Remove uboot-rockpro64? [y/N]
and bails out with an error.
Any help is appreciated.
1 Like
Ok I maybe I need to dive deeper here. I initially thought I can just add a devterm device to the ARM profiles but I see that the buildarmimg scripts would need to be updated as well in order to write things at the right places. So maybe for now the rockpro64 device needs to be my choice and I need to find a way to install the clockwork packages for uboot and linux instead of the ones that it would usually take.
1 Like
Ok, got the image build but there seems to be an issue with the bootloader like @m4xm4n mentioned. Need to get the setup ready for some debugging.
With using a rather short microUSB cable I was able to see some output of the bootloader. As of now this is what it says on my board:
U-Boot TPL 2021.10-1 (Nov 24 2021 - 15:26:40)
rk3399_dmc_of_to_plat: Cannot read rockchip,sdram-params -1
DRAM init failed: -1
DRAM configuration moved out of the base rk3399 devicetree in u-boot 2021.10 into separate includeable units that need to be specified for each device type based on which DRAM configuration they use. pushed an update to the u-boot repo that should address it, but still running a build to confirm
1 Like
Cool. Yes this looks promising. I wonder how this was going to work on the Armbian build. Probably they used an old u-boot then?