Werner 320 Posted November 28, 2020 Share Posted November 28, 2020 I started to play with this board and obviously failed miserably creating a basic Armbian integration. Anyway. These are the information I collected so far: dtb extraction from Xulong image: https://pastebin.com/raw/Uni2JzBF orangepimonitor 🙄 http://ix.io/2FM0 root@orangepizero2:/etc/apt# lsmod Module Size Used by zram 36864 2 sprdwl_ng 438272 0 sprdbt_tty 36864 2 uwe5622_bsp_sdio 294912 2 sprdbt_tty,sprdwl_ng kernel config: https://pastebin.com/raw/e2jTTZ7A 0 Quote Link to post Share on other sites
Werner 320 Posted November 28, 2020 Author Share Posted November 28, 2020 Also interesting to see. This board, or better to say their image suffering from a similar issue like the first H6 images: constant load on one core for no reason. loadavg is ALWAYS 1 or higher... At least they could reduce it. On H6 3 of 4 cores had always 100% load Also shutdown leads into reboot. 0 Quote Link to post Share on other sites
Werner 320 Posted November 29, 2020 Author Share Posted November 29, 2020 Some first work on U-Boot: https://github.com/jernejsk/u-boot/commits/h616-v1 0 Quote Link to post Share on other sites
jernej 197 Posted November 29, 2020 Share Posted November 29, 2020 2 hours ago, Werner said: Some first work on U-Boot: https://github.com/jernejsk/u-boot/commits/h616-v1 I just updated that branch, now it can boot normally from SD card. You'll also need TF-A and Linux to make it usable: https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP https://github.com/apritzel/linux/commits/h616-WIP UART, ethernet and SD card already work, so it already works good enough for headless server... 2 Quote Link to post Share on other sites
Werner 320 Posted November 29, 2020 Author Share Posted November 29, 2020 Thanks. Hopefully somebody like @martinayotte has a chance to play with the collected information and create some basic Armbian support with it 0 Quote Link to post Share on other sites
martinayotte 666 Posted November 29, 2020 Share Posted November 29, 2020 1 hour ago, Werner said: Hopefully somebody like @martinayotte has a chance to play with the collected information and create some basic Armbian support with it I will try my best, but "time is the missing ingredient" as usual ... (I'm currently chasing why SPI0 doesn't work properly on OPiOne+ while it was with few earlier kernel versions) 3 Quote Link to post Share on other sites
Igor 2099 Posted December 4, 2020 Share Posted December 4, 2020 On 11/29/2020 at 4:28 PM, jernej said: UART, ethernet and SD card already work, so it already works good enough for headless server... I am playing around and ... are there any general changes that I am missing-> U-boot file not found [ u-boot.itb ] 0 Quote Link to post Share on other sites
jernej 197 Posted December 4, 2020 Share Posted December 4, 2020 2 hours ago, Igor said: are there any general changes that I am missing-> U-boot file not found [ u-boot.itb ] At the end of U-Boot build process you should get u-boot-sunxi-with-spl.bin - this is now unified for 32 and 64 bit SoCs for some time now. It is possible that names of intermediary files changed since script for generating single binary was moved from shell script to python one recently. 0 Quote Link to post Share on other sites
Igor 2099 Posted December 4, 2020 Share Posted December 4, 2020 2 hours ago, jernej said: At the end of U-Boot build process you should get u-boot-sunxi-with-spl.bin - this is now unified for 32 and 64 bit SoCs for some time now. It is possible that names of intermediary files changed since script for generating single binary was moved from shell script to python one recently. It puzzles me since we have different variants for 32 and 64 bit. So you are saying its safe to migrate to u-boot-sunxi-with-spl.bin https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi64_common.inc#L44-L48 OK. 0 Quote Link to post Share on other sites
Igor 2099 Posted December 4, 2020 Share Posted December 4, 2020 Manage to boot but can't login via serial login ... huh. Will try once again tomorrow. https://github.com/armbian/build/pull/2418 1 Quote Link to post Share on other sites
jernej 197 Posted December 5, 2020 Share Posted December 5, 2020 8 hours ago, Igor said: It puzzles me since we have different variants for 32 and 64 bit. So you are saying its safe to migrate to u-boot-sunxi-with-spl.bin Certainly. I'm using unified approach for quiet a while on LE. 7 hours ago, Igor said: Manage to boot but can't login via serial login ... huh. Strange. I use Arch 32-bit userspace without any big issue. 0 Quote Link to post Share on other sites
Werner 320 Posted December 5, 2020 Author Share Posted December 5, 2020 Maybe it is a good idea to build on top of sunxi-dev instead of current since dev is 5.10 and will be next LTS kernel. Isn't the work of apritzel based on 5.10? 0 Quote Link to post Share on other sites
Werner 320 Posted December 5, 2020 Author Share Posted December 5, 2020 There you go cpufreq does not work yet. root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. Leds are inverted /sys/devices/platform/leds/leds/orangepi:green:status/trigger actually toggles the red led and vice versa network works: http://ix.io/2GH3 1 Quote Link to post Share on other sites
Igor 2099 Posted December 5, 2020 Share Posted December 5, 2020 Works now. Building beta images ... https://www.armbian.com/orange-pi-zero-2/ 0 Quote Link to post Share on other sites
Werner 320 Posted December 5, 2020 Author Share Posted December 5, 2020 Reboot does not work. Leads into shutdown/freeze HDMI does not work. No output whatsoever USB does not work ran into random power down orangepizero2 login: [ 17.491648] sysrq: Power Off [ 17.502363] reboot: Power down Other weird stuff [ 33.768377] usb1-vbus: disabling [ 33.768404] vcc3v3-ext: disabling [ 33.768749] vcc3v3-ext2: disabling [ 33.769067] cldo1: disabling 0 Quote Link to post Share on other sites
jernej 197 Posted December 5, 2020 Share Posted December 5, 2020 27 minutes ago, Werner said: HDMI does not work. No output whatsoever USB does not work That's expected, only things that I explicitly stated work - so SD card, network and serial console. Maybe also SPI and I2C, but I don't test buses unless some device is connected to it. 29 minutes ago, Werner said: Reboot does not work. Leads into shutdown/freeze Strange. It works for me. Make sure you have DT node which reserves memory for firmware. Without it, ATF will be overwritten and reset won't work. Other than that, I don't know. 34 minutes ago, Werner said: [ 33.768377] usb1-vbus: disabling [ 33.768404] vcc3v3-ext: disabling [ 33.768749] vcc3v3-ext2: disabling [ 33.769067] cldo1: disabling Why would be that strange? AFAIK kernel disables unused voltage regulators. 0 Quote Link to post Share on other sites
Werner 320 Posted December 5, 2020 Author Share Posted December 5, 2020 2 minutes ago, jernej said: Why would be that strange? AFAIK kernel disables unused voltage regulators. I don't know. Maybe I just did not pay close attention to that on any other board yet . If this is expected behavior never mind. 4 minutes ago, jernej said: It works for me. Probably our implementation breaks something. https://github.com/armbian/build/pull/2418/files 0 Quote Link to post Share on other sites
jernej 197 Posted December 5, 2020 Share Posted December 5, 2020 I don't see anything out of the ordinary, but note that there are newer Linux patches: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=394711 However, they shouldn't change anything AFAIK. 0 Quote Link to post Share on other sites
Werner 320 Posted December 5, 2020 Author Share Posted December 5, 2020 https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201204071107.25206-1-huangshuosheng@allwinnertech.com/ https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201204070901.24592-1-huangshuosheng@allwinnertech.com/ This might help fix cpufreq I assume 0 Quote Link to post Share on other sites
jernej 197 Posted December 5, 2020 Share Posted December 5, 2020 10 minutes ago, Werner said: This might help fix cpufreq I assume Those patches are for A100, not H616. The biggest issue for cpufreq is making opp table - you have to make sure that each point is stable. BSP one is good starting point, but testing is not fun. On top of that, it's very good to have thermal driver working, to prevent burning hot SoC... I don't plan working on OPP... 0 Quote Link to post Share on other sites
Werner 320 Posted December 6, 2020 Author Share Posted December 6, 2020 17 hours ago, jernej said: Those patches are for A100, not H616. Oops, my bad. Will try the new patch series. Reworked to the new patch series. Boots. Does neither fix nor break anything so far. 0 Quote Link to post Share on other sites
Werner 320 Posted December 11, 2020 Author Share Posted December 11, 2020 I tried to migrate to the recent patchset published here https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=400181 but wont do a clean boot for me. https://paste.debian.net/1176460/ For the moment I assume two issues: Something wrong with axp20 when applied against megi's orangepi-5.10 sources and mmc broke with the switch from the very first patchset to the 2nd (the linked above is the 3rd AFAIK) The 1st I could nail down by disabling by disabling Andre's [v2,10/21] mfd: axp20x: Allow AXP chips without interrupt lines patch (which is not necessary a smart idea but at least I does not throw an Oops at boot). The 2nd however I could not figure out yet. I still get dropped into a shell and mmc is not present in /dev. https://github.com/armbian/build/commit/2445b310692c44a129926fd24ec0f0b63c466342 0 Quote Link to post Share on other sites
hexdump 46 Posted December 11, 2020 Share Posted December 11, 2020 @Werner - it might be better (at least in the beginning) to use a plain mainline as a base as i guess this is what the authors of the patches use when creating them ... mixing it with another tree with lots of own patches in them might make it harder to debug problems 0 Quote Link to post Share on other sites
Werner 320 Posted December 11, 2020 Author Share Posted December 11, 2020 Yeah you are right, the patches are applied and built against mainline is just fine. However it would be nice to see them work against megi's sources too at some point. That is why I mention it here so maybe somebody has some clue why 0 Quote Link to post Share on other sites
Andyvec 0 Posted January 10 Share Posted January 10 Hi! I'm trying to boot from booster and focal images provided here (Jan 6 2021) but I my Orange Pi Zero2 it's not booting with this images. The red light on the board never turns on and the LAN are blinking in a wired way when trying this images. I can perfectly boot from booster, focal and Android images provides in the Orange Pi site (but I don't like theirs configuration), so it's not a an SD issue. I just making my images with dd as always. I have tried with a new SD, but it's the same... OrangiPi build are working, armbian are not. Are you guys still working in this new images? Is it necessary any additional step after burning with dd? Thanks a lot! 0 Quote Link to post Share on other sites
Werner 320 Posted January 10 Author Share Posted January 10 dd Support claims for images written with dd or any other tool that lack verification are rejected. https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card Seems like jernejsk made some changes to his U-Boot branch which could be the reason: https://github.com/jernejsk/u-boot/tree/h616-v1 0 Quote Link to post Share on other sites
Igor 2099 Posted January 10 Share Posted January 10 46 minutes ago, Andyvec said: armbian are not. We are developing support for this board from scratch, based on modern kernel. There are just a little work here and there, by different people, some things are the same as on older, some not. It costs a lot of time at this stage. Perhaps we should provide images with stock closed loader and private kernel? That works at least the same as stock and now certainly works better then mainline based images ... but its a dead end support path. I tried to boot that kernel with modern u-boot ... which would be some good mid path, but I already lost two afternoons on that and got nowhere. Which could be used better. Perhaps spending with family Our images are not done, which is why we label them WIP. They work or not. If they don't, we can't afford to left our jobs and/or spent afternoons to make them work. Which we usually do, when support is matured and we often (due too lots of investment into knowing how things works) knows why things bread down. And repair broken images. 1 Quote Link to post Share on other sites
jernej 197 Posted January 10 Share Posted January 10 2 hours ago, Werner said: Seems like jernejsk made some changes to his U-Boot branch Yeah, I forgot to add A100 compatible to mmc driver, that's why it doesn't boot. 0 Quote Link to post Share on other sites
Werner 320 Posted January 10 Author Share Posted January 10 14 minutes ago, jernej said: Yeah, I forgot to add A100 compatible to mmc driver, that's why it doesn't boot. Ah. Thanks for letting us know 0 Quote Link to post Share on other sites
jernej 197 Posted January 10 Share Posted January 10 Here is fixed v2 version: https://github.com/jernejsk/u-boot/commits/h616-v2 Note - it's not finished yet, so it will still change (force pushes). 2 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.