What branch are you on?
Stable is on 6.1.54-1 according to https://gitlab.manjaro.org/-/snippets/930/raw
And on my unstable I just updated to linux-rpi4-6.1.58-5 and it rebooted just fine. (I am running headless though, if you have some desktop that is creating trouble for you)
Iām on testingā¦
[ARM Testing Update] 2023-10-21 - Kernels, PipeWire, KDE Gear & Frameworks, Thunderbird is probably a better thread, or even start a new maybe.
But no matter what you decide, provide more info (logs etc) than āI can not bootā, we have no wizards on this forum that magically can gather the information neededā¦ 
Using what little info you gave we used to have to load the bluetooth firmware manually with attach-bluetooth.service at boot. Over a year ago the RPi kernel started loading the firmware. Disabling attach-bluetooth.service should have been done at that time. If you have attach-bluetooth.service running you need to disable it and also comment out dtparam=krnbt=on in /boot/config.txt if it exists as it is not needed any more.
Trying to load firmware manually might be causing an issue with this newer kernel.
Thank you, I will try this (tomorrow).
I looked at the latest README in /boot/config.txt and it does read differently now.
Name: cma
Info: Set custom CMA sizes, only use if you know what you are doing, might
> clash with other overlays like vc4-fkms-v3d and vc4-kms-v3d.
Load: dtoverlay=cma,=
Params: cma-512 CMA is 512MB (needs 1GB)
cma-448 CMA is 448MB (needs 1GB)
cma-384 CMA is 384MB (needs 1GB)
cma-320 CMA is 320MB (needs 1GB)
cma-256 CMA is 256MB (needs 1GB)
cma-192 CMA is 192MB (needs 1GB)
cma-128 CMA is 128MB
cma-96 CMA is 96MB
cma-64 CMA is 64MB
cma-size CMA size in bytes, 4MB aligned
cma-default Use upstreamās default value
I remember in one of your postās above seeing the error Failed to allocate cma and this got me thinking that within the last month I was having issues playing hevc 3840x2160 59.940fps video and I had to enable hdmi_enable_4kp60=1 in config.txt to get it play right. Something changed in the kernel. I wonder if by doing that it might provide some extra needed video parameters needed even though you do not have a UHD monitor like me but are are playing a UHD video. I had never had to do that before. I also leave disable_fw_kms_setup=1 enabled because sometimes I switch over to kodi-rpi to a TTY with CTRL+SHFT+F2. It never seemed to hurt anything. Here is my config.txt in that section:
#enable vc4
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d,cma-512
#max_framebuffers=2
#dtoverlay=rpivid-v4l2
disable_fw_kms_setup=1
hdmi_enable_4kp60=1
This option changes nothing. I think that āvc4-drm gpu: swiotlb buffer is fullā is a different problem than
in a tty :
vc4-drm gpu: [drm] ERROR Failed to allocate DLIST entry: -28
or in journalctl
Page flip failed: drmModeAtomicCommit: No space available on the device
who make the freezes.
For the moment no more problems with pull/5684. I will continue to report.
I passed along your info to RPi.
Hello,
I tried per your recommendations.
1/ I have no attach-bluetooth.service at all.
2/ I had dtparam=krnbt=on in /boot/config.txt and removed it.
Still, 6.1.58-2 crashes at boot.
Sorry for providing no ālogsā, but the crash happens early and the pi 4 didnāt had a chance to log anything to disk.
Most of the times the crash happens just after console resolution change, so black screen, nothing to see. SD card access LED steady lit.
Rebooting several times I eventually got a chance to perform an āold fashionedā screenshot, thatās ugly but pretty readable.
It still complains about bluetooth, but the kernel actually crashes on aes_arm64 decryption, which is rather interesting.
Thatās about all the info I can provideā¦
Since you have some old configs. If you have:
gpu_mem=64
dtoverlay=vc4-fkms-v3d
Also make these changes to:
#gpu_mem=64
dtoverlay=vc4-fkms-v3d
#Or if you need more gpu memory
dtoverlay=vc4-fkms-v3d,cma-512
I believe FKMS is broken right now and the consider it dreciated and not a priority to fix.
Hello,
I followed your suggestion, but at the same time received a whole lot of new ātestingā updates, among which kernel 6.1.58-5-MANJARO-RPI4.
And then it boots !
So I donāt know if itās the settings change or the newer kernel, but well, looks like itās fixed 
Thank you for your help !
I imagine it was the config changes. I had no issue with the older kernel and do not remember anyone else having issues. Yep there was another testing snap done just now.
downgrade from 6.6, it against rpi-overlays package?
Not sure what you are asking but the rpi-overlays package should be good for all kernels in testing/unstable branches as well as the raspberrypi-bootloader packages.
can you try 6.6 ā 6.5 or 6.1, then will know.
I just went from 6.6 ā 6.1 with no issues. I still am not seeing what you are getting at. Seems like we went over this before. The overlays are maintained in their raspberrypi-firmware git and that git is based on what they call their stable branch which is always the latest upstream LTS kernel which right now is 6.1. In the future it will most likely be kernel 6.6. It is good for all kernels. They do not maintain a separate firmware git for each kernel. You can download and use the latest overlays on any present kernel they have. As well as any file in this directory except the kernels as ourās are custom compiled.
https://github.com/raspberrypi/firmware/tree/master/boot
They mostly do all of the development on what they consider their stable tree at the time and from there migrate what is needed to the other branches for conformity.
RPi is asking if you have an update. They are beginning to believe that some of those errors are the result of programs being closed or buggy. They specifically quoted this quote and asked if that means it is fixed.
i have enabled a maximum of gnome-shell extension and apart from vc4-drm gpu: swiotlb buffer is full , I didnāt have any crash. But I think it takes a few days to be sure. It would be good if other people who applied the patch confirm. If I can do something to help identify swiotlb buffer is full. It does not occur just when reading video but at least it is easy to trigger, just read an accelerated hardware video.
The problem is no one else reporting this is able to compile the kernel with his commits apparently. They use other distros and they can not reproduce it using the Pi OS compiled with the commits so unable to test on their native distroās.
Anyway I passed your info to them again. Looking like they canāt do much more until something breaks down with them where they can figure out what happened.
The latest RPi kernels and kernel related packages has been pushed to the unstable branch when the mirrors sync.
Other than the merging with upstream for kernel bump the other packages are mostly minor fixups all involving the rpi5. One of those fixups with the rpi5-eeprom package involves the rpi5; no change with the rpi4-eeprom package.
https://github.com/raspberrypi/rpi-eeprom/pull/494
I just got an email notification from 6by9 @ RPi saying that he is going to merge his commits that @tartanpion has been testing into the main tree so when that happens I will rebuild the 6.1.61 / 6.6.0 kernels.
linux-rpi4 6.1.61-1
linux-rpi4-headers 6.1.61-1
linux-rpi5 6.1.61-1
linux-rpi5-headers 6.1.61-1
raspberrypi-utils 20231102-1
rpi4-eeprom 20231030-1
rpi5-eeprom 20231030-1
rpi-overlays 6.1.61-1