Raspberry Pi Kernels (2.0)

The latest linux-rpi4/5 kernels and rpi5-eeprom packages has been pushed to the unstable branch when the mirrors sync.

The rpi5-eeprom package has some preliminary work for network install which we do not use in latest but it is there if some one wants to do a network install of PiOS. Most of us use default so really no big reason to flash the pi5 eeprom.

They finally upgrade 6.7-rc6 to 6.7-rc8 but that is still 2 weeks behind. I decided to not waste my time with it as 6.7.1 could possibly hit at any time upstream.

linux-rpi4 6.6.12-1
linux-rpi4-headers 6.6.12-1
linux-rpi5 6.6.12-1
linux-rpi5-headers 6.6.12-1
rpi5-eeprom 20240116-1
1 Like

@Darksky, 6.8-rc1 is out.
can you pre-build for CPU-job test?

@Darksky
v6.7.1 (https://github.com/raspberrypi/linux/blob/rpi-6.7.y/Makefile) is out and v6.6.13 also.
Can I request to enable bcachefs module on the 6.7 kernel?

image

I have both compiled and tested. 6.6.13 sees to be good. 6.7 has a reboot/shutdown issue. It will lock up toward the end of the boot before the login screen and When I pull the power and pluf power back it goes through fsck then boots ok but the next boot it will go through the same process again. If you want to deal with that I will post 6.7 also with 6.6.13. I never tested it on the pi4 though. It may be different.

@Rip2 I will have to wait for RPi to add it to their gitlab tree. It’s no small job merging their tree with upstream. They have a ton of their own patches and they do a git rebase every week.

The latest linux-rpi4/5 kernels has been pushed to the unstable branch when the mirrors sync.

linux-rpi4 6.6.13-1
linux-rpi4-headers 6.6.13-1
linux-rpi5 6.6.13-1
linux-rpi5-headers 6.6.13-1
1 Like

6.6 config8, CONFIG_UDMABUF is not set ?

DMABUF options

CONFIG_SYNC_FILE=y

CONFIG_SW_SYNC is not set

CONFIG_UDMABUF is not set <— ???

CONFIG_DMABUF_MOVE_NOTIFY is not set

CONFIG_DMABUF_DEBUG is not set

CONFIG_DMABUF_SELFTESTS is not set

CONFIG_DMABUF_HEAPS=y

CONFIG_DMABUF_SYSFS_STATS is not set

CONFIG_DMABUF_HEAPS_SYSTEM=y
CONFIG_DMABUF_HEAPS_CMA=y

end of DMABUF options

Why are you needing it set? Rpi does not set it and looking around arch-arm does not and our linux kernel here does not.

I finally got around to testing the linux-rpi4-mainline 6.7.1-1 kernel package and they seem to be ok unlike the broken linux-rpi5-mainline 6.7.1-1 package. My router quit working yesterday.

@Dulbi the linux-rpi4-mainline 6.7.1-1 kernel has BCACHEFS_FS module enabled if you are wanting it for the pi4.

The eeprom packages has an update in latest regarding image and FAT compatibility which most of us use default so no big reason to flash the eeprom until it makes it to default.

I am going to open an issue with linux-rpi5-mainline 6.7.1-1 today on their github.

These packages pushed to the unstable branch when the mirrors sync.

linux-rpi4-mainline 6.7.1-1
linux-rpi4-mainline-headers 6.7.1-1
rpi4-eeprom 20240122-1
rpi5-eeprom 20240122-1
1 Like

youtube watch form 480p to 1080p, what a surprise.
don’t know which update caused by, kernel or ffmpeg(kynesim-6.0.1-main)?

1 Like

I have built upstream 6.8.0-rc1 here. How can I test this. Also I am on mesa 23.3.4 is that ok?

mesa-23.3.4 didn’t had CPU-jobs patches, 24.0-rc2 does.

@Rip2 rpi I’m in the process of compiling mesa-git 24.0.0_devel. But that still does not answer my question how to test if it is working.

run vulkan demos above link, special those raytracing.

None of the raytracing’s work on my pi4.

Enabled device extension "VK_KHR_acceleration_structure" is not present at device level
Enabled device extension "VK_KHR_ray_tracing_pipeline" is not present at device level
Enabled device extension "VK_KHR_deferred_host_operations" is not present at device level
Enabled device extension "VK_EXT_descriptor_indexing" is not present at device level
Could not create Vulkan device: 
ERROR_EXTENSION_NOT_PRESENT

Wonder if something has to be enabled in mesa-git config or are you sure they are supposed to work. Looking up the errors it seems that if it is not mesa then the gpu does not support it.

Pi vulkan-1.2 supported only, so pass to CPU do the jobs that what they said or i misunderstand?
kernel, mesa, vulkan-demo?
can you test VKdoom for double check?

edit,
6.8-rc1 note did not seen any v3dv things, maybe not merge?

edit2,
11th/Jan. vlog, maybe my english level can not totally understand what he said.

edit3,
6.8-rc2,
Maíra Canal (1):
drm/v3d: Free the job and assign it to NULL if initialization fails

I am rebuilding mesa-git today. I looked over the configure logs and it was searching for an installed v3dv3 package which it did not find.

I found this 3 year old guide to build v3dv by Igalia. At that time it was merged into the mesa tree in a separate branch. So will have to do some more searching to try some type of updates with it.

https://blogs.igalia.com/apinheiro/2020/06/v3dv-quick-guide-to-build-and-run-some-demos/

Additional:

I do not know if it will make any difference with things but here is the latest mesa-git packages.

mesa-git-24.1.0-183883.c4b32f9e90b.d41d8cd-1 packages

v6.7.2 is out

6.8-rc2 is now in the RPi repo but it is not ready for prime time yet. They are in the Fixup Mode.

https://github.com/raspberrypi/linux/commits/rpi-6.8.y

mesa-24 highlight, wait 6.8-RC? to test.
Maíra Canal (22):

v3dv: implement VK_EXT_multi_draw

v3dv: move multisync functions to the beginning of the file

v3dv: allow different in/out sync queues

v3dv: allow set_multisync() to accept more wait syncobjs

drm-uapi: extend interface for indirect CSD CPU job

v3dv: check CPU queue availability

v3dv: create a CPU queue type

v3dv: use the indirect CSD user extension

v3dv: occlusion queries aren’t handled with a CPU job

drm-uapi: extend interface for timestamp query CPU job

v3dv: use the timestamp query user extension

drm-uapi: extend interface for reset timestamp CPU job

v3dv: use the reset timestamp user extension

drm-uapi: extend interface for copy timestamp results CPU job

v3dv: use the copy timestamp query results user extension

drm-uapi: extend interface for the reset performance query CPU job

v3dv: don’t start iterating performance queries at zero

v3dv: use the reset performance query user extension

drm-uapi: extend interface for copy performance query CPU job

v3dv: use the copy performance query results user extension

v3d/v3dv: move V3D_CSD definitions to a separate file

v3dv: enable CPU jobs in the simulator

They are still trying to get things right with 6.8-rc2. They aborted their last “Compile Tests” Friday. I usually do not see much activity on their github on the weekends.

I have compiled and tested their latest and for some reason the schedutil governor is not scaling the cpu cores. It seems to be stuck at 600MHz. Everything else seems to be working ok as far as I can see. I got the scaling to work by installing cpupower and then ran this command:

sudo cpupower frequency-set -g ondemand

You can monitor the cpu/temp with this command in a terminal:

cpu-temp-speed

I still have no clue how to test the new cpu-jobs. I have the mesa 24 git version installed I posted above. Bottom line is if you want to test the kernel on your pi4 here it is. Just be sure you install cpupower and enable the ondemand govenor as shown above to have the cpu threads scaling.

https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rpi4-rc/-/jobs/13624/artifacts/download

6.8-rc2, after login.
*get_mempolicy: Function not implemented