Graphics error after boot menu, boot unsuccessful.

[Cactus2580]

Outstanding work.  Need a bit to process. 

On the off-chance you are around at this minute, what happens if you just append
vga=ask
Do you even get any text at all or does it stay rainbow snow?

Sorry, didn't get to this earlier. If I append VGA=ask it does the same thing as if I use the F7-ask boot flag presented by the bootloader. Green text asking me my resolution. Picking the correct resolution ends in undefined video mode, picking any other resolution ends up with more rainbow but less snow, some of them are just endless scrolling lines. Either way, I've tried every option it gives and no luck so far. Did see a bit on forcing the Radeon driver using kernel commands from a Google search last night, so will try that a bit later and report back. 

Thanks again for your help!

[grindstone]

Appreciate the report. Thank you for the patience and for all the work. Was wondering if you tried xorg=radeon on the RC7, too. Got interrupted today as well so gotta hit it another later but more to come.

[Cactus2580]

Appreciate the report.  Thank you for the patience and for all the work.  Was wondering if you tried xorg=radeon on the RC7, too.  Got interrupted today as well so gotta hit it another later but more to come.

No worries! As for xorg=Radeon, yes, have tried that to no effect, but that was before moving firmware from AntiX to DSL so I will give it a shot on the reroll as well and see if it is any different.

[grindstone]

Loaded amd graphics fw pkg, made new initrd for stock 5.10.188-antix1-486-smp (~14MB gzipped):
https://drive.proton.me/urls/C5XGJGRMH0#V8UsycwwCqJr


(Still needs the CEDAR and maybe PALM under /usr/lib/firmware/radeon directory I think, but if you threw them all in /radeon it should be fine).

Yes, I know, now that it's done I think to ask if you tried the whole -core /boot directory, but...

Lemme know.
------------
Edit:  Staring at Debian kernel patches, it needs the whole /radeon directory. 

Code:

Subject: radeon, amdgpu: Firmware is required for DRM and KMS on R600 onward
Date: Tue, 08 Jan 2013 03:25:52 +0000
Bug-Debian: https://bugs.debian.org/607194
Bug-Debian: https://bugs.debian.org/607471
Bug-Debian: https://bugs.debian.org/610851
Bug-Debian: https://bugs.debian.org/627497
Bug-Debian: https://bugs.debian.org/632212
Bug-Debian: https://bugs.debian.org/637943
Bug-Debian: https://bugs.debian.org/649448
Bug-Debian: https://bugs.debian.org/697229
Bug-Debian: https://bugs.debian.org/1053764
Forwarded: no
Last-Update: 2023-11-08

radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.

radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.

Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it
is missing, except for the pre-R600 case.

[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.

[grindstone]

Not sure it's of any help, but there's a whack of new AntiX kernels in the "waiting" repo...which of course figures
  cussing_too.gif (Size: 2.84 KB / Downloads: 4) because I spent last night making proper header and kernel .debs (~60MB)  with DRM_RADEON built-in (on a box with the amd firmware package installed).  Unless you can (maybe?) chroot (from -core) into a DSL root, I don't know how to get the proper .debs in there (which would generate the new initrd it needs, too) the right way and still keep it small.  FWIW, there's a "bare" vmlinuz in there, too, if you wanna thrash yourself one more re-squash but if the others didn't work, confidence is low-ish.