Orange Pi Zero 3

[Gunjan Gupta]

I created the download page for it. So it should be even easier now - https://www.armbian.com/orange-pi-zero-3/

[ag123]

@pixdrift, @Stephen Graf, @Gunjan Gupta, all

 

for the DTS, I'm slowly seeing the dilemma, on the soc some of the pheriperials are normally deemed 'fixed', but that

1. pin mux means that the same pin has multiple alternate functions - e.g. gpio + spi + i2c + uart + pwm etc
2. 'slave' / 'child' functions are a pain to deal with. 'slave' / 'child' functions are like for spi or i2c, some boards has external devices connected on them.
   e.g. on orangepi zero 3, I think the boot spi flash is likely connected to a spi flash, I'm not sure about others (this is deemded a 'slave' or 'child' device of the spi)
   the trouble is those 'slave' devices can be arbitrary e.g. one board may have that spi flash, another don't, or some others has other different device(s) connected at different ports.
   even gpios is not spared, as for gpios some pins are *leds* and again this vary from board to board or even arbitrary e.g. anyone can use any gpio pin as a led pin and the drive pull up or pull down differs.

I'm not sure how in particular dts overlays can represented case (2), is it practically feasible to declare 'soc' level includes that says declare the spi or i2c port  dtsi, and that subsequent per board dts include the 'soc' dtsi for the spi and i2c ports and further declare the slave / child devices attached?

 

And that there are further problems, e.g. that 'bigtreetech' board may declare non existent devices as being connected e.g. addressable led strips e.g. ws8212, tft3 lcd, mcp and light (leds). That in part as the eventual use could be a 3d printer which has those things connected, they are literally external and nowhere on the board.

 

then circling back to point (1), do declaring pheriperials as 'ok' necessary cause conflicts between the alternate functions? e.g. gpio + spi + i2c + uart + pwm all set to 'okay'?

the notion is that the alternate functions being the alternate functions themselves, and the pin mux being pin mux, .e.g pin mux selects the alternate functions and not the other way round.

the catch here probably is, if just say that there is *no conflict*, then that if all the alternate functions are 'ON' the soc would likely run hotter consume more power, but that pin mux may determine what is there at the output at the pin. the big catch here is that, if we are concerned about these issues, we may end up setting everything disabled by default ! and that every permutation of alternate functions thereafter requires a *custom overlay* !

 

Actually, I think it is a limitation of today's  kernel design, alternate functions could hopefully become 'dynamically configurable' at some future linux versions, e.g. that an app make calls to the kernel to setup particular peripherals at run time e.g. changing that from 'disabled' to 'okay' at run time. if imagine an fpga is connected at some arbitrary gpio, that fpga can warp into spi, i2c, uart, ethernet, scsi, a cpu, an npu, a gpu practically anything on the fly by fpga programming. we live in a wrold where hardware is software is partially true.

 

[Gunjan Gupta]

14 minutes ago, ag123 said:

And that there are further problems, e.g. that 'bigtreetech' board may declare non existent devices as being connected e.g. addressable led strips e.g. ws8212, tft3 lcd, mcp and light (leds). That in part as the eventual use could be a 3d printer which has those things connected, they are literally external and nowhere on the board.

There is no need to bring bigtreetech CB1 into the picture. Its a special case. It was added and maintained by Bigtreetech themself. They also have partnered with us and their funding allows us to spend sometime on Allwinner boards. Otherwise Allwinner boards just acts like giant blackhole that has the most of Armbian users and yet brings almost zero funding to the project.

[Gunjan Gupta]

The way I see it, the summary from last PR is that I want to keep overlays generic to avoid duplicate future efforts. While pixdrift and Stephen Graf wants to keep things specific only to zero2 and zero3 which would mean there will be duplicate efforts needed in the future. And thats where we had the deadlock in the last PR.

[ag123]

@Gunjan Gupta my apologies, I don't mean to address 'bigtreetech' rather I'm saying that the board is intended for a particular use case, and hence the dts is designed as such.

but that as the soc shares similar dts or dtsi templates, would there be overlapping concerns here?

[Gunjan Gupta]

6 minutes ago, ag123 said:

but that as the soc shares similar dts or dtsi templates, would there be overlapping concerns here?

I thinks it would be ok. Its a CM4 like board, so having more overlays for it won't hurt in anyways I think

[ag123]

i think we are dealing with dilemmas which evolves since when 'early' arm boards evolves with device trees, e.g. beagle bone black - the 1st to use device trees.

https://elinux.org/images/f/f9/Petazzoni-device-tree-dummies_0.pdf

 

if we want to be generic and yet safe, my guess is for a lot of the 'soc' level stuff, we'd probably declare all the peripherals / devices (e.g. spi / i2c / uart / pwm / gpio / usb etc) properly in the dtsi / dts, but perhaps 'disabled'.

this is probably safe, but that 'switching on' things would then take *custom overlays* for all various permutations.

 

then that for things that are 'common' (or commonly used or has a well defined use case) e.g. leds, spi flash boot roms (probabbly better 'disabled') those would/could be enabled ('okay') by default. But that this would be for each board.

 

it may take 'tutorials' pages to educate the audience about dts overlays etc going forward. 

 

 

 

 

[MrK]

@Stephen Graf Thank you. I found that no matter which userspace tool is being used I will not see 2x sck period of cs-sck setup and hold times (ref. H616 datasheet, section 5.10.3) due to spi-sun6i.c driver limitations. The spi controller according to H616 user manual, section 9.3 has more features than the existing driver is able to use. I want develop the driver further and preserve legacy modes while allowing these new extensions.

An excerpt from spi-sun6i.c:

 

Quote

    /* We want to control the chip select manually */
    reg |= SUN6I_TFR_CTL_CS_MANUAL;

 

I am sure "we do not want it all the time".

 

In the mean time I re-enabled spi1-dma. It seems to work however I reckon that it is too early to be confident of the dma. I will run more advanced tests once these spi controller extensions not handled by now will be done.

This is accomplished in attached patch.

 

@pixdrift Should I fork you repo, commit my changes and create pull request or posting a patch to this forum is good enough ? I think the patch should be added to series.conf if any. Right now I compile kernel out-of-tree (source tree) which is faster than the whole build system and I don't need to use VM because the build system requires root neither I don't use ubuntu by default but other distribution.

 

I noticed that pin-mux complains about some spi mis-configuration. I haven't updated my armbian yet since last time.

example:

[    1.530864] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[    1.531168] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 230 (PH6) from group PH6  on device 300b000.pinctrl
[    1.531178] sun6i-spi 5011000.spi: Error applying setting, reverse things back

 

@ag123 re: 2 interfaces, yes there are two independent instances of spi controller, #0 and #1. #0 is able to work in quad mode while #1 can use single mosi/miso or double rate only. #0 is routed to onboard spi flash in case of e.g. orange pi zero 3.

Everything is possible. It depends on board vendor only. For example spi #0 could be routed to connector also so some external device could share sck, miso, mosi with onboard spi flash but the CS. Section 9.3 of 616 user manual gives brief idea on how the spi controllers work and section 4.3 of 616 datasheet is about pin assignment. Looks like spi0 is available on PC only and spi1 on PH.

 

 

 

0001-orangepi-zero-3-dts-restored-dma-instance-spi1-confi.patch

[Gunjan Gupta]

18 minutes ago, ag123 said:

it may take 'tutorials' pages to educate the audience about dts overlays etc going forward. 

If I remember correctly, we generally have a README file in /boot/dtb/overlay listing all possible overlays for an soc and the parameter they support. So that should be fine. Besides these are header pins we are talking about. Anyone wishing to use it, unless they are using something simple will be writing their custom overlays for their electronic component anyways. For example if someone want to add a screen, they have to write a dts overlay for that. By default most things that are sold only provides overlays for raspberrypi. So I am willing to take a chance that the user who wants to use those headers would not be technically challenged and will do some homework themself

[Gunjan Gupta]

3 minutes ago, MrK said:

Right now I compile kernel out-of-tree (source tree) which is faster than the whole build system and I don't need to use VM because the build system requires root neither I don't use ubuntu by default but other distribution.

 

Build system supports building using docker. When using the same, you neither require root nor you require sudo IIRC. Also if you only wish to compile kernel, you can use "../compile.sh kernel BOARD=<board> BRANCH=<branch>". That will only compile the kernel

 

5 minutes ago, MrK said:

I think the patch should be added to series.conf if any

Series.conf and series.armbian. If you don't wish it to go missing on next major kernel bump

[MrK]

@Gunjan Gupta I see. I'm new to armbian so I do everything my own way. Promise I will do better over time.

[Gunjan Gupta]

1 minute ago, MrK said:

Promise I will do better over time.

Any contribution is more than welcome. 

[MrK]

Thanks.

[Sma]

3 hours ago, Gunjan Gupta said:

created the download page for it. So it should be even easier now - https://www.armbian.com/orange-pi-zero-3/

Awesome! Well, sort of....haha. I've had my OPiZ3 running for...looks like over 8 days now, on the PR6116 image @pixdrift was so kind to make available awhile back. Though granted it's just sitting there, not doing anything other than running random screen savers. Now of course I have to shut it down and grab one of the latest images to test. 

I've got a 3.5" touch screen attached to it, so I guess I'll see if i can get touch working, and if I'm not mistaken it SHOULD work without the HDMI hooked up, but maybe I have a false impression of what it's connector does. Maybe it only handles touch. If so no biggie, I can keep using it with HDMI as is. 🙂

Edited January 22 by Sma

[Stephen Graf]

@ag123@Gunjan Gupta@pixdriftLet's try to go back to fundamentals to see what we are trying to resolve with the overlays.

 

I will try to give you an idea of what a hardware developer would think about when deciding on a specific SBC.  The SBC designer will have made some choices as to what i/o will be available on the board.  The SOC has numerous options of which only a few will be implemented.  The hardware developer will look at the array of boards available and choose one that readily provides the functions that he thinks he would need.  I chose the orangepizero3 based on the availability of i2c (aka twi), spi and gpio which is very similar to the orangepione that I have a lot of experience with.  My problem is trying to get this i/o enabled via the usual armbian-config procedure. @Gunjan Gupta has taught me how to write overlays and I have been able to patch the dtb directly to get the i/o working.  But that is not the preferred procedure.  In the process I have come to question the rational of tying the overlays to the SOC instead of the SBC.

 

Should the overlays for orangepizero3 be labelled sun501-h618? That would be an easy solution for today as there are no other h618 boards. I think the bigtree board should not have been allowed to use the label sun50i-h616 for its overlays as that board is a very specific implementation for a particular environment.

 

After further reflection I don't think enabling the i/o in the dtb is the best idea.  It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter.  In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated.

 

I am not sure this moves us further along in resolving the issue, but I hope it provides some stimulus for thought.

[SteeMan]

I just want to add a few comments to this whole dtb overlay discussion.

 

First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.

 

The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

[pixdrift]

6 hours ago, Gunjan Gupta said:

The way I see it, the summary from last PR is that I want to keep overlays generic to avoid duplicate future efforts. While pixdrift and Stephen Graf wants to keep things specific only to zero2 and zero3 which would mean there will be duplicate efforts needed in the future. And thats where we had the deadlock in the last PR.

Currently there hasn't been a proposed alternative the solves the issue of board specific implementations of SoCs. There has been a suggestion that this could be done at the SoC level more cleanly, but I have dug through it and so has @Stephen Graf, and there are challenges with this approach (mainly conflicting board implementations and unnecessary options appears to end users) which currently (in my opinion) haven't been addressed by the SoC level overlay proposal. This may change if someone can put a patch together and we can see it working of course.

 

I still argue that having board specific overlays configurations available to Armbian developers (ie. people contributing to the Armbian project) is a fundamentally good (and clean) solution. I honestly don't see a huge increase in developer support burden when supporting this. After the initial creation of a new board configuration in Armbian, these files should be rarely touched or modified. If a zero4 comes out and it's based on the zero3, I just copy the zero3 overlay configuration and update it with zero4 changes and move on. I am not a board maintainer, but I would like to quantify exactly what support effort you are concerned about here @Gunjan Gupta? would you be able to provide examples of the scenarios that would greatly increase the maintenance effort of this approach so I can better understand your concerns?

 

 

3 hours ago, Stephen Graf said:

After further reflection I don't think enabling the i/o in the dtb is the best idea.  It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter.  In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated.

I agree. I put forward the new patch to demonstrate an alternate option, but I am not completely convinced by it either. In honesty, I thought @Gunjan Gupta may accept this as a PR based off our GitHub PR discussion, but I misinterpreted his views (my fault) in the discussion. This patch was developed before I saw his comment. That being said, there is something to be said for the 'out of the box experience' of everything just working, but you're right.. we should probably go the other way and make more things toggled (HDMI was a great example as I rarely use video in my applications of these boards)

 

One thing I did get out of this patching process however was that the DTS files are a bit of a mess. In my view, the configuration for the different SoC components should be done up at the h616.dtsi level, but I still believe the overlays should target specific boards. This is best demonstrated by the changes in my most recent (enable_all) branch. You will see I have moved the configuration for uart5 and ir (as examples) up to the h616.dtsi so the only thing done at the board level (the zero.dtsi because zero2 and zero3 are a special case with shared config here) is the 'status' change. This has pushed me to the conclusion that regardless of what level the overlay configuration targets (SoC or board), there should be essentially no configuration other than 'status = okay' or 'status = disabled' in the overlay for each item except in specific cases where a change of configuration is required such as switching usb otg to host mode.

 

 

1 hour ago, SteeMan said:

The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

Thanks for joining the conversation @SteeMan and for your Armbian forum moderation efforts. I appreciate this point of view and I completely agree. The things @Stephen Graf does with his boards is completely different to what I do. You then have another example user 'persona' that uses the boards for emulation, or streaming, or NAS. My position is that all our use cases should be treated as first class citizens, and we need to be careful as developers (with the luxury of being able to change what we want) about being opinionated about how we think people should use the hardware, and focus on the user experience to provide all the features a board has to offer easily to the end user.

I want to ensure this implementation (and other changes for that matter) avoids the following
1. Questions about why something that looks like it should work, doesn't work (eg. "I enabled this option in overlays, and it still doesn't work")

2. End users needing to 'roll their sleeves up' and write kernel patches or custom patches for Armbian to enable basic features

3. A negative view from new Armbian users when they come to the forum asking for support, and are told to 'implement it yourself if you want it' and leave disillusioned

Every new user is potentially a developer/contributor to the project with mentoring, and I think @Stephen Graf and myself are recent examples of this, but that doesn't mean that we want a new board user's first interaction with the community to be a 'just write a dtb overlay' style response as you have mentioned.

Edited January 22 by pixdrift

[pixdrift]

6 hours ago, MrK said:

@pixdrift Should I fork you repo, commit my changes and create pull request or posting a patch to this forum is good enough ? I think the patch should be added to series.conf if any. Right now I compile kernel out-of-tree (source tree) which is faster than the whole build system and I don't need to use VM because the build system requires root neither I don't use ubuntu by default but other distribution.

Sorry @MrK I missed this.

I am keen to see this patch because it's clear from your previous posts you're far more knowledgeable with the hardware intricacies than I think I could ever hope to be, so I am happy to go along with your suggestions for now :D.. I am just sticking patches together until this thing hopefully works!

I think based on my own experience, rather than you forking off my GitHub repository, it would be better to fork from mainline armbian/build (so you don't end up dependent on me):

 

1. Fork armbian/build so you have your own copy of the main Armbian repo
2. Create a new branch in your fork for the feature/change
3. Share a link to this branch here for collaboration/discussion

I am happy to pull changes from there, even if you just add the patch file to the patches.armbian directory in your branch with no other changes.

 

-edit-

Just looking at the patch you posted, is the spi-sun6i.c from another patch? or new?

Edited January 22 by pixdrift

[Gunjan Gupta]

26 minutes ago, pixdrift said:

I am not a board maintainer, but I would like to quantify exactly what support effort you are concerned about here @Gunjan Gupta

Alright let me give you an example of cases where a generic overlay will be helpful. There can be cases where someone will just add a board that they have to armbian and disappear afterwards without adding overlay for it. Now users will come to the forum asking for what overlay they can use to enable i2c for example on header and such. If we have generic overlays, then the same can be avoided. Also its makes adding new boards easier for the same soc easier. Overlays will already be there and just can be straight forwardly tested or tweaked for the new board.

 

31 minutes ago, pixdrift said:

This has pushed me to the conclusion that regardless of what level the overlay configuration targets (SoC or board), there should be essentially no configuration other than 'status = okay' or 'status = disabled' in the overlay for each item except in specific cases where a change of configuration is required such as switching usb otg to host mode.

Thats where fixup scripts and parameters come in. You can see we have a lot of parameters for spi overlays for other socs like H3. Those gets documented in the readme file. User enables the overlay and add parameter in the armbianEnv.txt file. I do agree this can be further improved and armbian-config can be made to handle those parameters with some work, but it is still better than have 10+ overlays per board for say for say 5-10 boards per socs with 5-10 socs per kernel. You can imagine the amount of files that will be there if we keep adding overlays per board per soc. Also imagine if something changes in mainline kernel and due to that you need to say add a new configuration value to the overlay. How many files would need to be checked and modified?

[pixdrift]

16 minutes ago, Gunjan Gupta said:

Overlays will already be there and just can be straight forwardly tested or tweaked for the new board.

Thanks for your response.

I think this is where the issue is.. they can't be 'tweaked' because of the potential impact to existing board configurations that share the overlays for the same SoC. Developers are reluctant to change the configuration for the new boards out of concern that it will impact existing boards using the same SoC configuration (this current example with zero2 and zero3 and Bigtreetech demonstrates this) .

The concern I have is, that when you create a patch/change for the overlays for a new board using an existing SoC, every board maintainer that has a board using that same SoC needs to re-test to validate the new board changes don't break their implementation. This may be speculation on my part if the process is working for other boards, but the board count is only at 3 or 4 for h616/h618 at this point, when we add Zero2W, Longan Pi3H , MangoPi M-core, Yuzuki Chameleon, Banana Pi M4, I only see the support/testing matrix when making changes exponentially increasing, which will burden far more board maintainers.

With board specific overlays, yes it's potentially a large number of files, but the files are relevant to just that board, and they can be modified in isolation without calling back other developers every time a PR is raised. I am not personally concerned about the number of files as they can be organised in directories and follow standard conventions for clarity, and size wise they will amount to kilobytes and compress well.

 

As I mentioned above too, my proposal is to make 'board specific' configurations available as an agreed option for developers in Armbian, not to mandate that every board must be implemented in this way (this can be configured with prefix in the board configuration).

Edited January 22 by pixdrift

[Gunjan Gupta]

Is it too much to ask to wait so that I can get some time to work on this? I have seen your changes. Wait for some time to see what I had in mind and decide after that. Until then you have your fork and your builds. So forgive me if I don't understand why its so urgent to have this right now. Please just wait ok. I am maintaining 10 boards juggling multiple tasks. I can't simply keep on replying trying to explain what I have in mind. This is distracting me from focusing on other issues that need my attention right now.

[Stephen Graf]

1 hour ago, Gunjan Gupta said:

This is distracting me from focusing on other issues that need my attention right now.

@Gunjan Gupta Yes I can see that you are trying to take on too much and no I don't think this is that urgent. However in the interests of moving forward, is there anyone else who would have some cycles to deal with this?

 

I would like to follow your proposal and stay with the existing naming convention for the time being.  As the orangepizero3 is the first h618 SOC, in keeping with the existing procedures we should create a new overlay structure called sun50i-h618. I could recreate the patch for the overlays (5) that I think are useful for the zero3.  Then by the time new h618 boards are added you may have had time to revisit the whole issue.  In the meantime let others do the work.  This change will not impact any other board.

 

As I am proposing to stay with the existing procedures. I don't think this patch will require any significant time from you. I can see from @SteeMan comments that trying to improve things will be a big headache.

 

What do you think?

[pixdrift]

For anyone interested in builds of the PR6182 patch set for the menu/overlay changes, I copied up the builds I generated (that also include the mali fix posted in this thread)

https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/

Edited February 2 by pixdrift

[ag123]

note that i agree with @Stephen Graf viewpoint that overlays are specific, and worse not only to a board but to particular use case.

take for example the 'bigtreetech cb1' board which may coincidentally be using a soc in the H616/H618 family, lets just say that the CB1 dts (note not overlay) declares that 'ws2812' (addressable led matrix), spi tft lcd, mcp, light are part of accessible devices connected to (an) SPI port. this scenario didn't only address the board, it address the use case as well, e.g. a 3d printer with those additional devices connected.

it isn't to say that it is 'incorrect' nor 'inappropriate', but that the same SPI port on the same board can just as well be connected to *different peripherals and/or devices*.

and that supposing that you have at least 2 different uses for the same board that would take at least 2 different dts templates and/or overlays, in fact there can be 'infinite' permutations of use cases for the same SPI port, and that practically means *infinite* permutations of overlays for *all possible* devices connected in some ways to a SPI port.

 

hence, for dtsi (DTS includes) and dts (device tree source) templates, they work more like 'object oriented' inheritance hierarchies, e.g. that the most general, say at the soc level may be declared, e.g. the SPI ports.

 

but that further down at the use cases e.g. the devices attached to spi ports, especially those can literally change on the fly, those would inevitably need to be declared in *specific* overlays addressed to the use case e.g. a 3d printer (or any appliance for that matter, e.g. a TV / media streaming box) - this goes beyond just that board. Note however, that there are *well defined* use cases e.g. particular leds on the board, those can probably be defined and enabled ('okay') in the board specific dts template.

 

in a sense, every board with at least a difference in configuration, say for that matter led at a different pin and/or pull-up/pull-down would have a different dts template for the board.

this would be the same say fixed on board pheriperials say connnected to spi ports (say the spi flash boot rom)

 

---

then that there is a different problem (addressed a few comments earlier), about many alternate functions on the same pin and pin mux e.g. that a same pin can have gpio + spi + uart + i2c + pwm + ...

I'm not sure if declaring all the functions being enabled (i.e. 'okay') would result in conflicts, or that if they are enabled means that the function becomes 'configured' and *active* and hence draw power.

But that i'd guess even if 'everything enabled ('okay')' there is still the pin mux which ultimately selects the function that is seen at the pin. just that in this case if all the functions (e.g. gpio + spi + uart + i2c + pwm) are concurrently 'okay' and if it cause it to draw power, the soc / chip will likely run *hot* even if it does 'nothing' (note I'm not sure if this is after all true).

If this is indeed the case, and that we only want specific pheriperials to be 'enabled' if it is used, we may end up having to define all the on chip/soc pheriperials and *test them*, but in the 'production' version mark them as 'disabled' so that specific (custom) overlays are subsequently added to address the *use case* for every particular scenario.

 

'research'

https://course.ece.cmu.edu/~ece742/S20/slides/Dark Silicon_ The Beginning of the End.pdf

Quote

“Dark Silicon”

 

Before 2006, transistor scaling (Moore’s Law) has mostly been followed by voltage scaling (Dennard scaling).

Around 2006, Dennard scaling failed such that it cannot follow Moore’s Law.

 

The extra transistors brought by Moore’s Law can no longer be powered on because it would violate the thermal design power (TDP) constraint 🔥

 

These unpowered/unused transistors are “dark silicon”.

 

well it matters, as in that if it is 'disabled' by default, chances are that the chip may run a degree or 2 cooler.

but that the 'inconvenience' is that anyone who wants to use those ports ( gpio + spi + uart + i2c + pwm + ...) would need to enable them themselves by means of dts overlays

it probably also address pinmux conflict issues

 

the hard part is to decide on *well defined* use cases, e.g. that the debug uart port is *mostly necessary* (i.e. a must, so that probably has to be configured 'okay' by default on every (different) board in its board specific dts. these days more than ever, SBC no longer have the 'luxury' of its own hdmi monitors and even for that matter with a full suite of usb keyboard and mouse (as like a desktop / notebook computer), and the 'debug uart port', is the only system console, to fix every other network problems ethernet / wifi, hdmi, display, etc.

 

or e.g. the 'alive' led status, blinking the leds is the most primitive (g)ui to tell the user that their board with the os is 'alive', never mind that they have serious network connectivity issues, but the board and os is running !

 

 

[Stephen Graf]

27 minutes ago, ag123 said:

take for example the 'bigtreetech cb1' board

I think the bigtree board is the one that is causing all this conflict. It is a very specialized board built for a specific function - to run 3D printers.  Bigtree paid Armbian to set up the image and they got the paid treatment regardless of the compatibility with other boards.  I suspect future h616 and h618 boards will be much more alike and not similar to the bigtree board.

 

As for the devices that hang on the spi and i2c buses, there are hundreds of them.  Go to AliExpress and search for "i2c device".  There is no way to provide overlays for each of them.

 

My suggestion is to provide overlays for the the main i/o that the SBC advertises and brings out to the headers.  If users want to implement some of the other muxed functions then it should be the users responsibility to provide a user overlay which does not impact the build environment.  Yes there will be many overlays that are common between boards and yes there will be some overlays that are not.  The difficulty is how to deal with the overlays that are not in common.

[pixdrift]

1 hour ago, Stephen Graf said:

My suggestion is to provide overlays for the the main i/o that the SBC advertises and brings out to the headers.  If users want to implement some of the other muxed functions then it should be the users responsibility to provide a user overlay which does not impact the build environment.  Yes there will be many overlays that are common between boards and yes there will be some overlays that are not.  The difficulty is how to deal with the overlays that are not in common.

I think this is a really important point to re-iterate. This discussion isn't trying to solve implementation for third party hardware devices with these overlays, this is specifically to support the features that the vendors provide on the boards (and board specific expansions), but in a modular/flexible way.

In terms of 'addons' this is limited to the expansion boards which are specific to the hardware such as Orange Pi Zero2/3 expansion board, and the same with the Zero2W expansion board, which is also specific to that hardware. This isn't to bundle overlays for third party devices as @Stephen Graf has mentioned.

Edited January 23 by pixdrift

[MrK]

@pixdrift No problem.

 

I reckon I can say I am proficient in hw to some extent and I do have still decent tools like the Hp logic analyzer which can bust or confirm some statement.

The Hp16702 was top class analyzer in 2000's. It is versatile tool running HP-UX so telling almost everything about its features would make this reply very long so maybe not this time.

 

I am glad you are positive about my contribution so I look forward to doing even more.

@ag123 I started with the spi because it seems to be good choice for interfacing fpga to orange pi zero 3. It seems viable to me and I'm familiar with verilog and xilinx xc3/xc6 families a bit. At least I used to be so I may have some good reason to recall it.

 

I will fork soon the armbian as you advised.

 

And thank you. Looking forward.

 

The patch I have posted here is composed of two parts

1. change to h616 dts - I followed sun50i-h6.dtsi

2. change to spi-sun6i.c - the change was result of my work on issue like why adding reference to dma in spi overlay is void and I figured out that of_dma_request_slave_channel() does not care about overlays.

 Only root dts matters so that's why dma_request_chan() failed and forwarded errno in pointer returned by the of_* function above.

so this change is new but the last one.

 

I am going to create more complex spi-sun6i patch in maybe 3 days or so (need to focus on things of certain prio right now)  which will allow to switch CS management to spi controller on demand and prepare some proof-of-concept userspace test cases + nice screenshots from the LA (logic analyzer).

 

 

 

 

 

 

[Gunjan Gupta]

7 hours ago, MrK said:

1. change to h616 dts - I followed sun50i-h6.dtsi

DMA related changes looks good. I have the same changes in my local git as well. One thing I do suggest is to add dma to spi0 as well. Currently you have only added it to spi1

 

7 hours ago, MrK said:

why adding reference to dma in spi overlay is void and I figured out that of_dma_request_slave_channel() does not care about overlays.

I am afraid I don't understand. Linux kernel will not be aware of the existence of overlay as they are applied by uboot. Unless ofcourse you used sysfs to load the same which is not the preferred way anyway. Do check uart output to see overlay was indeed loaded by u-boot and there was no error.

[MrK]

@Gunjan Gupta I was about committing the change about spi0 dma and decided to double check it. Bad news are that spi0 reports rx dma timeout.

So I can not do that. Strange is that dma works for spi1 when tested with spi-pipe it works. I added even a green jumper between miso-mosi to see if loop works and it does. Attached screenshots.

 

root@orangepizero3:~# ./spi-test1.sh
++ spi-config -d /dev/spidev1.0 -q
/dev/spidev1.0: mode=0, lsb=0, bits=8, speed=100000000, spiready=0
++ printf '\xde\xad\xbe\xef'
++ spi-pipe -b4 -n 1 -d /dev/spidev1.0
++ hexdump -C
00000000  de ad be ef                                       |....|
00000004
root@orangepizero3:~#

 

I tried to upload a screenshot of size of abt 3.3M and it did not work. Is there size limit applied ?

 

Here is the diff:

--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -625,6 +625,8 @@ spi0: spi@5010000 {
                        status = "disabled";
                        #address-cells = <1>;
                        #size-cells = <0>;
+                       dmas = <&dma 22>, <&dma 22>;
+                       dma-names = "tx", "rx";

 

I am sure of that dma channel is right. (double checked 616 user manual, dma section: 3.9)

 

spi-pipe passes two buffers for rx and tx and I don't know how flash driver uses spi driver. for example it may request one way transfer e.g. rx dma after sending flash read block/page command this might be the difference.

 

You are welcome to give a try by yourself and let's see if this is something which happens to me or something "almost there" like the wifi issue. wifi is longer story I found the same assert issue in firmware reported 2 years ago. ok, not this time.

 

Let us know if adding "dmas=" property to spi0 works on your board.

 

And regarding 2nd issue, yes I was sure dtbo was loaded by u-boot and fdt appy did not complain about anything. You may see that my overlay is 858 bytes long while your should be abt. 699 bytes.

 

This because I added "dmas" property to overlay for the 1st time anyway this is not enough, dma channels will stay disabled just like I have explained.

Of course I had to add instance of dma device to h616 dtsi

otherwise fdt apply will fail and will not link overlay because of unknown reference. However I did not add "dmas=" to spi1 declaration in h616 dtsi. it was present to overlay only.

 

Give a try and I can make a bet you will spi driver complaining that it can't allocate tx and rx dma in kernel log while you have enabled it already in overlay.

 

 

 

 

[MrK]

so overall dma is not ready. spi1 seems to work because of spi-pipe pass and nothing else. I haven't tried anything else by now.

spi0 working with real device fails when dmas are enabled.