Linux 5.15 kernel patch

[kayshinonome]

This compiles but unfortunately I do not have the hardware to currently test this. It was specifically done on 5.15.29

[Swizzy]

Just push additional commits to the same branch the pullrequest is from for any further fixes/changes, no need to close and redo the pull-request

[kayshinonome]

Ah, I'm sorry ^^

[CursedSilicon]

I built and tried TFTP booting it via XeLL on my 360 but unfortunately it seems to just display glitched text after a couple seconds and lock up entirely

I have the same problem with the 5.9 and 5.12 kernels as well

I'm trying to build 3.10.17 but it seems to need a much older GCC than the GCC 12 on Gentoo, so I will update later if I'm able to get that working

Image example of a capture of the consoles output

[Swizzy]

That looks like a memory corruption issue in the graphics side of things.

There was issues with the Corona motherboard booting up XeLL - if you tried this on one of those motherboards it's quite likely that there are patches that need to be added also for Linux to make it fully function there. However, the issue on Corona was much worse (no video output at all at the time). It still booted fine in the background, just you couldn't see anything because of the issue.

[CursedSilicon]

It seems to panic(?) or at least doesn't proceed far enough into boot to either become pingable or illuminate the USB keyboard

XeLL Reloaded seems to ID it as a Corona Phison/eMMC (4GB) unit (screenshot attached) so you're definitely right about it likely needing more patches (though I'm unclear if said patches exist?)

I was intending to run the unit headless for a project. Can I simply disable the video framebuffer and SSH into the device instead? With only 512MB of memory it's not the best for running an X server on in 2023 anyway ;)

[Swizzy]

If you can, i would recommend hooking up UART to see the console output there, you might see something there that could help. Unfortunately, i don't know if patches for the Linux kernel was ever made to work with Corona, when i fixed XeLL i was focused solely on that (and any homebrew using the libXenon SDK).

The fixes i did are the last 2 here; https://github.com/Free60Project/libxenon/commits/master?after=71a411cddfc26c9ccade08d054d87180c359797a+80&branch=master&qualified_name=refs%2Fheads%2Fmaster along with a few later corrections to handle video modes correctly (which may also be related), this was done 10 years ago tho.

[CursedSilicon]

I'd hook up a UART but unfortunately it's not my 360, so I can't tamper with the internals :(

I'll have to see about getting my own Corona unit for tinkering with to debug the issue in the long-term

In the short-term I tried just removing the entire graphics section and booting headless, but the system still doesn't seem to come up in any accessible state. I suspect there might be other gremlins lurking in the Corona board rev

[i-lost-my-bagel]

I'm having issues booting all of the 5.x kernels on my Falcon 360. I managed to get 3.10.7 built and it booted.

[CursedSilicon]

+1 to what @i-lost-my-bagel said. I purchased a Falcon model and am getting graphical corruption and can't SSH in

Seems to be similar to the issue with the the Corona model

[Swizzy]

+1 to what @i-lost-my-bagel said. I purchased a Falcon model and am getting graphical corruption and can't SSH in

Seems to be similar to the issue with the the Corona model

Corona had no video output at all back in the day, so no - it's not the same issue

[CursedSilicon]

@Swizzy I'll need to see about getting a UART attached. @ashquarky has also expressed possible interest in poking at it due to overlap with the later Wii U

[CursedSilicon]

@Swizzy Minor clarification

The graphical corruption issue seems to be (visually) similar to the one I reported up earlier in the thread
for the Corona

[CursedSilicon]

Additional,

I tested the 5.9 and 5.12 kernels (both on a Falcon model Phat rather than the known-bad Corona model)

The Sound, UART and RTC drivers all broke with compile errors and were disabled.

Testing with an absolute bare-bones nfsroot style config still yields the same kind of graphical corruption as other 5.X kernel builds

I'll try and get a UART installed on my unit for better debugging

[rwf93]

Attached a UART to the console to see what the kernel is doing, most I've gotten is an EP C0000000 from the output with my screen going corrupt. Have noted that it doesn't always go corrupt, but that could just be a random issue. Currently using buildroot to cross compile these patches and just transferring vmlinux to a USB (XeLL doesn't seem to like my network and crashes upon getting a DHCP response from my router). Not sure if that's the best route of compiling for this platform...

Note that also the console is a Falcon, I have tested this with a Corona, and it seems to have the same graphical glitches.

[rwf93]

Managed to get a login to popup over UART, framebuffer still seems messed up. I had to cross-compile the kernel by itself using libxenon, then with buildroot I just created a toolchain for PowerPC 970 as it didn't like libxenon. Input doesn't work, but I've managed to get this far.

[rwf93]

Managed to push the kernel to 5.17, I also got UART input. It's through polling and not an interrupt as I don't fully know SMC interrupts. To my knowledge, there is no handling from the CPU to the SMC for serial RX/TX.

As for more driver bugs. Networking is messed up, seems to have some issues with xenon_net_open. On 5.17 it complains about an Incorrect netdev->dev_addr (I have not really investigated this, this could be an issue with the headers I'm compiling buildroot against...)

Logs of the boot for 5.15.29, 5.16.0, and 5.17.0:
5.15.29.log
5.16.0.log
5.17.0.log

P.S should open a PR and commit some of these changes to the patch? This one isn't merged yet so I'm kinda waiting for that. I suppose I could fork this one though.

[rwf93]

Managed to look into more networking. It seems that the issue on 5.17 was netdev->dev_addr_shadow not being the same as netdev->dev_addr. I Just memcpy'd the value in addr->sa_data as a quick hack to get around the error.

I will probably investigate that more later, but for now: Still issues with xenon_net_open I've reduced the stack trace it to xenon_net_init_ring, or more specifically drivers/net/ethernet/xenon/xenon_net:322. It seems that pci_alloc_consistent is returning a null pointer.

I am not a kernel developer, nor I do fully know the reasons for why this could be happening. The most that seems that could trace back to it is the bug/warning at arch/powerpc/mm/mem.c:342

[rwf93]

I managed to get network to work. For 5.17 it was above with copying the mac address into dev_addr_shadow however, the main issue with pci_alloc_consistent was that it was forcefully using iommu (found with a little bit of kgdb help of course).
I have never worked with dma allocators in the kernel but I managed to force it to use the regular dma by forcing tp->pdev->dev.dma_ops_bypass to be true.

It at least gets around the issue of the driver outright crashing, and actually functions. I am able to ssh into a 5.17 kernel with absolutely no issues, as well as get a simple http server running.

P.S: Yes I am developing on windows. I don't actually have any space for a linux install at the moment. Please do not kill be for such heresy!

[rwf93]

Managed to get nearly all drivers to work. Seems that someone forced the all ops on all drivers to use iommu. A quick comment out of arch/powerpc/platforms/xenon/pci.c seemed to fix them all.

Made some patches for 5.17 here.
(Note, there is a useless nand driver that I'm working on and forgot to remove. Woops!)
I also made patches to get gcc-12.3.0 working here (note that it was originally made for libxenon, but found it works pretty well with buildroot).

Still need to work on the framebuffer being garbled, but so far nearly all drivers (minus SATA, FB, and audio) seem to work. I also tested cross compiling Cuberite and fixed some of the endianess issues that were mentioned in this issue (funnily enough @CursedSilicon created it).

[CursedSilicon]

Whoops sorry for the late response.

I'm glad to see someone smarter than me was able to get a handle on what was breaking

There's one other user in my retro Discord that wanted to look at it a bit in between Wii U Linux kernel stuff, though I don't know if they've touched it yet

I'll forward the above post to them and see if they have any insight that might be useful

[i-lost-my-bagel]

got gentoo booting over nfs with the kernel patches from @rwf93

[rwf93]

Hello again,

I managed to get 5.18-6.0.0 (woot!) to compile and run. There are some issues with 6.0.0 in that the framebuffer attempts to create a 65536x65536 resolution and subsequently crashes the kernel (most likely due to it eating all the ram in that attempt). Likely an underflow, but I can't debug it because it happens before kgdb can attach. Possibly I can early attach it? No idea.

Main issues with porting to 5.18/5.19 were some changes like removing the regular PCI functions (as they were replaced with DMA functions).

As for 6.0.0 it was relatively easy, just some include errors mainly with of, of_address, and interrupts.

I have noticed some small bugs with 5.18/5.19, sometimes the network driver crashes. I haven't been able to debug it enough to see the reason of it.

You can find the branches, here.

(also I should probably get gentoo running, albeit I have never touched gentoo, so I have no idea in that regard)

[CursedSilicon]

@rwf93 Does the 360 support DMA for those devices? It's (arguably) fairly new so I would assume it might. But then again, embedded device and all that.

If you want some assistance with Gentoo in particular there's a few of us over in my retro computing Discord that may be able to assist as well. @i-lost-my-bagel in particular has been posting her progress on and off with kernel tinkering (and I believe is running Gentoo on her 360)

https://discord.gg/gnHYxEBC

[rwf93]

DMA itself is not particularly a new thing actually, actually one of the first instances of a DMA controller would be the Intel 8257 PDIP. The kernel itself handles DMA ops by a per pci implementation basis. The patches for the (5.9-5.15) Xbox were using IOMMU DMA ops, which the console does not support as that's too new. I fixed it by not using IOMMU DMA ops for the console in it's PCI implementation.