Serby

@Stephen Graf this is the overlay ? But how about in the main devicetree, do you have module called spidev@0… @1.. and make sure it’s not “disabled” that’s what supposedly loads the spi into /dev/ … there is supposed to be an spidev in the kernel, but maybe your overlay needs that too address the “disabled” to “okay” ( I assume the main device tree would be set disabled and depending on the overlay you pick will enable / change the corresponding spidev@X to status=“okay” also *if I’m not mistaken I think there is i2c-dev also so for example if &spi1 {… ; spi@X {… status=”okay”…}; spi@Y{… status=“disabled}; … }; I’d assume spi@X, Y would be different overlays for the different CS options so like dtoverlay=spi1-Xcs , spi1-Ycs would have their own overlay or some function maybe ? That sets the status=“okay” enabled to the corresponding one @Stephen Graf i mentioned to look at the raspberry pi repo here is how they do it ( also go up to the parent directory of that file for all the examples, and the README there also explains what things do.. * https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/overlays/spi1-1cs-overlay.dts#L40 obviously the settings going to be different for OrangePi but Atleast you got something to compare / work with ** I mention the spread sheet as you go along, mainly just for Documents purposes later on. So others using it know which overlay corresponds to what gpio pins / function. If you do it as you go will save time having to go back and do it again + it kind of acts like a checklist

In that datasheet, it shows the ALT pins, most of this SoCs has a pin mux, and depending on which alt setting you used for 1 pin sometimes dictates the whole pinout for the rest of the pins in that ALT “group”. also a lot of this SoC have programable Pull Up / Pull downs. And/or the PCB manufacture adds a pull up/down on the pcb itself … or for example if the spi NAND that’s on the board already, if for example it’s on spi0-0 since it’s already present, if you try to switch spi0-0 to some other pin the IC is still physically connected which might cause SoC pin to PULL some kinda way that conflicts with the ALTs pin Pull * and sometimes if there is no pull direction set depending on the chip and pcb can cause some parasitic capacitance and drive the pin high when it’s meant to be low, so as a precaution you might want to force the pin the direction it needs to be and not leave that setting unset ( this usually isn’t an issue but I remember the raspi 1B had this issue ), just mentioning it cus if theirs some weird unexpected behavior happening , this is often overlooked, bang your head for days and might be something along this lines * ah yeah and double check that the data-sheet pins on the SoC match the numbering scheme on the PCB pin outs , and if there is a difference between the two figure out which set they using to describe the GPIOs … remember that was a headache also , cus the pcb manufacture might be calling the GPIO header pins 0-15 for example but on the soc its p30-45 or w/e ** I remember when I was messing with the crypto chips ATTECC608 i2c chips, I had a bad batch of gpio jumper cables , and wouldn’t read on the bus untill I fanageled with the cables… couldn’t figure it out for the longest time lol stick the multimeter everything worked but the little sleeve was wider then the gpio pin , and the pin would rest on the plastic and not make contact 😐 , similar to your Ethernet cable issue, rule that out before you jump to conclusions , but as far as SPI is concerned , if the CS pin is causing issues backtrace SPI1, if it has spi1.0 1.1 1.2 etc all the spi1-CS pins need to be low ( or high?) , cus if one is set in the high ( or low?) it’s going to block the bus cus it’s signaling to the bus that it needs the bus, and could cause the issues mentioned above Maybe later today when I hit the pc I’ll make a spreadsheet / chart… based off that datasheet similar to this https://elinux.org/RPi_BCM2835_GPIOs… or as you go fill in a spears sheet there in excel or w/e cus that helps a lot as a simple look up table , the one in the datasheet is okay but is mixed in with a lot of other things that might be confusing

If you’re still taking suggestions there for overlays … don’t forget the g_ether (usb gadget Ethernet support) a good reference for overlays would just be the raspberry pi overlays directory… just got to change the actual settings of the pins and what not… but it’s a good base that’s well documented, including things like the hdmi hot plug etc, the video memory… one thing I noticed if you are doing the dtc with the gpu “okay” thing… it works on the “beta” 6.1 Debian from OrangePi, but I noticed that the CMA memory ? Could be wrong acronym … but I didn’t find it in the DTB /DTC when I was changing the gpu from disabled to okay… but when you run the command `dmesg | grep cma` in terminal it shows in the “beta” 6.1 Debian is only 128mB … but I think The CMA is shared with everything not specific to the GPU, but that would most likely need to be raised maybe by like 64mBs or more for mesa / Mali panfrost driver? But if your up to making that an overlay then depending on users need they can just set whatever value they need… ref: https://developer.toradex.com/software/linux-resources/linux-features/contiguous-memory-allocator-cma-linux/#intended-audience https://lwn.net/Articles/396707/ oh and there is something with the ETH or EMAC that’s kinda strange but if you look at bottom of page 16 it references 2 interfaces emac0 10/100/1000 and emac1 10/100, which really doesn’t make sense to me, ( I have an OrangePi zero2w ) I don’t have the external adapter board but it claims it’s 10/100… but if you read in that datasheet ( I know it says h616 … but that’s what pops up when you click h618), it says that the 10/100 (emac1) interface is internal only… so that means the 10/100/1000 (emac0) is what’s actually exposed to the pins, why they need a second IC for the 10/100/1000 on OrangePi zero 3 🤷‍♂️or why the zero2w only has 10/100 ( maybe the pcb design or w/e couldn’t be routed for the 1000 speed 🤷‍♂️) But maybe something there that they might have missed that might address the Ethernet bugs or issues you had encountered / patched ? Like maybe something is mapped incorrectly that the internal 10/100 is being used ? I assume the internal one would be for bridging / vlans like maybe for the g_ether I mentioned above ? So it has its own dedicated phy / bus 🤷‍♂️ another thing, remember the mail GPU is just the 3d acceleration hardware it really doesn’t address anything about the other hardware on the chip ref: page 12, the 2d graphics (G2D) or the “display engine”, 🤷‍♂️heh a lot of random things like that I don’t understand or is not clearly documented anywhere but the datasheet, but then if you look at the arm website for Mali-g31 ref: https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel notice it mentions: “Note that these components are not a complete driver stack. To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard Arm commercial licence to all Mali GPU customers.” So if Sunix / allwinner doesn’t provide that then I guess we out of luck for that part of it… or maybe it’s just already in the mainline kernel or panfrost mesa driver 🤷‍♂️… I also tried installing Wayland GNOME as an alternative login / desktop manager option, but that just crashes after awhile and the CPU usage is madness just moving the mouse across the screen heh. But according to the docs I think it specifically says the Mali supports x11 Wayland Vulcan and the non windowed one (can’t find that doc ATM) but also I think you mentioned you looked at this , but this might address the hdmi issues etc in the case you were referring to something else in cedrus video graphics docs https://linux-sunxi.org/Display