4.4 Kernel is end-of-life

[krioso]

I've tried asking this question in different ways over the past couple of months. I've seen it asked by others as well. I haven't seen any direct answer in other ways the question has been asked.

The closest I've seen was related to the Docker issue and a workaround to make Docker work was provided.

My situation is that I can't use an outdated kernel on a Production system.

Is there any way to get information to understand what is needed to build or retrieve or be able to upgrade to a newer kernel?

[jglover512]

Might be worth looking into Builtroot or the Yacto project to build a community run image.

[krioso]

I'd be happy to....but (as others have asked as well) would be helpful to know more about how the current image is built, what to consider for future builds, why the 4.4 kernel is prioritized and overriding updates, is there something about the hardware which prevents running a newer kernel, what are the limitations or parameters to keep in mind. I've tried a bunch of build options without success.

I imagine certain specific considerations were made when deciding how to build the images that are provided. It would be helpful to know what those considerations are, including a clearer description of how the firmware flash process is working. The reality is that you can't (to my knowledge) attach a screen and access a terminal when the system doesn't boot, to be able to see what is happening and why.

Not to distract from my concern - I have three Helm V2's and I really want to be able to update them and use them freely as the Helm effort unfortunately fades into history, but I can't do that comfortably without an updated kernel (either Helm-provided or an alternative that will work).

All of the above does not take anything away from the effort already put in by the founders to keep the devices running in some useful way - they could've just shut the doors and left the existing servers for the recycle heap.

I remain unclear as to why the question fo the kernel selection hasn't been answered directly. If the answer is, "Sorry, the device can't support a kernel beyond 4.4", then knowing that would set a path for people to know what to do - use with an end-of-life kernel, try to stumble onto an alternative, or send the devices to recycle.

[Jackbeef]

The board is not really that different. It is a [rk3399-evb board] (https://wiki.radxa.com/Rockpi4/Core) with some extra (spice) on top (rk818) . Kernel 4.4 is what rockchip is providing to boot. It was their base template which helm crew used. The ev board is similar to fuhai board ( look at the link) soldered a rockchip 4 core SOM. Currently spinning up armbian tool chain for the board. I wish I had a fuhai board.

[Jackbeef]

I'd be happy to....but (as others have asked as well) would be helpful to know more about how the current image is built, what to consider for future builds, why the 4.4 kernel is prioritized and overriding updates, is there something about the hardware which prevents running a newer kernel, what are the limitations or parameters to keep in mind. I've tried a bunch of build options without success.

I imagine certain specific considerations were made when deciding how to build the images that are provided. It would be helpful to know what those considerations are, including a clearer description of how the firmware flash process is working. The reality is that you can't (to my knowledge) attach a screen and access a terminal when the system doesn't boot, to be able to see what is happening and why.

Not to distract from my concern - I have three Helm V2's and I really want to be able to update them and use them freely as the Helm effort unfortunately fades into history, but I can't do that comfortably without an updated kernel (either Helm-provided or an alternative that will work).

All of the above does not take anything away from the effort already put in by the founders to keep the devices running in some useful way - they could've just shut the doors and left the existing servers for the recycle heap.

I remain unclear as to why the question fo the kernel selection hasn't been answered directly. If the answer is, "Sorry, the device can't support a kernel beyond 4.4", then knowing that would set a path for people to know what to do - use with an end-of-life kernel, try to stumble onto an alternative, or send the devices to recycle.

I also tried other images. via rs232 , it complains about no trust.img error. Well loaderis looking for an image that it was built for.

[joecole889]

I'd be happy to....but (as others have asked as well) would be helpful to know more about how the current image is built, what to consider for future builds, why the 4.4 kernel is prioritized and overriding updates, is there something about the hardware which prevents running a newer kernel, what are the limitations or parameters to keep in mind. I've tried a bunch of build options without success.

I imagine certain specific considerations were made when deciding how to build the images that are provided. It would be helpful to know what those considerations are, including a clearer description of how the firmware flash process is working. The reality is that you can't (to my knowledge) attach a screen and access a terminal when the system doesn't boot, to be able to see what is happening and why.

Not to distract from my concern - I have three Helm V2's and I really want to be able to update them and use them freely as the Helm effort unfortunately fades into history, but I can't do that comfortably without an updated kernel (either Helm-provided or an alternative that will work).

All of the above does not take anything away from the effort already put in by the founders to keep the devices running in some useful way - they could've just shut the doors and left the existing servers for the recycle heap.

I remain unclear as to why the question fo the kernel selection hasn't been answered directly. If the answer is, "Sorry, the device can't support a kernel beyond 4.4", then knowing that would set a path for people to know what to do - use with an end-of-life kernel, try to stumble onto an alternative, or send the devices to recycle.

For what it is worth, I was able to find a serial port on the board and get console access to the system. This allows me to watch the boot sequence and debug startup problems. It is a 3 pin header at the tail end of the M.2 SSD near the negative battery terminal. The pin closest to the board corner is ground. The baud rate I use to connect is 1515000.

[epilatow]

Not sure if anyone is still paying attention here or is still using helm hardware. I had a Helm v2a sitting around and wanted to use it with a modern linux kernel and distro, so I created a new linux 6.12 kernel based device tree blob (combining the rk3399-evb.dtb and disassembled information from the 4.4 rk3399-helm-v2a.dtb), and then used armbian to create new Ubuntu 24.04 images for flashing. You can find (and build) new images here: https://github.com/epilatow/helm-armbian. If you just want to upgrade an existing system to a newer kernel, grab the new rk3399-helm-v2a.dtb file from that repo (I've only tested it with 6.12 kernels).