17 17
lanefu

Espressobin support development efforts

Recommended Posts

Built! Installed! Port order flipped! That was easy!

 

I'm leaving it running to make sure I don't see any freezes or kernel panics.

Share this post


Link to post
Share on other sites
21 hours ago, ebin-dev said:

So - I can't confirm that the patched kernel would work without issues on a V5_0_1 EspressoBin with the current boot loader.

 

@FlashBurn @ebin-dev

 

Should we consider the patch PR a WIP and leave open until the v5 stability is figured out?

Share this post


Link to post
Share on other sites
18 hours ago, lanefu said:

Should we consider the patch PR a WIP and leave open until the v5 stability is figured out?

 

Since the patch is not working for all EspressoBins I would suggest to consider it a WIP or to delete it. Marvell already allocated resources in order to solve the issue. 

 

Edit: I have tested patched kernel 4.19.20 on three V5 EspressoBins - one used and two new ones. All of them produce the same issues (i.e. a kernel panic "Internal error: synchronous parity or ECC error" with bootloader 1000_800). With this patch applied we risk to lose the installed base of V3-V5 EspressoBins. It is simply not enough to just change parts of the cpufreq code - the problem has a wider scope and the bootloader probably needs some adjustments too.

Share this post


Link to post
Share on other sites

The patches which where sent to the kernel mailing list are the same as the one in my pull request.

 

As for me the newer kernels also do not work (kernels without my patch) is this not a problem of the patches, but of something which is wrong in the kernel.

 

Edit::

 

Some more notes regarding the pull request.

 

Situation now:

 

Firmware running 1000 MHz, real cpu frequency is 800 MHz.

 

Situation with the patch from the pull request:

 

Firmware running 1000 MHz, real cpu frequency is 1000 MHz.

 

So if the board does not run with 1000 MHz, but it did before, just flash the firmware with 800 MHz cpu frequency and it has the same performance like before, but everyone can run the board at the right cpu frequency.

 

Just to be clear, I don´t see the problem why not applying the pull request. The pull request fixes 2 bugs and now things work as expected, but it also maybe does show that some boards are not running up to their specs.

Share this post


Link to post
Share on other sites

I built kernel v4.19.20 as described above and it seems to be running stably on my (previously known stable) v5 and v7 hardware at 1GHz.

The only change to "patches" that I made was the switch of wan and lan1 (which, I think,  had been backed out of next).

The v7 (my main focus) has been up over 48 hours the v5 less than 12 hours, but I'm leaving it running and will update tomorrow.

 

Share this post


Link to post
Share on other sites

@spqr

 

I have to be picky, but your board does not run at 1 GHz, but 800 MHz and that is why it is stable ;) We still don't know if our boards are running stable with 1 GHz without fixing the cpu scaling bug. But as your board boots justs fine at 1 GHz your board is doing better than my V7 board.

Share this post


Link to post
Share on other sites

Sorry, I didn't know this. I assumed that because I used the u-boot 1000-800 (ddr3 1 GB RAM 2 chip) for the v5 I was running at 1GHz.

I'm really only messing with the v5 as a "lab experiment" because I've been ordering v7 for my application.

(FYI The v5 I have has no been up well over 24 hours on the kernel I built with no panics or freezes.)

Stability on v7 has been fairly elusive and I don't know if that was just bad luck or some actual hardware issue that isn't being properly handled.

I'm awaiting answers from Globalscale but continuing to make (software) progress on my project with the v5 and three working v7 units I have.

Share this post


Link to post
Share on other sites

Um... wait, really I'm not running at 1GHz? This is my v5.

 

root@espressobin:/var/log# tail armbian-hardware-monitor.log                    
                name: SS08G                                                     
                                                                                
### Boot system health:                                                         
                                                                                
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU                     
20:11:06: 1000MHz  1.18  78%  37%  38%   0%   2%   0% -75000°C                  
20:11:07: 1000MHz  1.16  60%   7%  50%   1%   1%   0% -75000°C                  
20:11:07: 1000MHz  1.16  60%   7%  50%   3%   0%   0% -75000°C                  
20:11:07: 1000MHz  1.16  67%   9%  56%   1%   0%   0% -75000°C                  
20:11:08: 1000MHz  1.16  93%  12%  79%   2%   0%   0% -75000°C                  

Share this post


Link to post
Share on other sites

Hey this is just kind of a general question..    i have a v4 board does it have an additional set of irregularities that i need to worry about.     Like are the assumptions for v5 that i cant make for v4?

Share this post


Link to post
Share on other sites

Just my 2-cents on the ethernet port ordering issue...

Even though boards prior to v7 had the port naming flipped, it seems more "industry standard" to have the wan port on the left.

Now that globalscale is shipping cases and the metal version has WAN screen printed on the left one (which is also separated off from the

other two) would it really offend any v5 users if the order changes?

I think it would be good to just commit that change unless some v5 users really feel strongly about it...

 

Share this post


Link to post
Share on other sites
1 hour ago, spqr said:

Now that globalscale is shipping cases and the metal version has WAN screen printed on the left one (which is also separated off from the

 

Continuity is a fantastic justification.  One ask..  come up with easy to understand paragraph to explain the difference that we can add to the board download page, etc

Share this post


Link to post
Share on other sites

I just gave a hunch a try and this is the result running sbc-bench stable at 1000 MHz:

 

sbc-bench.sh log output

 

If anyone wants to test this kernel I could upload it to dropbox for everyone to download.

 

As my board was reacting kind of unpredictable, my assumption was that there is a hardware problem with stability, but only at 1000 MHz. So my guess was that the core voltage is to blame, but as the board does run fine at 1000 MHz, it has to be a problem of the core voltage at lower frequencies. So I made a kernel without activating the AVS (automatic voltage scaling). This seems to solve the stability problems on my board. Next step would be to try to let the AVS not use so low voltages, but at the moment I don´t have the time to try this out. I will tell these findings to the linux kernel developer of the cpufreq driver and we will see if he can fix it.

 

Share this post


Link to post
Share on other sites

Interesting.  Is the kernel developer connected with Globalscale or Marvell?

I returned my batch of failing units to Globalscale and they have reproduced and are looking into the problem.

It could be completely unrelated as well... but maybe not.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
17 17