raspberrypi
partially fix aarch64 BE on the zero2w
this PR allows booting big-endian linux on a zero2w
what works:
- serial console
- dwc2 gadget mode
what partially works:
- mailbox framebuffer byte order is backwards, but it does display text
- cpufreq is reporting incorrect clocks
- wifi (if the sdhci driver is modified to not use DMA, TODO)
what doesnt work:
- vchiq
- dma (TODO)
- sdhost
- dwc
untested:
- kms/fkms
Why is this something somebody (else) would want to do? It looks like most of these files are unmodified upstream files, so proposals for changes should be sent to the maintainers.
@pelwell in my case, i need a big-endian build machine, because of some issues with cross-compiling to a different BE arch
https://forums.raspberrypi.com/viewtopic.php?t=328078 there is also prior work, where somebody else already did these fixes, and they never got upstreamed
i can also see it being useful to test existing software, to ensure it handles byte-swaps correctly having these fixes merged/upstreamed, would greatly simplify producing an aarch64-be rpi image, where anybody can then test their software to see if it handles BE properly a software solution on the rpi is far cheaper then having to buy some exotic BE system
i had assumed that since all of those files are rpi related, it would be best to target this downstream fork of linux first, and then it gets upstreamed later? or would it be better to try and submit the changes directly to mainline?
fkms and bcm2708_fb are irrelevant to upstream, and TBH adding BE support to those feels like unnecessary churn downstream.
Using simple_fb should work instead of bcm2708_fb. The firmware looks for display0 as an alias, and /soc/fb being disabled in order to configure simple_fb.
A patch should only touch one subsystem, and requires a commit message and Signed-off-by tag. Debugging printk's need to be removed.
Whilst booting basic BE support may be reasonable, going for full BE support feels unnecessary.
Whilst booting basic BE support may be reasonable, going for full BE support feels unnecessary
yep, thats why i'm ignoring things like (f)kms and vchiq
the only thing i might do, is a Kconfig change, so they conflict with the BE flag, then it wont cause any problems and it will be clear that they arent supported
A patch should only touch one subsystem, and requires a commit message and Signed-off-by tag.
i'll work on splitting this PR up into several commits, and fixing all of the CI complains as well
bcm2708_fb throws numerous errors when unpatched, but i dont fully need it either, so i could just toss it in with the same Kconfig flag as vchiq and (f)kms
my end goal is to just have a headless BE machine with working network
the dwc_otg looks like too big of a task for me to fix
its using bitfield structs, and the compiler has reversed the fields, rather then the bytes so now every field the code is using to decode registers is mis-aligned and the whole driver is hosed fixing that would basically require duplicating every struct it uses, or rewriting the entire thing, and thats not the kind of patch i want to submit
dwc2 on the other hand is using a lot of shifts, so it may work better