Maybe. But I don't know how. The easiest is probably sticking with the customization script. Install the tools, build your thing, and then do some cleanup (apt purge, apt clean, apt autoremove ....).
I'd try with linux-image-vendor-rk35xx and linux-dtb-vendor-rk35xx and leave cli bsp package for now as it is.
That being said it would be more useful to get an idea about WHAT is actually failing an attempting to fix before messing with the kernels. Hook up a serial console and set verbosity to 7. https://debug.armbian.de
You seem to be the first person reporting such an issue and none of us has a second sight. Therefore without logs there is pretty much nothing we can do.
Existing installations can simply be apt update/upgraded since both Ubuntu and Debian released fixed versions for their supported userspaces.
Armbians rootfs packages, which are used for building new images, have been recreated and pre-built images available for download are being rebuilt/replaced as well.
tl;dr: mitigation is in the works/already done
Not possible without tinkering since at least the boot loader must be present either via sd or on board SPI flash.
However no idea how to access this onboard 2M storage w/o the option to boot the board via sd beforehand.
Not sure if it is worth exploring in this direct. Faster and probably cheaper too is to buy a new board.
Sometimes newer kernel packages are not pushed automatically via apt for various reason. This usually isn't an issue. Having .36 instead of .32 most likely does not give you significant advantages.
There is however always the option to build a kernel package by yourself and then install via dpkg.
https://github.com/armbian/build
There is no UEFI or Secureboot available on this board. However you may want to try this: https://github.com/edk2-porting/edk2-rk3588
and then https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security
Hm as for me I only have standard jumper wires for debugging my stuff. last but not least because it does not connect 5 volts which isn't necessary anyways for serial interaction and reduces the risk of frying a board by connecting this wrongly.
Well the other variant of course is that it might be connected wrongly . Tried to flip RX and TX lines? common mistake having these mixed up.
If it boots from sdcard there MUST be ouput to the debug serial.
This output isn't related to uboot. So I assume you don't get any output whatsoever which means broken/missing boot loader.
I'd try to boot from fresh sdcard and then start investigating.
I'd do the following:
Boot any image that works for your and check if /dev/mtd0 is present. Then simply overwrite it with dd if=/dev/zero of=/dev/mtd0. May take a few minutes. This type of memory is rather slow at writing.
We cannot afford to provide pre-made images in every kernel-userspace combination for every board. The amount of resources necessary could be just insane. However that is what the build framework is made for so you can choose exactly what you want and build it by yourself.
https://github.com/armbian/build