wierd network problem w cubieboard2 allwinner A20

[holm]

Hi,

 

I'm still experimenting with different "Linuxes" on that boards.. to get an LCD Display (LVDS) and the Ethernet part working.

 It cost me days to figure out that there seems to be an ugly glitch. with the stone age "cb2-dvk-sdcard-lubuntu-lcd v1.0.img"

I get an working X11 Desktop with 800x480 ..but Ethernet doesn't work. I've checked those fex files (script.bin, script.fex) but

couldn't figure out what's going on.

I think that doesn't interest someone besides me, ok., got that.

 

Now I've tried the actual "Armbian_community 24.5.0-trunk.667 Jammy with Linux 6.6.31-current-sunxi" that I've downloaded

from somewhere here (Armbian_community_24.5.0-trunk.667_Cubieboard2_jammy_current_6.6.31_xfce_desktop.img).

 ..No Ethernet ..if the cubieboard2 sits on the DVK521 breakout board from waveshare.

If I pull it from there and run it solo..ethernet is working.. plug it back .. no Ethernet.

I've disconnected the LCD and pulled all the jumpers on the board that connects "on board hardware".. no Ethernet.

 

So the DVK512 is bad. ..really? 3 of them, new and unused ..at once?

 

A year ago I've build a FreeBSD for that board, let's have a look:

 

"FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC                    
                                                                                
Welcome to FreeBSD!  

 

[..]

To change this login announcement, see motd(5).                                 
root@cubie2:~ # # ping forum.armbian.com                                          
PING forum.armbian.com (5.161.66.254): 56 data bytes                            
64 bytes from 5.161.66.254: icmp_seq=0 ttl=47 time=97.410 ms                    
64 bytes from 5.161.66.254: icmp_seq=1 ttl=47 time=96.099 ms                    
64 bytes from 5.161.66.254: icmp_seq=2 ttl=47 time=96.424 ms                    
64 bytes from 5.161.66.254: icmp_seq=3 ttl=47 time=95.877 ms                    
64 bytes from 5.161.66.254: icmp_seq=4 ttl=47 time=95.936 ms                    
64 bytes from 5.161.66.254: icmp_seq=5 ttl=47 time=95.989 ms                    
64 bytes from 5.161.66.254: icmp_seq=6 ttl=47 time=96.083 ms                    
^C                                                                              
--- forum.armbian.com ping statistics ---                                       
7 packets transmitted, 7 packets received, 0.0% packet loss                     
round-trip min/avg/max/stddev = 95.877/96.260/97.410/0.497 ms                   
root@cubie2:~ # "

 

..needless to say that the cubieboard2 sits on its DVK521 and there is no difference if the LCD is connected or not,

and if additionally all jumpers are plugged in. That DVK521 Board is nothing other as a breakout board, converting

the 2mm headers to the usual 2,5mm ones. If no LCD or additional hardware is connected the is no load on the lines,

even the PL2303 is powered separate from the 4 Pin header on the Cubieboard.

 

Allwinner has made the mistake to steal GPL'ed code, therefore all the old archives are now empty. Most of the files and

even posts relating to the cubieboards that I've got came out of archive.org.

Here is the schematic from the cubieboard (cubieboard 1, but the only difference to cubieboard2 ist the A10 processor instead

of the A20, so it is the same schematic) and here the schematic of the DVK521 board.

 

https://www.tiffe.de/other/cubieboard_schematic_2012-08-08.pdf

https://www.tiffe.de/other/DVK521.pdf

 

There must be something wrong with a floating Pin or some such wenn Linux runs, FreeBSD seems to be unaffected. It isn't relevant if

Linux runs with the old fex and script.bin mechanism or the modern way with that Device Tree..

 

Please give me a hint how I can figure out what's going on here. For an Linux Newbee it's really difficult.

 

Regards,

Holm

 

 

[CryBaby]

I have no clue, but maybe you will find one in the system logs.

[holm]

..if that where the case, I don't had this problem.

 

But yes, since you ask niceley, I'll append the logs here later today.

 

Regards,

Holm

[holm]

ok, here is the output of  journalctl -b attached, Ethernet not working. I couldn't find a cause in there.

 

The interesting thing is, sometimes it works, sometimes it don't. Floating input or something?

 

Regards,

Holm

Armbian-cap

[CryBaby]

That looks like it is working to me. I have been fiddling with my cubietruck recently and I notice that it doesn't always connect to the network too, so maybe the problem has nothing to do with your carrier board.

[holm]

My problem seems to have nothing todo with hardware at all. None of my problems have their source in the hardware.

My Idea was that "Armbian" and "sunxi" sounds like a solution to get my project running, but as longer as I'm trying

it gets clearer and clearer that it isn't a solution, it's the source of the problems.

"community support" should get renamed to "no support", you are at you own.

 

I've tried a year before and it was impossible to ad a 2nd uart running with that overlay mechanism, but X11 worked and

ethernet worked. Now a year later the uart works but other things are broken. The documentation isn't better as before,

you get hundrets of outdated hints or websites with dead links.

 

Sorry, if I have to investigate all things myself w/o documentation or any help from other users or the developers, I could

use FreeBSD where I'm familiar with., but there are still other linuxes to try, plain debian and openwrt.

 

I'm giving up here, that stuff is simply unusable like it was a year before.

 

Regards,

Holm

Edited May 29 by holm

[holm]

Maybe that's the cause of the trouble?

"

GMAC

Allwinner's A20, A31/A31s and the A80 contain a MAC unit called GMAC ("Gigabit MAC"). The controller supports MII and RGMII modes. On the A20 it is pin compatible with the EMAC in MII mode. Also on A20 the manufacturer of the device in question can decide whether to use EMAC or GMAC. The controller is an early version of the Synopsys DWMAC (DesignWare MAC), with some hardware specific glue.

The SoC's GMAC is always combined with an external PHY, in most cases a RTL8211E/CL (the Lamobo R1 uses the Broadcom BCM53125 switch IC instead). Important: In this special mode the RTL8211 chip is just used as PHY and only responsible for layer 1 operations, since everything else happens inside the SoC's GMAC (therefore no RealTek drivers are needed and some functionality differs, e.g. no WoL possible).

For reliable Gigabit networking (1000Mbit operation), several sunxi devices require an important tweak that adjusts the relative timing of the clock and data signals to the PHY, in order to compensate for differing trace lengths on the PCB (details). Among others, this includes Banana Pi/Pro, Cubietruck, Lamobo R1, pcDuino3 Nano and Orange Pi/Mini. Recent mainline U-Boot uses CONFIG_GMAC_TX_DELAY to initialize these devices accordingly. If a necessary GMAC TX delay isn't set, then GBit Ethernet operation might be unreliable or won't work at all. 10/100 Mbit/sec negotiation is unaffected, so misconfigured devices could actually work (faster) when connected to a Fast Ethernet port instead of a GBit Ethernet port."

 

https://linux-sunxi.org/Ethernet

 

Regards,

Holm

[holm]

The problem was discovered in 2017 HERE:

..and no one came to the conclusion that a pcDunio isn't the only platform with Allwinner A20 where it is relevant?

 

Holm

[CryBaby]

CONFIG_GMAC_TX_DELAY seems to have been added to uboot in 2015 so the question is is it being set in armbian? I don't know if it can be set in bootEnv.txt or you have to set it at build time. I don't have access to my cubietruck right now...

[SteeMan]

A quick look shows:

Current u-boot sets CONFIG_GMAC_TX_DELAY = 1 (I didn't look at history if this has changed over time)

(https://github.com/u-boot/u-boot/blob/ea722aa5eb33740ae77e8816aeb72b385e621cd0/configs/Cubietruck_defconfig#L11)

and there is no patch in Armbian for Cubietruck that changes that value:

(https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-sunxi/board_cubietruck)

 

It should be fairly simple to test different values to see if that addresses the problem and submit a PR to Armbian (or to upstream u-boot) to fix

[holm]

Hi SteeMan ..you are right, it may be simple, you just have do set up a buildroot, compile an test the image, I'll ask my (good) wife (urology chief-nurse) if she want's todo it.

Maybe my old retired Neighbor (75 this year) also want's to submit an PR for at thing that is known since 2015 as you say. (I think he has to learn english for that..besides of unix/linux

but that should be easy as you say). Can you please provide a list of all different boards that may affected from that problem that's known for 9 years here? I'll try to activate all my

neighbors in the meantime.

 

Sorry man, do you still have all of the noodles on the dish?

 

You are complaining here that the Armbian project doesn't have enough recources available to support all that platforms, but if one asks for help to find the bugs, you

don't have enough resourecs for only an hint... If one submits an PR that affects an entire class of plattforms around a cpu, you wan't to get a PR for every single HW

implementation?

 

It think it's no wonder that you don't have  enough recources... who want's to deal with such guys?

 

Regards,

Holm

 

Sorry, but I'm a old white man .. so an asshole anyway...

 

Edited June 1 by holm

[SteeMan]

@holm  The board you are using is not supported or maintained by Armbian.  It is Community Maintained.  That means that no Armbian resources exist to support this board.  It is up to people outside Armbian to submit PRs to keep it alive.  That is what it means when Armbian says it lacks resources to maintain hundreds of different boards out there.

What Armbian provides to you free is infrastructure, automated builds and a forum.  It is up to you or others who care about this (or any Community Maintained board) to submit PRs to keep it alive.

 

I'm just a moderator of the forums trying to help.

 

If you really want to complain to someone, instead of complaining to those of us here trying to help you for free (as I volunteer my time to receive the abuse you just gave to me), you should complain to the company that took your money for their board but then don't provide any software support for what they sold you.  They just take your money and run, and hope others (like Armbian) will support their hardware without any compensation.

[holm]

Zitat

@holm  The board you are using is not supported or maintained by Armbian.  It is Community Maintained.  That means that no Armbian resources exist to support this board.  It is up to people outside Armbian to submit PRs to keep it alive.  That is what it means when Armbian says it lacks resources to maintain hundreds of different boards out there.

What Armbian provides to you free is infrastructure, automated builds and a forum.  It is up to you or others who care about this (or any Community Maintained board) to submit PRs to keep it alive.

 

Oh yes,  you are taking the easy looking way, don't you?

To make it less easy for you: how about the support 9 years before now?

Why wasn't the patch (including that PR in 2017) followed by a repair of all that systems that are affected? (to this time)

If Armbian where not Armbian but Debian and there where a Bug with an Intel-something processor, would you really ask for an PR for every single Motherboard

that supports that CPU?

 

Before I'm trying to submit PR's that  keep something alive, I'm trying to ask ..you can easily find my questions and the  begging for help in this forum

(begun almost a year before now), where have you (and the others) been? I can only see CryBaby, not with a solution but with a similar Problem.

Before I can submit an PR, I first have to understand the entire build architecture of that buildroot (no, I'm not familiar with that) and where to apply

my patches.  It wehre at you to give me hints (or other people here that already know that stuff) how to handle that and finally make your project better,

ha, sorry  forgot it for a moment..no time, no recources..not interested.

 

I'm complaining, yes!

..because you aren't doing your (free time) job right. In no circumstances it should be necessary to find and fix the same bug over and over again

and that for years!  And yes, there where years with support for cubieboards2 and where ethernet wasn't working.....

You wasting time of people that want to use your work (for what it is made  for)  ...and that really wish to help to get things running, ..simply be ignoring them.

 

Zitat

..instead of complaining to those of us here trying to help you for free (as I volunteer my time to receive the abuse you just gave to me)

 

Sorry I don't remember that you tried to help.. in fact you told me I should solve the problem myself and then submit an patch...wasn't that you?

From my point of view that looks as you asking me for help...

You are NOT the "community" that is supporting something here, your help consisted of an recursive grep...

 

Since you have the idea I should complain to the company that build that board(s) ..I got them for free, trying to do something useful with them, only bought the breakout

boards for $20 and 2nd:

why you are developing Armbian here at all? There are companies that should provide support..companies for every board that you are supporting here..Why the heck you are here?

 

I understand that you are pissed of.. but you should get better arguments I think.

 

BTW: I'm pissed of too.. searching for problems that was already known 9 years before. Asking people that think it isn't necessary to answer,

complaining in a language that I've never learned.

 

Regards,

Holm

 

 

 

 

 

 

[SteeMan]

1 hour ago, holm said:

Since you have the idea I should complain to the company that build that board(s) ..I got them for free, trying to do something useful with them, only bought the breakout

boards for $20 and 2nd:

why you are developing Armbian here at all? There are companies that should provide support..companies for every board that you are supporting here..Why the heck you are here?

My last comment on this.

 

The sad reality is that what the handful of volunteers that are Armbian produce is on average the best support out there for these boards.  Many (I would even say most) of the other SBC builds out there take their code from Armbian and then add on a few things.

 

You talk about 'companies', there aren't any that support these boards.  The companies are the board manufacturers and they don't support their own products.

 

You ask why Armbian is here, it is here because people like me have a bit of spare time and want to help and find these boards a fun and challenging hobby.  But it is entitled people like you that make me not want to do this.

 

Finally, you have no investment in Armbian thus Armbian owes you nothing.  If you were paying for something here you might have a reason for your behavior.  But you are using something provided to you for free, as is with no warranty.  If it doesn't work then go find something elsewhere that you think is better (and good luck by the way).  Or since this is open source you can always fix it yourself.

[holm]

It was your idea that I should  complain at the company that made the cubiebords, not mine, that's why I've mentioned this.

My question was why you are here..then regarding your opinion should we all have support from the companies we bought

the boards from?

 

..no answer.

 

But again: I would try to help..at least in regard to the A20 SOC's, but they got out of your support anyways.

To do that, it isn't that comfortable to leave such people at their own and to have nothing to say to their questions.

Nobody is interested in warranties at all but I've got a problem and Armbian showed up with a slogan such as "community supported"..

In fact, there is no support at all and the bug existed already as there still was support. I tried a year before and I've tried now.

 

My question why "the community" should do investigations on the same bug over and over again for 9 years...no answer from you.

A year before there was "some kind of support" regarding the Armbian website..  I've invested time because of this. The principles of opensource aren't that new to me, but thanks for clarify it up again.

Must be that new thing with "quality is a myth" or something that give you the idea I had you to thank for something.

 

Ok, it is your "last comment on this"  so leave it as it is. Maybe I can figure out what's going on and tell it to other people here.

You could  have been helpful, but you don't wanted this. You have done nothing useful at all. You are complaining about your users, a really bright idea in my eyes. 🙂

Yes, of course I can fix this myself (since it is opensource as you mentioned above) ..but get my right, I can do this with or without you, there is no difference.

 

Regards,

Holm

 

Addition:

Zitat

The sad reality is that what the handful of volunteers that are Armbian produce is on average the best support out there for these boards.  Many (I would even say most) of the other SBC builds out there take their code from Armbian and then add on a few things.

 

It where really nice if this where the case, but you are dividing people in two classes, the one s with the newer boards and the ones with the older ones. The later only seldom gets the luck of beeng read from one of the developers...and then there is that no support thingy ...

 

Edited June 1 by holm

[MaxT]

It was your idea that I should  complain at the company that made the cubiebords, not mine, that's why I've mentioned this.
My question was why you are here..then regarding your opinion should we all have support from the companies we bought
the boards from?
 
..no answer.

...

Armbian showed up with a slogan such as "community supported"..
...
 
My question why "the community" should do investigations on the same bug over and over again for 9 years...no answer from you.
...

  I've invested time because of this.
...

You could  have been helpful, but you don't wanted this. You have done nothing useful at all.

Someone always should be liable that you are not happy with smth, and must do smth here and/or there to make you happy, right?

Just a few thoughts (I'm also not young):

Suggest you direct claims to Linux devs and enjoy having reply there (just find an appropriate mail list at lore.kernel.org, probably in the MAINTAINERS file in Linux sources). If the board isn't supported in mainline, that's another reason to complain and ask why the hell they are there. Will appreciate if you share reply here when you get one.

I guess armbian people are here because they enjoy playing with SBC and to the extent acceptable for them help others, but obviously (for me at least) without any sort of guarantees or promises

As to the community, suggest you think of yourself as the only member of the Community currently having interest in this particular board, facing this particular issue and having enough time. Probably an answer why you have not got any reply will be clear. So you also might what to blame other owners of the board who are not on this site and dropping all their current affairs just to do what you need.

You also might want to find the person fixing the bug in question 9 years (?) ago and raise complaints on why that asshole have not fixed the bug for all boards to him and change him your time invested so far, otherwise that time is your time, no one got any value (now you know more than before ) out of that investment except yourself, so that's your R&D.

At to usefulness, seems there are quite many people finding this project useful, probably not all their expectations are met, but still, and I guess they are happy that there are knowledgeable people that might have will/time to help. Even if not, no one has any right to try insulting the team.

Some people become wiser as they get older, some not, where are you with this?

[holm]

smth -v please

 

..to make it short: Helpful where an answer like "you have to set the value in /armbian/build/path/to/some/$board/patch file and generate an new image with ./compile.sh -something" ..that is an helpful and generic information about what todo and it is totally independent of is a board supported or not or if one of the developers is knowing exact that board or not.

Otherwise a user has to investigate where he can get the buildroot from (yes github) and then has to reverse engeneer what some people tought it where a good idea to do things. That's a heavy job for one that just

wanted to download an operating system image and use it. The Intention that he has to be an Linux developer that has to build kernels and u-boot images is an entirely different thing!

 

But it seems that it is totally normal that one that has a problem here doesn't get such answers, here you get answers that try explain that the user is an asshole and has to help itself, like the one from you.

Please tell your Idea why an CPU related bug must get an PR for every single bsp package to your barber, maybe he is interested in your interpretation...

 

Zitat

Some people become wiser as they get older, some not, where are you with this?

 

Maybe a little more far as you, I've learned in the meantime that my time is getting shorter.

 

Es war mir ein Vergnügen,

Holm

 

 

[Werner]

off-topic

closed