X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.01

@kas1e
@kas1e
I removed PCI NIC card, but still I have two PCIe graphics cards and USB 3.0 controller connected. Still no success with other SATA.

This is addresses used by CFE:



What output can help?

@Tuvok
Quote:

Cool, and yeah, i see other reports about cls/execute, just those for now not very important (but i noted them for later, of course).

Interesting thing which i found now, is another CFE bug (probably) which we hit now when Realtek card in : see the logs without, we have: IDE unit 0: ,etc at boot of CFE, while when we add realtek , then we have: SATA unit xxx: !

That mean than CFE, when we just add PCI device and enumeration changes, simple change the handler patch to IDE or to SATA , and i think its just another CFE bug where it simple goes wrong route or something. Because even if we have SATA unit ... in the boot log, we still can't use channel1, and we still in the same legacy ide emulation mode, so ..

I need to dig in in CFE disassembly again to see why there 2 different routes and how the differs at all.. For now, all i can say, is that when this IDE unit vs SATA unit in boot log appears , it simple swap IO ports. Like

Ports without Realtek (IDE unit: xxx in log): sata: BAR0: 0x1030, ide: BAR0: 0x1040
Ports with Realtek (SATA unit: xxxx in log): sata: BAR0: 0x1040, BAR0: 0x1030.

See, simple swap. So of course patch didn't work as i doing it over "IDE" legacy. It should be easy to fix, because it's anyway all "legacy". I simple didn't at moment why there at all different printf and port swap, because even if we have "Sata unit .xxx", like, it should works as SATA, CFE anyway can't deal with single hdd when it "slave", so mean it's the same IDE legacy emulation, just strange printf + port swap.

Need to dig in !


@Sailor
Quote:

See, in your output you also have SATA Unit: xxx instead of IDE Unit: xxx

So it seems same issue for you : you have more PCI cards added, some of which make CFE think that by some reason we switch from IDE to SATA whatever code path is it (will check that). While i am at it, can you also what card you need to remove (second PCIe graphics card, or usb controller, or both) , so CFE on boot will says "IDE unit: xxxx", and test if patch work then.

Thanks!

@Tuvok

Quote:

Yes I has tried that. The issue is CFE is corrupting the file data. I haven't been able to run a batch script from USB for years. It's related to the buggy FAT driver. The common solution is to reformat as FAT16. The FAT32 code is corrupt somehow. I've formatted and repaired from Windows but CFE always breaks with FAT32. Maybe it cannot handle sticks over 4GB or something. I've mostly given up and use OS4 to copy files to a FFS volume where it can work from.

@kas1e

Quote:

Yes, a real crash with a machine check exception or whatever it was. Unless you have a terminal attached, blink and you'll miss it. While CFE crashes and instantly reboots.

Quote:

I wonder if that FFS seek bug stops loading large files from FFS? For example, it was thought for years that Linux could not boot from FFS, because it broke somehow or just stalled. I did some digging and found out that Linux could boot from FFS, but the problem was the FFS loader has a size limitation. It was close to 16MB but could be around 14MB. Similar to the old UBoot. So Kickstart size would be limited by the same amount I imagine.

I thought it may have been because CFE mapped 16MB of RAM for itself and anything over broke it. But, when loading direct to other memory like 0x24000000 it shouldn't matter. Turned out that, unlike the rest of the Linux industry, the X1000 kernels were uncompressed so it was trying to load in a 30MB file on average. It couldn't cope with such a big file and would break. I tried compressing one and it worked.

But, I wonder why it needs to seek. If it's loading in a file it just needs to locate all the blocks from the file headers, then do a read block in sequence. But amigaboot.of does send a seek command before a read command when using OF API. So it cannot escape seeking.

Quote:

Okay, that makes sense. So just below the 0x7CD00000 area amigaboot claims.

Quote:

Will run again and take notice of output. If it matters I also have an RTL8169 card in a PCI slot.

Quote:

Was that a lot of work? I suppose the OF API doesn't have any commands for setting PIO or DMA? The default PIO0 mode would be on purpose for the safest boot option.

Quote:

I've read that and didn't really take notice because I knew it was always 8 bit. It says BPP is 8. 800x600 in my case. With 0x0340 per scan which means 832 bytes per line. So 800 bytes with some padding. 100 characters across.

I wondered why it is using a bitmap mode and not using a proper text mode? Bitmap is nice for logos but CFE is displaying text. Especially on terminal. Seemed they took the hard road to me. You've got hardware accelerated VGA text modes giving you a matrix like a C64. Instead they do it the hard way and need to write font rendering routines as if it was a Mac or Amiga with no text modes.

And then Linux always present the confusing double penguin sprite. Never seen it on a PC. Must be a PowerPC thing.


Can RadeonRX support 8 bit modes? So this is trouble all along? We were told it was because RX cards have a UEFI BIOS and didn't support the old VGABIOS in CFE or something like that. Or is it a combo of these issues? You couldn't have hacked a UEFI x86 emulator in there as well already?

@kas1eQuote:

I removed all PCI/PCIe cards except fist graphics card.
Connected devices:

Close to cpu:
Port0: SSD Amigaos 4.1FE partitions incl. FFS amigaboot.of
Port2: DVD

Near to case - rim of motherboard
Port1: HDD linux partition
Port3: HDD amigaos 4.1u6 partitions incl. FFS amigaboot.of

SUCCESS:

HDD in Port3 is mapped as ide 0.1 and I can boot from it

tested more configurations:

GFX card + PCI RTL - not works:


dual gfx card - SUCCESS:


GFX card + PCIe USB3.0 - not works: