Jump to content

Sean Perez

  • Posts

  • Joined

  • Last visited

  1. Ive been trying to figure something out with the orangepi zero2w, specifically for video decoding. Ive gotten the 3d engine working and benching fine with opengl, and I installed this when you first posted it for the hardware video acceleration, but what I been trying to figure out in general for the GPU and or the video, is the CMA memory... I think this might be the limiting factor in all this, and is a big oversight on alot of this video stuff. Im not running armbian at the moment but on the orangepi os running 6.1 debian I run this cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 117696 kB (128 mB) so depending on the different kernel / SoC builds debian, armbian, custom stuff... everyone probably has something different. And from what I have read in other posts here and within the Raspberry Pi community, the CMA allocation seems to be the most important part for video and 3d hardware acceleration, since its not in the "user space" it technically not have access to the whole RAM only the CMA (128mB in my case). I think 128 is enough but if your running some thing crazy it could need more as in other post in this forums that people have pushed 1GB ram board to a max of 512mB~ Ive read that the CMA can be in the device tree which seems not to be the case for the orangepi zero2w debian 6.1, so im trying to figure out where else I can change that, I figure I post this here, maybe someone has more insight or has tried changing the CMA for this driver and has verified results?
  2. yeah but your missing the spidev@0{} thats what lets it be seen in /dev/ this is the 6.1 debian opi dtb... spi@5010000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8> reg = <0x5010000 0x1000>; interrupts = <0x00 0x0c 0x04>; clocks = <0x02 0x4f 0x02 0x4d>; clock-names = "ahb\0mod"; resets = <0x02 0x1c>; pinctrl-names = "default"; pinctrl-0 = <0x35 0x36>; dmas = <0x24 0x16 0x24 0x16>; dma-names = "rx\0tx"; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7e>; spidev@0 { status = "disabled"; compatible = "rohm,dh2228fv"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; flash@0 { status = "okay"; #address-cells = <0x01>; #size-cells = <0x01>; compatible = "jedec,spi-nor"; reg = <0x00>; spi-max-frequency = <0x2625a00>; }; }; spi@5011000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8> reg = <0x5011000 0x1000>; interrupts = <0x00 0x0d 0x04>; clocks = <0x02 0x50 0x02 0x4e>; clock-names = "ahb\0mod"; resets = <0x02 0x1d>; pinctrl-names = "default"; pinctrl-0 = <0x37 0x38>; dmas = <0x24 0x17 0x24 0x17>; dma-names = "rx\0tx"; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7f>; spidev@1 { compatible = "rohm,dh2228fv"; status = "disabled"; reg = <0x01>; spi-max-frequency = <0xf4240>; }; }; im not 100% sure but im pretty sure the fact that it's in main dtb might not let it overlay on it? (oh I just realized my phone and my PC have different usernames -Serby) ** @Stephen Graf since I was here I decompiled the overlays in orangepi 6.1 debian /tmp/sun50i-h616-spi1-cs0-cs1-spidev.dtbi fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff 0xffffffff>; spidev@0 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x00>; spi-max-frequency = <0x2faf080>; }; spidev@1 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x01>; spi-max-frequency = <0x2faf080>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; spi1_cs0_pin = "/fragment@1/__overlay__:pinctrl-0:4"; spi1_cs1_pin = "/fragment@1/__overlay__:pinctrl-0:8"; }; }; /tmp/sun50i-h616-spi1-cs0-cs1-spidev.dtbi /tmp/sun50i-h616-spi1-cs0-spidev.dtbi /tmp/sun50i-h616-spi1-cs1-spidev.dtbi dunno if you had those or not but I guess they use that other syntax of fragment@... but .. it seems that raspi goes that also, I dunno, gonna see what I find im like you never really messed with this beyond changing a line here and there... what im trying to find is the CMA memory which I think should be set in the reserved-memory reserved-memory { #address-cells = <0x02>; #size-cells = <0x02>; ranges; secmon@40000000 { reg = <0x00 0x40000000 0x00 0x80000>; no-map; }; }; but its not i think the secmon thing as per some kernel update email mentioned that is for kernel boot or something ... but the CMA is set in the orangepi debian 6.1 but i dont find it in DT secmon@... { ...}; cma_reserved@48000000 { // Adjust the address based on your system compatible = "shared-dma-pool"; reg = <0x0 0x48000000 0x0 0x8000000>; // Adjust the size based on your requirements no-map; }; but im not 100% convinced about that yet but im seeing things on other boards that are showing CMA at like 512mB ++ (depends on the memory size your board has) but mainly its for heavy GPU decode encode ( on those other boards) the default on the orangepi debian 6.1 is cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 117644 kB and its hardly using anything ( and im running desktop xfce) dunno how big a deal this is but according to this posts i been comming across mentioning this and with GPU hardware acceleration on other SoCs.. just dunno where to add this without breaking something LOL
  3. Kinda a long one ... but it's been like 1 week trying to get u-boot and all this stuff correct on my own not specific to armbian. But, been searching all over for all sorts of things, made comments on the uboot/uboot github etc.. I'm learning this whole linux uboot etc... maybe this might be useful, any input or corrections etc let me know. The uboot/uboot github you got to pay attention to the branches... The orangepi_zero3 is almost identical to the orangepi_zero2w. but in no way is the orangepi_zero2 and zero2w compatible don't even bother looking at that, except for maybe the the eth phy , but since the 2w doesn't have that, I don't see a chip in docs, or on the board (maybe on the expansion board but I don't have one, those docs, same don't really show anything unless its built into the rj45 board connector or just uses the SoC). The zero3 does have a `motorcomm=y` the chip (10/100/1000) that is in the defconfig from uboot/uboot.. the zero2 has some `rtl8211f=y` in the defconfig, that might be the only thing (maybe) that the zero2 and zero2w might have in common. So the DDR4 if you look at the schematics side by side orangepi_zero3 and 2w they are the same (not just ddr4 but everything - the eth ic). the PMIC are the same and the busses and voltages are all the same ( one of them the schematic shows extra capacitors but the voltage / "bus" address all the same) The WiFi chip is the same power / pins etc, I saw someone mentioned the WiFi no working but on the official (beta build 6.1 debian) I've had no issues with it (haven't benched marked it or anything), on the older debian it gave me issues, like on first boot I could get my apt updates, after that restart it wouldn't connect, but it would after a second reboot... ( not sure I remember some of those helium miners I messed around with had issues like that, and a lot of the time it was the 2.4ghz and 5ghz home routers, would have the same SSID name and for whatever reason some of those drivers / chips would get stumped on that). As I was looking around I finally stumbled on the "next" branch in the the `1.`orangepi-build github directory, and that things been getting updates like every week and is like a year ahead of the master branch. There are no instructions there... But for the past 10 hours I been going threw it and banging out the headaches of figuring it out... but its kind of different and I'm just learning what all this different parts of uboot / linux build are structured. ref `1.` : https://github.com/orangepi-xunlong/orangepi-build/tree/next This seems to be the files you might need to compare here with what you got ( just referencing the wifi area since I noticed that was an issue a lot of people were having) zero2w https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero2w-u-boot-current.dts#L2707 zero3 - should be same note the difference in line number... https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-current.dts#L2688 Some other files here that have settings, other board in the parent folder... https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero2w.fex But also in the above files notice the HDMI ( someone was saying something about that) I had an issue with an armbian I downloaded 2-3 of the community versions for the 2w and it kinda worked... but I had issues with the HDMI with a DVI converter, I could see stuff it was just all glitching out, and would stall out on me. I tried it with just plugging it in HDMI to the TV HDMI (no dvi adapter + 1080) and it wasn't glitching out, I think the GNOME and the video drivers crash it im guessing, I did try to install GNOME on the official working xfce debian "beta" 6.1 and it was lagging hard, I tried to figure out wayland but leaving that for after I build this kernel to have "full control" of my debuging etc.. The orange pi beta 6.1 debian worked fine with the HDMI to DVI at any res, and the 6.1 mainline kernel I think already has the support for the Mali gpu, ( I still had to build it, with mesa etc for getting gstreamer ffmpeg codecs etc... I built that like 3 different ways... via the debian-mali method, with the ARM docs method, and random stuff I first found. As I've been going through the orangepi-build files / build I'm pretty sure there was a setting / option already set for PanfrostLima ... debian-mali https://wiki.debian.org/PanfrostLima#Hardware_support Mesa-mali https://docs.mesa3d.org/drivers/panfrost.html ARM-mali https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel But if you go into the orangepi-build/external/ you'll find all the things I mentioned above, and how I have been confirming all my random configs I been hacking together over the week. That repo is actually very well organized vs the other things I been going through, just files seem to have different names, and/or are structured more for whiptail style config / build system (actually really nice once you figure out how to get it to run (I even made / currently debuging a windows 11 Dockerfile that lets me use build on windows using linux docker, with the whole 'docker in docker' method). So you might not find like a defconfig (I'm not sure how armbian does this), but all the settings are there, even if they are mixed into a file that just builds those files out... but its actually convenient because you see the orangepi_zero3 and zero2w on the same page or directory without 10000 files in it, separated by whatever if statement / setting that is different. for example https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/include/sunxi64_common.inc#L69 https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/sun50iw9.conf#L118 Like it all works, I'm just in that stage of trying to update it to newer mainline kernels, fixing w.e errors pop up on my windows docker build attempt... but if your happy with what they got already there 6.1 and 5.4... and the ./build.sh just runs a menu config, that lets you build each part separate , uboot / kernel / fs .. and it has option for updating the kernel through the standard menuconfig. Preset configs that auto load into the menuconfig for orangepi_zero2w /zero3 and be completely adjusted from the whiptail menu... ref: - check parent folder for the other models https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/kernel/linux-6.1-sun50iw9-next.config So there are no instructions for that thing but this is what I was able to do, but then ran into, and still debugging some stuff (just for my windows docker container) 1. `git clone https://github.com/orangepi-xunlong/orangepi-build.git` 2. `cd ./orangepi-build` 3. `sudo chmod +x build.sh` (if necessary) 4. `./build.sh` - Note the build process makes a docker image and downloads all the build dependencies, so you shouldn't need to. But if you are building on x86_64 linux it has some function in there that will throw an error `You are running on an unsupported system [ bookworm<distro> ]` , the function that causes this has a note 'Ubuntu 21.04.x (Hirsute) x86_64 is the only fully supported host OS release', but you can use this ENV / VAR in the console or maybe the ./build <arg> `export NO_HOST_RELEASE_CHECK=yes`, which will bypass that, but with no gaurentee if it will work. 5. from the whiptail menu pick what you want to build uboot, kernel, fs, etc.. - Note that once you go into that option, its going to build the option at the end, it does not go back to the main menu for you to pick the next build option, it builds 1 at a time, then at the end theres another option to put it together, ( this is where you can either switch to armbian or w.e @least you hopefully* got a working u-boot) - Note when you are going through each step of the build option you made it will give you a list, to pick which board -> the ram -> what branch you want to use "master" or "next", next is like 1 year ahead of master, especially for orangepi_zero2w / orangepi_zero3 Thats pretty much it you just repeat step 5 untill you build everything you want, then combine it with armbian, or w.e ( havent ever built a U-boot before), but it spits each step out to some output folder in that orangepi-build directory, if it works then just go copy the settings and update the armbian repo or w.e I know it was alot, but I got alot of info from this forum, and others so I figure I post where I'm at , where I Noticed an active thread dealing with this. Again I've never built U-boot before but I'm sure alot of us haven't so to save someone from 1-2 weeks of reading 5 year old post and what not thats what I've gathered. Happy Newyears eve ... dunno if im going to finish this build for a day or 2
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines