pixdrift

Welcome @VioletGiraffe, thanks for joining the forum and letting us know you can test

Must be quite a journey reading the whole thread for the history now, well done 

In terms of video out, I don't think there has been any specific focus on it and as @Stephen Graf may not be currently supported, but keep an eye out for updates here.
 
I think mainline is good to build off currently, there are no big PRs pending except the Overlay work which may not interest you as it's GPIO related. The options vary based on what OS you're using, but I generally use Edge Kernel, Debian OS and XFCE Desktop options for testing. I can be more specific if you need

Has anyone got information on this slightly different Transpeed variant (M98-8K)?
https://www.aliexpress.com/item/1005006078280236.html

Apparently it's also H618 based, but advertised as Android 13 with a different case without the clock on the front (but most other specs look the same). Would be interesting to see if this board is the same internally and would also work with the same images being built here.
 
If you have this TV box or have photos of the insides, please let us know!

Yes! That is what I was looking at right now. Thanks iun cuim. I was stuck on the 100mbps ethernet. But it seems Warpme got it working. So I'm going to focus on his patches and see if I can get Transpeed working on Armbian. I got this TV Box a month ago and I didn't know Warpme already did most of the hard work. 

I've been trying to find the DRAM setting for this board. I found a firmware update that might help. Got it from androidpctv.com/firmware-transpeed-h618/ . I used the firmware unpacker from xdaforums.com/t/tool-imgrepacker-livesuits-phoenixsuits-firmware-images-unpacker-packer.1753473/ .
I used the Windows version of imgRePacker.exe to extract the boot0_nand.fex. Then read the boot0_nand.fex in linux using command hexedit boot0_nand.fex. It looks very close to the boot0 Andre Przywara used to find the DRAM settings on his board. lore.kernel.org/linux-sunxi/2123971.irdbgypaU6@jernej-laptop/ . 
 
You can see 03 03 03 03  0E 0E 0E 0E in hexedit.   
 
CONFIG_DRAM_SUN50I_H616_DX_ODT=0x03030303 
CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
 
Not sure if this will work with our board. But if we can try these settings or find another firmware for our board. We might get past the DRAM setup errors.

Hi Mag911
Awesome, I was hoping my posts would help others with boxes based on the H618. Like ag123 pointed out. There are a lot of boxes that are similar but with different configurations. If I can post enough information and steps on how to setup these boxes we can get enough of them up and running. These boxes are now adding more RAM and larger eMMC's. I think it's a good time to support Armbian development on TV boxes. The original Android that came with this box was very basic. It wouldn't allow me to install most the apps I wanted. So I decided to hack it. 
Is HDMI and WIFI now working on your box?

I found the wifi firmware needed for this box. Download and rename the file to "brcmfmac4335-sdio.transpeed,8k618-t.bin". Place it in /lib/firmware/brcm.
https://github.com/LibreELEC/brcmfmac_sdio-firmware/blob/master/brcmfmac4335-sdio.bin
 
Also needs the brcmfmac4335-sdio.txt. No need to rename it just place it in /lib/firmware/brcm.
https://github.com/LibreELEC/brcmfmac_sdio-firmware/blob/master/brcmfmac4335-sdio.txt
 
 

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?

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  

$ 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.

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) 

@MrK I missed your messages earlier and I can see your frustration.

The challenge for me personally is my ability to understand what you're proposing in your changes as I am just not at that technical level (a weak mind ), but I wish I was! That absolutely doesn't mean your changes aren't valid (or correct), but I am concerned (as I believe others are) that Armbian may not be the place for these improvements to be added, and they should perhaps be discussed in a kernel dev mailing list etc. and then make their way into Armbian by way of kernel changes? I understand @Gunjan Gupta questions/concerns about changing things (potentially unnecessarily) as I feel Armbian don't want to end up maintaining a kernel patch set very few in the project understand

Do you have the details for the mailing lists which deals with the components you're discussing? If not, perhaps someone from the forum can assist with a link and/or suggestion for how to get these patches/changes to the right place.
 
I really value your technical knowledge and experience in this space because I think what you're suggesting will improve the capabilities of the boards we're using, I just want to make sure these contributions are discussed with people responsible for this code upstream so everyone (even outside of Armbian) can benefit, and the changes can be discussed and maintained with like minded developers.

@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

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.

One possible option can be to convert the configs that are creating problems to be built as modules and then blacklist the modules using MODULES_BLACKLIST in board config.

Theoretically modules should get loaded automatically based on the compatible string in the dts. But we can always check if that is not the case and add MODULES to board config to force loading them.
 
Another option can also be to add status=disabled for the dts node in LonganPi's dts to disable the dts node belonging to the kernel module to prevent the module from coming into action.

@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 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?

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.
 
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?

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. 🙂

@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.

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.

Hi, the commit was merged: https://github.com/armbian/build/commit/1023f9d4204a4cd229a01a6dec498642f6790e43

@pixdrift The build I was using was one of your newer ones, tested by editing the dtb in armbian config. To check if gpu works, I tested with lsmod and Supertuxkart, works fine. 

Any reason why the mali gpu node is disabled by default (i.e. status is not set to 'okay')? https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero3-Enable-GPU-mali.patch

I have successfully tested 3D acceleration on Zero3, seems to be working fine.

"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.
Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.
 
If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.

Hi sander, welcome to the forum! Thanks for introducing yourself, always good to know there are others around willing to assist with testing

I'd say you're in the right place as I think Zero2W is where (at least my) focus will shift to next, just a bit early as we don't have anything to test.

As has been discussed in the thread, @Gunjan Gupta did some preliminary work in his own repo to get the Zero2W working, but I haven't had time to go through it and prepare a more formal patch for Armbian.
https://github.com/viraniac/armbian_build/tree/zero2w

This repo is provided with no support, as it's in heavy development, but if you wanted something to work with, this may help.