11-22-2024, 11:38 AM
(This post was last modified: 11-22-2024, 11:57 AM by Cactus2580.)
Sorry for delay, got sick, didn't want to stare at screens for hours - a mksquashfs on my hardware takes nearly 20mins on 4 processor cores at a size of ~877mb.
As per your questions above, I have attempted to move the entire /boot directory from one to the other. Pretty early on, actually. No luck. I have also moved the entire lib/firmware from -Core to DSL.R7, no luck there either.
As far as I can tell, after much screwing around on different forums and searches and the AMD graphics info, the issue I'm running into here is related to the kernel itself not recognizing the Wrestler HD6290 device, or improperly assigning memory regions to said device. I've tried blacklisting the amdgpu driver, I've tried setting radeon.cik_support=1 radeon.si_support=1 amdgpu.cik_support=0 amd.si_support=0, and vice-versa. I've tried forcing the radeon driver, and I have not been able to find a single bit of information on "downgrading" from amdgpu to radeon, only the opposite. It -seems- that every other instance of anyone asking a similar question anywhere on the internet has to do with the kernel automatically detecting their hardware using the radeon portion of whatever the kernel uses to detect video hardware, and them wishing to "upgrade" to the more modern amdgpu.
AntiX-23.2-Core, which does run a 5.10.224 kernel as opposed to 5.10.18x kernel, automatically detects it. Swapping kernels straight across makes for... can't find AUfs or some similar error. Swapping initrd from Antix-Core to DSL.R7 gets nothing. I've not only forced the entire /firmware from -Core to DSL.R7, with no luck, but I've also tried moving just the /firmware/radeon over, also no luck. I have been unable to find a list of what drivers are statically compiled into the 5.10.x kernel anywhere in the documentation that I've been able to find, and I've been unable to figure out a command to specify at boot flag time what display driver for the kernel to use, and DSL.R7 will not even hit the framebuffer or serial console or whatever it's called these days before running into rainbow snow errors, no X involved at all. Whatever the kernel is doing screws up well before initrd and linuxfs, so I'm not sure this is an error of having /lib/firmware/radeon, as opposed to the kernel itself lacking support for my card itself. Apparently x86-linux-free might also include the ATI driver, but I am unable to figure out how to invoke that, either.
Do we know if John(?) has trimmed down the firmware that exists within the kernel itself? This is the only explanation that I can come up with so far. At this point, my former curiosity has turned into disgust with the hardware itself, who decided to mix the graphics with the cpu anyways? I've got AntiX-23.2-core installed on the hard-drive of the AO722 itself, it works well enough, albeit a bit slow. I guess nothing beats the speed of TinyCore or Kolibri.
Thanks again for your time, maybe a solution will be found yet!
Cactus2580
Edit: It is somewhat baffling that whatever the bootloader is, ISOLinux, I believe, will display properly yet the kernel itself will not. What sort of display server does ISOLinux use, and is there a way to force it to continue once it gives control over to the kernel? Resolution really does not matter much, if at all, in this situation. Getting it to boot up at all would be a huge victory at this point.
As per your questions above, I have attempted to move the entire /boot directory from one to the other. Pretty early on, actually. No luck. I have also moved the entire lib/firmware from -Core to DSL.R7, no luck there either.
As far as I can tell, after much screwing around on different forums and searches and the AMD graphics info, the issue I'm running into here is related to the kernel itself not recognizing the Wrestler HD6290 device, or improperly assigning memory regions to said device. I've tried blacklisting the amdgpu driver, I've tried setting radeon.cik_support=1 radeon.si_support=1 amdgpu.cik_support=0 amd.si_support=0, and vice-versa. I've tried forcing the radeon driver, and I have not been able to find a single bit of information on "downgrading" from amdgpu to radeon, only the opposite. It -seems- that every other instance of anyone asking a similar question anywhere on the internet has to do with the kernel automatically detecting their hardware using the radeon portion of whatever the kernel uses to detect video hardware, and them wishing to "upgrade" to the more modern amdgpu.
AntiX-23.2-Core, which does run a 5.10.224 kernel as opposed to 5.10.18x kernel, automatically detects it. Swapping kernels straight across makes for... can't find AUfs or some similar error. Swapping initrd from Antix-Core to DSL.R7 gets nothing. I've not only forced the entire /firmware from -Core to DSL.R7, with no luck, but I've also tried moving just the /firmware/radeon over, also no luck. I have been unable to find a list of what drivers are statically compiled into the 5.10.x kernel anywhere in the documentation that I've been able to find, and I've been unable to figure out a command to specify at boot flag time what display driver for the kernel to use, and DSL.R7 will not even hit the framebuffer or serial console or whatever it's called these days before running into rainbow snow errors, no X involved at all. Whatever the kernel is doing screws up well before initrd and linuxfs, so I'm not sure this is an error of having /lib/firmware/radeon, as opposed to the kernel itself lacking support for my card itself. Apparently x86-linux-free might also include the ATI driver, but I am unable to figure out how to invoke that, either.
Do we know if John(?) has trimmed down the firmware that exists within the kernel itself? This is the only explanation that I can come up with so far. At this point, my former curiosity has turned into disgust with the hardware itself, who decided to mix the graphics with the cpu anyways? I've got AntiX-23.2-core installed on the hard-drive of the AO722 itself, it works well enough, albeit a bit slow. I guess nothing beats the speed of TinyCore or Kolibri.
Thanks again for your time, maybe a solution will be found yet!
Cactus2580
Edit: It is somewhat baffling that whatever the bootloader is, ISOLinux, I believe, will display properly yet the kernel itself will not. What sort of display server does ISOLinux use, and is there a way to force it to continue once it gives control over to the kernel? Resolution really does not matter much, if at all, in this situation. Getting it to boot up at all would be a huge victory at this point.