Orange Pi Zero 3

[Stephen Graf]

2 hours ago, vice said:

TPM device is using spi0 as default but at orangepizero3 there is spi1.

Orangepizero2/3 are using spi0 internally to connect to the 16MB flash memory on the boards.  Spi1 is available and should be enabled by a working overlay in the near future.

In the meantime if you can find the driver source, it should be easy to change the spi port and cs in the code as they are usually just definitions.

As an aside, if you are looking to use a tpm for secure boot, you should be looking at u-boot and not Armbian.

[Stephen Graf]

I am asking for help in resolving an issue with dmesg and journal not starting at time zero on the orangepizero2.  I don't' know about the zero2.

 

I am actually trying to determine why bluetooth only works on the initial boot and never again after a reboot.  I am booting from spi flash to a usb hard disk. The dmesg started at time .03 sec on the initial boot and only at time .6 sec on the second boot.  In previous investigation I noted the journal indicates missing about 150 messages on boot. I am not sure if the missing data would help in my bluetooth investigation, but I feel very uncomfortable without the data.

 

I have no idea of where to start looking at the missing data problem. An armbianmonitor -u has been uploaded:

 

https://paste.armbian.com/isajocaper

[Stephen Graf]

6 hours ago, Stephen Graf said:

dmesg and journal not starting at time zero

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0.

 

I came across this in the internet:

 

Your kernel's ring buffer ran out and the first entries were removed for new entries.

Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config.

 

 

yeah now works with 19!
 

~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_

CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

[Igor]

13 hours ago, pixdrift said:

I feel Armbian don't want to

Reason is in exploitation nature of economical relations between parties - "you don't fund our work, but steal from" vs. "we paid for hardware, software is free" vs. "Buy 16core 32Gb NVME 2.5G PCI ... hardware that runs any Linux" We would very much invest a lot more, but someone needs to pay our bills more then 0.5%. Several people behind Armbian also works full time in order to maintain this place and all our forks and upstream distributions that are "porting from Armbian: Manjaro, Arch, NixOS, Debian, ...".

 

There is big misconception and common believe that hardware vendors helps us. Sadly no. They don't help. With small exceptions they do everything to (ab)use our work and efforts, community development, this place, you. Whatever they are communicating, their aim is to sell hardware with promise of software support, with proprietary builds and closed features where only they have the key. Such as video 3D (opened by community on old chips), acceleration (opened on old chips), AI acceleration (closed ATM). Its a love / hate relationship.

 

Some of things that are done in this (yet another new hardware - why we need Zero 3? 4 needs only making marketing material, board is done in a day) are fun, while (real and long term) maintenance is hard and inglorious work people tend to avoid. Getting amateurs to maintain this large, complex and disorganized egocentric landscape ... is very very hard.

A lot of patches we maintain are here because upstream is wild wild west, often unfriendly to community (sometimes with a good reason) and friendly to corporate that can afford to develop at required quality level standards and also a place of deceptions. Vendors efforts are done once their HW is "supported" by mainline Linux (with "supported by Armbian" its the same), but in reality, often nobody maintains those boards and its also impossible to verify if things are alright at merge time. Some patches that we made were also simply up-streamed by removing the origin. Which is the lowest act open source developers can do. Sadly this also happens and its pointless to waste time to prove and take actions. And fight for your (c) for the job you have done for free in organised manner. Armbian is here 10 years. For us maintaining is a long term mission, done in as organised way as possible in order to save our time.

 

11 hours ago, Stephen Graf said:

you should be looking at u-boot and not Armbian.

u-boot is yet again, a raw material. In ideal world, all this low level job should be covered by vendors. But its not done by them. Its done by you, me and people around communities as ours, once by us, once by OpenWRT, LibreElec or similar project that stick their noise into low level world.

[pixdrift]

I am not sure why you have quoted me out of context there @Igor but I think this quote poorly represents my intent as the quoted text was part of me providing a response to @MrK regarding overhead of maintaining kernel patches in Armbian. I think your response is both disproportionate and misdirected. I understand the commercial realities of open source and contribute here (as an amateur) by choice.

 

 

 

[pixdrift]

6 hours ago, Stephen Graf said:

came across this in the internet:

 

Your kernel's ring buffer ran out and the first entries were removed for new entries.

Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config.

 

 

yeah now works with 19!
 

~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_

CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

This looks pretty interesting @Stephen Graf, sorry I didn't get to test Zero 2 to confirm for you, I did build a fresh image from main though for the test.

What was the configuration before you changed it to 19? and how did you land on 19? did you bump it up until it was enough? or was there something more technical driving that decision?

[pixdrift]

May as well open old wounds while I am here.

 

I know my patch to 'enable all' as an overlay alternative wasn't well received, but I would like to discuss one of the patches I created in this PR as I think it may add value, specifically the changes to the sun50i-h616.dtsi.

https://github.com/armbian/build/compare/main...pixdrift:armbian_build:zero23_enable_all#diff-fd8dde60be0ca66f34e87999a632958889bf41b5ff6b047627ee4d91a7f1e04dR111-R184

These changes are basically to 'move up' all the shared/common config out of the zero2/zero3 board configs so they don't need to be set at the board level and the boards can be pretty close to turning components on with 'okay'. This may not be perfect (need a review of the dtsi changes and feedback), but I wanted the intent to be clear, and to see if others agree with this approach.

It also fixes the spi1 pin problem (PH5 -> PH9) in the dtsi patch.. so people don't have to keep working around it (maybe  we should just merge this first as something we all agree on?)

Edited January 29 by pixdrift

[ag123]

@Igor

it is a little unfortunate that in this open sourced world, not all users would see using and supporting Armbian as a cooperative

https://dictionary.cambridge.org/dictionary/english/cooperative

 

I'm not sure what can be done, but this state of the situation would likely persist.

 

in a certain sense, getting Linux and Armbian to run on Orange Pi Zero 3 is already a 'heroic' effort. Given, the dram controller is *undocumented*, all that u-boot codes that made the memory detection work is a 'miracle' pieced together from reverse engineering and wild guesses. So are all that 'heroic' efforts by linux-sunxi and Armbian to make it run on H616 / H18 and supporting the ethernet PHY as well as uwe-5622 wifi. for that matter the H618 and uwe5622 technical reference manual cannot be found in the wild

and all these efforts thus far from notably @Gunjan Gupta , @pixdrift , @Stephen Graf et.al. the wild tests and trials to tweak the configurations *so happens to work*!

it can reasonably be said that running any open-sourced linux and/or Armbian on Orange Pi Zero 3 will practically be always *use at your own risk*, as no one can give any assurance that any of these are after all formal.

 

In short, it wouldn't have happened without all these community effort and Armbian itself and efforts from linux-sunxi contributors. it is an incredible effort on its own.

for that matter Orange Pi Zero 3 with all these community effort from Armbian and linux sun-xi nearly makes it lives up to an Raspberry Pi 3B+, at least in terms of functionality and performance.

it is no small feat / achievement.

 

There is also the notion that the board developers / manufacturers should after all fund and support Armbian including the technicals, it is a different consideration however.

 

I'd like to say that Armbian *runs well* on Orange Pi Zero 3, for 'basic' use with ethernet and wifi. There are many other things that I've not yet explored but the @pixdrift, @Stephen Graf have explored to some extent. e.g. the gpios, spi and such alternate functions on the pins etc.

 

as for the "1.5GB problem", my thoughts are currently this. We'd need to publish *release notes* or more correctly *read this first*, with this board if this board is hosted as a 'community supported' board. Because, the memory detection logic *in uboot* will probe into *wrap around* addresses and falsely detect memory as available. There is *no solution* as the dram controller is *undocumented* , so one way out of this is to publish a note to say that for 1.5GB and some such board owners, a *solution*, is they have to edit /boot/armbianEnv.txt, and use a different DTS overlay that encode the memory size in the overlay. This is thinking ahead, I've not tried this solution if it after all works if at all. we'd probably can put other *pitfalls* and known-limitations and *disclaimers* (e.g. use at your own risk) in the *read this first*

 

[ag123]

@pixdrift rather than to say that 'enable all' isn't well received, i think we (at least myself) may be misguided, as I've not explored a lot of things, especially access to the io header pins.

there are also a lot of things that we'd need @pixdrift, @Gunjan Gupta, @Stephen Graf and others who happened to use those functionality (e.g. the header pins / spi / gpio etc) to share if after all enabling them actually lead to conflicts? and if after all pinmux 'works the way as expected', e.g. my notion that pin mux selects the function is *pure speculation*, e.g. that after all we can simply 'enable everything' and just use pin mux to choose between them. e.g. pin mux determines if gpio or alternate function ( spi / uart/ i2c / pwm etc is seen at the pin.

There are also *unproven* things that I simply speculate if simply 'okay' the device in DTS actually cause a higher power consumption / higher temperature, there is no actual report / comment to indicate that it really works that way !

i'm simply being *lazy* to comment that maybe leaving it 'disabled' is just 'safe', that may not even be true.

 

[Stephen Graf]

4 hours ago, pixdrift said:

What was the configuration before you changed it to 19

I'm still trying to find where to make the change.  The internet message was from 10 years ago!  I did not want you to rebuild, just start up zero2 and do a dmesg to see it it starts at time 0 or about .6 sec. Just to see if the problem is specific to zero3 or both.

[Stephen Graf]

2 hours ago, ag123 said:

i'm simply being *lazy* to comment that maybe leaving it 'disabled' is just 'safe',

I think I retracted my proposal to enable all the hardware and just skip overlays.  Armbian-config Hardware and overlays are very useful. 

 

My concern from the beginning has been the issue of overlays being "generic". Dts is a definition of the hardware on a SBC.  Obviously the SOC is the major piece, but there are other items that need specification, memory, gpu, power regulator, ethernet phy, etc.  Because these other items are unique to a SBC, the dts takes the name of the SBC, not the SOC.  There is no such thing as a generic dts. Now since overlays are simply modifications to a dts it is logical that overlays should also be unique and tied to a specific dts.  There are many overlays that are common among the SBCs just as many dts' share common dtsi, But the fact remains that the dts has the name of the SBC and I suggest that the overlays follow this naming convention.  I think this would simplify creation and certainly testing of overlays.  Fewer patches would be required and testing would be limited to the overlay for the SBC being worked on. If this approach were taken it would not require rework of the existing overlays that already work.

[pixdrift]

Apologies, I didn't mean to bring up the discussion about overlays again. I agree overlays are the direction we are agreed to go, it is just agreement on implementation that is pending.

 

I am still interested in feedback on the specific section of my branch that I posted as this work to 'move up' hardware configuration into the sun50i-h616.dtsi will also benefit overlays in the future. It's to ensure everything that is SoC level configuration is captured in the sun50i-h616.dtsi rather than being defined and replicated in the board .dts files.

If we can agree that this looks beneficial, I will separate it from the 'all enable' PR I was building and raise a new PR.

[pixdrift]

3 hours ago, Stephen Graf said:

I'm still trying to find where to make the change.  The internet message was from 10 years ago!  I did not want you to rebuild, just start up zero2 and do a dmesg to see it it starts at time 0 or about .6 sec. Just to see if the problem is specific to zero3 or both.

A rebuild is quick on my compile setup, and I always like to test with the latest main branch regardless. The testing on the hardware is a little more involved, I will get the details and post them here.

[Stephen Graf]

7 hours ago, Stephen Graf said:

I'm still trying to find where to make the change.

Well I found it by asking for kernel configuration changes during the build setup.  I think the original values were 15 for 17 and 12 for 15 but I can't remember for sure.  Anyway with the new values I can see the beginning of the dmesg and journal does not report missing messages.

 

However the extra data did not show anything to help me with the bluetooth problem.

 

 

x               General setup  --->   

 

 x           (17) Kernel log buffer size (16 => 64KB, 17 => 128KB)                             x x
 x           (15) CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB) 

[Gunjan Gupta]

5 hours ago, Stephen Graf said:

Well I found it by asking for kernel configuration changes during the build setup.  I think the original values were 15 for 17 and 12 for 15 but I can't remember for sure. 

 

$ grep 'CONFIG_LOG.*SHIFT' config/kernel/linux-sunxi64-*.config

config/kernel/linux-sunxi64-current.config:CONFIG_LOG_BUF_SHIFT=14
config/kernel/linux-sunxi64-current.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_BUF_SHIFT=14
config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_BUF_SHIFT=14
config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

 

you can also use './compile.sh BOARD=orangepizero3 BRANCH=<branch> kernel-config' to get to the kernel menuconfig and change the same.

[pixdrift]

On 1/29/2024 at 5:50 PM, Stephen Graf said:

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0.

It starts pretty close to 0, but not 0  Is this similar to what you see on the Zero3? If you need anything else let me now, I will leave this image running for a while.

The fact it doesn't start at the same point each time, definitely looks like a buffer running out.

Boot 1.
 

root@orangepizero2:~# dmesg | head -n20
[    0.883321] async_tx: api initialized (async)
[    0.883341] Key type asymmetric registered
[    0.883354] Asymmetric key parser 'x509' registered
[    0.883511] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246)
[    0.883939] io scheduler mq-deadline registered
[    0.883958] io scheduler kyber registered
[    0.884056] io scheduler bfq registered
[    0.907712] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[    0.938149] loop: module loaded
[    0.944735] usbcore: registered new interface driver usb-storage
[    0.946043] mousedev: PS/2 mouse device common for all mice
[    0.948220] sun6i-rtc 7000000.rtc: registered as rtc0
[    0.948294] sun6i-rtc 7000000.rtc: setting system clock to 1970-01-02T00:00:46 UTC (86446)
[    0.949050] i2c_dev: i2c /dev entries driver
[    0.950594] sunxi-wdt 30090a0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[    0.953963] sdhci: Secure Digital Host Controller Interface driver
[    0.953991] sdhci: Copyright(c) Pierre Ossman
[    0.954060] Synopsys Designware Multimedia Card Interface Driver
[    0.955498] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.957225] ledtrig-cpu: registered to indicate activity on CPUs

 

Boot 2.
 

root@orangepizero2:~# dmesg | head -n20
[    0.960698] hid: raw HID events driver (C) Jiri Kosina
[    0.960882] usbcore: registered new interface driver usbhid
[    0.960900] usbhid: USB HID core driver
[    0.962997] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    0.977441] NET: Registered PF_INET6 protocol family
[    2.996533] Freeing initrd memory: 17964K
[    3.087943] Segment Routing with IPv6
[    3.088129] In-situ OAM (IOAM) with IPv6
[    3.088328] NET: Registered PF_PACKET protocol family
[    3.088657] 8021q: 802.1Q VLAN Support v1.8
[    3.088806] 9pnet: Installing 9P2000 support
[    3.088980] Key type dns_resolver registered
[    3.105046] registered taskstats version 1
[    3.105354] Loading compiled-in X.509 certificates
[    3.123670] zswap: loaded using pool zstd/z3fold
[    3.145834] Key type .fscrypt registered
[    3.145864] Key type fscrypt-provisioning registered
[    3.149115] Btrfs loaded, zoned=yes, fsverity=no
[    3.149407] Key type encrypted registered
[    3.149433] AppArmor: AppArmor sha1 policy hashing enabled

 

Edited January 30 by pixdrift

[pixdrift]

Thanks @Gunjan Gupta that looks promising because we can potentially just bump it up for the sunxi kernels to resolve the issues without impacting anyone else  

I wonder if distros tweak this setting too, seems like an obvious one to bump up.

[Gunjan Gupta]

11 minutes ago, pixdrift said:

I wonder if distros tweak this setting too, seems like an obvious one to bump up.

Debian seems to use the following

CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

 

Fedora has the following

CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

 

[pixdrift]

Changing the linux-sunxi64-edge.config to the same as Debian resolved the issue
 

CONFIG_LOG_BUF_SHIFT=17

Boot
 

root@orangepizero2:~# dmesg | head -n20
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.7.2-edge-sunxi64 (armbian@next) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #10 SMP Thu Jan 25 23:45:31 UTC 2024
[    0.000000] KASLR disabled due to lack of seed
[    0.000000] Machine model: OrangePi Zero2
[    0.000000] OF: reserved mem: 0x0000000040000000..0x000000004007ffff (512 KiB) nomap non-reusable secmon@40000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x7fdcd040-0x7fdcefff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000004007ffff]
[    0.000000]   node   0: [mem 0x0000000040080000-0x000000007fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] cma: Reserved 128 MiB at 0x0000000076c00000 on node -1
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.

@Gunjan Gupta If I was to raise a PR to update this in the three sunxi64 configs (legacy, current, edge) would that get merged? or are there concerns about changing this?

I think setting to the same as Debian is a safe option, and obviously resolves the issue.
 

Edited January 30 by pixdrift

[Gunjan Gupta]

14 minutes ago, pixdrift said:

If I was to raise a PR to update this in the three sunxi64 configs (legacy, current, edge) would that get merged? or are there concerns about changing this?

I think this is fine. I noticed this issue on Allwinner H6 SoC as well. So I think this will benefit other SoCs as well. The sunxi64 I believe covers A64, H5, H6, H616/H618 I think they will be fine. 

[Stephen Graf]

6 hours ago, Gunjan Gupta said:

I think this is fine. I noticed this issue on Allwinner H6 SoC as well.

On orangepizero3 I tested with just changing CONFIG_LOG_BUF_SHIFT=17 and it worked well. Using a setting of 15 still had missing messages. I saw that most other boards in the Armbian distro had settings of 17 or 18 and I think one was 19.

[Gunjan Gupta]

5 minutes ago, Stephen Graf said:

I think one was 19.

Maximum value I see is 21

config/kernel/linux-arm64-sm8250.config:CONFIG_LOG_BUF_SHIFT=21

 

[Stephen Graf]

@Gunjan Gupta  Should @pixdrift issue a PR to change the value for the legacy, current and edge to 17?

[Gunjan Gupta]

25 minutes ago, Stephen Graf said:

@Gunjan Gupta  Should @pixdrift issue a PR to change the value for the legacy, current and edge to 17?

https://github.com/armbian/build/pull/6228

[pixdrift]

Thanks @Gunjan Gupta saves me raising a PR for such a minor change.

Would you also be able to add this pin change for spi1 to your PR6228? it's another minor update that has been pending for a while
https://github.com/armbian/build/compare/main...pixdrift:armbian_build:zero23_enable_all#diff-fd8dde60be0ca66f34e87999a632958889bf41b5ff6b047627ee4d91a7f1e04dR119-R123

Edited January 30 by pixdrift

[Gunjan Gupta]

19 minutes ago, pixdrift said:

Would you also be able to add this pin change for spi1 to your PR6228? it's another minor update that has been pending for a while
https://github.com/armbian/build/compare/main...pixdrift:armbian_build:zero23_enable_all#diff-fd8dde60be0ca66f34e87999a632958889bf41b5ff6b047627ee4d91a7f1e04dR119-R123

Edited 3 minutes ago by pixdrift

I had most of the commits running on my orange pi 3 lts and as they were tested I included the same. I do have some leftover commits for zero3 in my local git that I have still not pushed. I was planning to test everything and push them on the coming weekend. Is it ok if I defer this to be included in that as well?

[pixdrift]

26 minutes ago, Gunjan Gupta said:

I had most of the commits running on my orange pi 3 lts and as they were tested I included the same. I do have some leftover commits for zero3 in my local git that I have still not pushed. I was planning to test everything and push them on the coming weekend. Is it ok if I defer this to be included in that as well?

That sounds good. Could you stage a PR for this in WIP? and I can get some builds done from the PR so people can test the changes here (and also review if there is anything else we should add).

[pixdrift]

Just a quick note for those who don't venture out into the wider forum beyond their boards of interest (this was me until a couple of days ago)... I'd like to introduce @Nick A.

 

@Nick A dropped me a message earlier this week and linked me to a thread he has been working in with several others for an H618 based TV Box from Transpeed. 

Looks like @ag123 already knew about it, but just wanted to introduce @Nick A and others from this thread as additional collaborators for H61x work. It was an interesting thread to go through as I don't have any TV boxes currently, and it was also great to see the work on H61x that everyone has been contributing to... getting picked up and used by others.

Edited January 31 by pixdrift

[ag123]

actually that box is good in a sense that it has quite a few peripherals on board and is probably cheaper than development boards in a sense that it comes with a case.

i've not 'touched' them as that normally public documentation tend to be even thinner than do development boards.

but yup, I'd think it would be good if Armbian runs on them as well, more options for whoever is using Armbian

hopefully that the H618s are after all similar that the difference between them is simply a DTS

[Gunjan Gupta]

@pixdriftI will raise my PR when I am ready. But for the SPI change, could you please raise the PR yourself?