Ryzer

Most likely USB OTG unless there are any USB related errors in the kernel log. In the case of OTG, there should be auto detection via the ID pin which sets the device role but I have never known this to work. Fortunately it is possible to set the mode manually to host in the device tree. I tend to use the following device tree overlay: /dts-v1/; /plugin/; /{ compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20"; fragment@0{ target = <&usb_otg>; __overlay__{ dr_mode = "host"; }; }; }; just connect via serial or ssh, once logged in use nano and paste in the text above. Save it as something like sun4i-usb-host.dts. Then run armbian-add-overlay sun4i-usb-host.dts. This automatically compiles the overlay and places it /boot/dtb/overlay-user/ The RAM may just need fine tuning slightly. As far as I know it is not possible to adjust the RAM frequency in uboot once compiled, only check clock rate via sudo cat /sys/kernel/debug/clk/pll-ddr/clk_rate. I might have to try that on my pcDuino2, I didn't think the A10 would be powerful enough to run Octoprint. All the best Ryzer

Right so 1GB - display framebuffer allocation. Can you confirm HDMI works as it been a while since I built an system image with 6.1 kernel. I dont recall display issues, just problems relating to SPI at the time. Anyway kernel 6.1 is no longer supported, even as a legacy kernel. The earliest kernel you can now build with is 6.6. I am suprised that the mirrror archives I have looked at so far do not feature any 6.6 kernel builds for the Cubieboard. Thats not to say it would be impossible to compile with an older kernel but could prove more trouble than what it is worth. I am interest to see what if encounter any stability issues when booting an edge kernel. Interesting, that is the exact same RAM chips used on the pcDuino2 but the additional text enscribed is different. Just to be safe can you run memtester to see if it picks up an errors. For example: sudo memtester 64MB 2. Even without re-compiling the entire system, what we can do is replace the targeted board dts. This should be doable given you already have a serial link, but you will need to catch uboot early on to hault to boot process to get a uboot prompt. Then running setenv ftdfile sun4i-a10-topwise-a721.dts to see if the onboard display works. *update* - upon checking kernel sources the previously mentioned sun4i-drm patches are no longer necessary as the changes appear to have been included in the latest sub revision of kernel 6.12.30 All the best Ryzer

Right, I was thinking what if you try forcing a different mirror via DOWNLOAD_MIRROR: https://docs.armbian.com/Developer-Guide_Build-Switches/#hidden-options-for-advanced-users-default-values-are-marked-bold I cant guarantee this will work though. While A2 cards offer better performance, they are not as well supported. That is still the case to the best of my knowledge. Right one of the caveats I did find with getting HDMI working was the likelihood of increased taints so I think this patch is also required: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c?h=v6.14.11&id=ae048fc4f96d716a2ef326bd6e894694057c078c It is a possibility that either the RAM could be faulty or just unstable and need fine tuning. The problem is that really old system images tend to be less picky about RAM issues and will still try to boot. Normally I would say try installing memtester but that seems to detect failures in the most recent kernel yet my 6.6 build found no memory issues. Besides the originally Android image, have you tested with one of the archived images? More importantly what exactly are the RAM chips used on the board? Can you confirm the actual RAM capacity? From my experience, my second pcduino2 board with the Skhynix RAM had these sorts of problems. Sorry I cant be of more help Ryzer

In that case I would strongly recommend purchasing an A1 rated SD card before trying anything else. If you are getting MMC related errors these are definitely related to the SD card rather than RAM. Once you have done this then we can look into DRAM config if need be. Trying to enable the display post build is kinda tricky. If it was just a matter of adding the HDMI display nodes, then yes that is normally possible however the display driver needs a slight patch in order to work. Now if you had kernel headers installed you could try to build the driver however another current problem means that custom loaded modules seem to not load/unload properly. Seeming as you are using the pre-built Cubieboard images, it already has the display nodes in place but not the recent patches to sun4i-drm. Looking again at the build log you provided earlier it looks like something is blocking the download of bookworm distro which is why it is failing. what happens if you trying ping apt.armbian.com? Given that this issue happens with bookworm, I wonder if it will also happen if trying build with Ubuntu Noble instead. I am currently working on formally including the display patches on my latest development branch so please bear with me. Best of luck Ryzer

That's completely understandable. Given how long the A10 and A20 have been around, I wouldn't expect recent kernels to be thoroughly tested on them. Even from my perspective HDMI is more of a nice-to-have rather than a priority. I realize I might be an exception in this, but I prefer trying to fix issues myself rather than relying on someone else to do it. The only real barrier is my own lack of knowledge. That said, I believe I’ve firmly gotten to grips with device trees now. I acknowledge that I still have some way to go before I can confidently dig into driver development myself. I really appreciate the effort from you and others in making the build system so easy to use. Thanks to that, I’m able to apply my own fixes where needed with relatively minimal technical knowledge of the intricacies of Linux. I actually noticed the change today while browsing kernel.org. Exactly what I had in mind.

@Igor I can only guess that something has changed within the drm framework somewhere between kernel 6.6 and 6.12. After a bit of digging I did find the patch mentioned in my previous post, which I can confirm does restore HDMI functionality albiet with what appear to be minor errors. Taken from Pcduino3: ryan@pcduino3:~$ sudo dmesg | grep drm [sudo] password for ryan: [ 1.000426] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0caec14) [ 1.000666] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0caec14) [ 1.001260] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0cae380) [ 1.001797] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0cae380) [ 1.002745] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.002787] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0cac870) [ 1.003623] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.003671] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0cac870) [ 1.005703] sun4i-drm display-engine: bound 1c16000.hdmi (ops 0xc0caf610) [ 1.007882] [drm] Initialized sun4i-drm 1.0.0 for display-engine on minor 0 [ 1.068719] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 131 [ 1.068755] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 129 [ 1.126922] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb frame buffer device [ 4.022304] [drm] Initialized simpledrm 1.0.0 for 7e000000.framebuffer on minor 1 [ 4.150136] simple-framebuffer 7e000000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device [ 4.537321] [drm] Initialized lima 1.1.0 for 1c40000.gpu on minor 2 [ 8.416996] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 8.783119] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 8.785117] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. kernel 6.14 already has the changes adopted so does not need to be patched. I appreciate that boards like the pcduino2 are over a decade old now and not likely to achive the same attention as something like the orange pi zero.

That is worrying, I wonder if there could potentially be issues with the RAM, which could either be faulty or clocked higher than a level it is stable at. Reffering back to the fex you provide earlier it suggest a dram value of 384, so you may have to the def_config file to include the line CONFIG_DRAM_CLK=384. Is the card just class 10 rated or is it an A1 SD card? https://docs.armbian.com/User-Guide_Getting-Started/ Strange it should auto login on first boot. What it should be request is to set a new root password then confirming that password. Could you please provide a screen shot of the login screen you are greeted with. Alternatively it may be possible to set the root password external to get around this issue. Please see: https://docs.armbian.com/User-Guide_Autoconfig/ Strange never encoutered that before, have you tried pulling the latest version of armbian build to see if it fixes it? Unfortunately I have not had a lot of luck in trying to get WSL2 to work so I have stuck with virtual box. Worth a shot with the pre-built images, but I dont believe the Cubieboard is in a much better state. best of luck Ryzer

Ok that is a promising start at least. Are the 'BUG: bad page state messages' every boot or occasionally? The route cause will probably be difficult to find, possibly a deep route kernel or hardware issue. I tend to find that sometimes I will get the bad page state messages and then on another occassion get no kind of faults. You shouldnt need to enter any credientials on first boot, that only applies to setup over network connection. Once you have been able to login and if wireless works then you can install memtester to see if that picks up an errors. not a problem, looking forward to hearing your progress Ryzer

Hi pcduino2user, Nice to see a fellow Pcduino user, I guess not many people interested in over a decade old hardware at this point. I try my best, I am by no means an expert, most of my current changes are just corrections to the device tree. Anyway, there appear to breaking changes in kernel 6.12 which breaks hdmi output. The intial patches for adding the hdmi display nodes are in my pcduino2-and-3-improvements branch however they are for much older kernel versions so need to be re-created, something I plan to do within the coming week. Additional the display driver needs a minor tweak. I currently have a userpatch derived from: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ Thanks Ryzer

Right to clarify what I described earlier was the patch creation process, where you would modify an existing file or if the file does not exist you would create in the relevant. After running for a bit the build process will pause. At this point you would need to open a new tab and navigate to cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/arch/arm/boot/dts/allwinner. Here you would need to amend the sun4i-a10-topwise-a721.dts. According to the dts it already has the panel node so the on board display should at least work unless the driver is broken or device tree bindings have changed. Unfortunately I havent worked with panels so cannot provide much further assistance for other than confirming that an entry exist in the simple panel driver. sudo modinfo panel-simple | grep starry [sudo] password for ryan: alias: of:N*T*Cstarry,kr070pe2tC* alias: of:N*T*Cstarry,kr070pe2t ryan@pcduino2-1:~$ Normally to get hdmi to work you simply have to enable the hdmi nodes plus create a hdmi connector node. I have attached the patch that I use on my pcduino2, applying the same alterations to the dts of the topwise's dts should work. I have had issues with hdmi display in 6.12 which I found a work around for but not perfect as we have to modify the hdmi driver. From What I can tell the problem is related to atomic check function: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ It may be fixed in kernel 6.14 but I havent tested it yet. save the changes in your text editor and exit. Return to the tab running the build script, hit enter and it will generate a preview of the changes and ask if you are happy with the changes or not. type 'y' to accept. Luckily the build process will helpfully walk you through these steps. Once the build process has finished go to output/patch/. and rename the newly generated patch something useful so that you remember its purpose. Then move it into patches or userpatches. Which is up to you but personally, I prefer to have my patches in userpatches unless it is something I plan to merge in future. whenever you run git pull to fetch the latest version of armbian build, the patch directory is likely to be updated whereas userpatches is not affected. A caveat with userpatches is that full directory structure is not pre-existing so you have to manually create it, mirroring the patches directory. Also note that userpatches are applied after patches in the patch directory. Did you clone Armbian build directly or are you work off your own fork? Now what i tend to do is rerun the build process to check that the patch was applied successful. So rerun ./compile.sh BOARD=topwise-A721 (Replace with the name used in your config file) BRANCH=current RELEASE=bookworm kernel-patch. if successful it should appear in the list of patches and if applied under usepatches it will helpful be the last entry on the list. Unless you have any further patches to apply you can then go on to running a full build. I am suprised no one has yet done a video on the patching process yet Have you attempted disassembling the tablet to check for any solder pads present which could be the serial console? If there is then it may be possible to hook up a usb to serial converter. This could at least be a solid indicator to confirm that the device is at least booting. best of luck Ryzer pcduino2-hdmi-enable.patch

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

My mistake I was suggesting based on prior comments found on the Orange Pi Zero3 thread but after reviewing again it looks like the port part of the overlay is no longer necessary either so as Kris777 suggested just the interface name should hopefully now suffice. According to wiki, the main i2c interface should be i2c3: https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2

HI, I dont believe it is necessary to recreate the Topwise A721 dts as it should already be included in the kernel sources used. What most likely needs to be done as a minimum is config file so that the Armbian build system recognizes the board and knows how to handle it. Admittedly I have never added a board so I can only speculate. A problem you may face is that the internal LCD may no longer work with the latest kernels. best of luck Ryzer

oh right, then maybe there is a few things you can help me with in future as I still getting to grips with my esp32. Don't worry it look difficult at first but gets easier. Now I believe I know what the problem, on the overlays line modify it to i2c0-pi and i2c1-pi. This appears to be a common problem with armbian-config overlay functional. My own A10 and A20 systems also has this problem as well.

Hi Yordan, Are you sure you have correctly enabled the i2c overlay on your board? what is the output of cat /boot/armbianEnv.txt? If something is showing up even with nothing apparently connected they your are likely targeting a different bus. It is possible what you are seeing is the address of the internal pmic although this normal shows up as UU. Best of luck Ryzer