0
zador.blood.stained

[RfC] Images for "new" boards

Recommended Posts

Mainline kernel 4.7 brought separate Device Tree configuration for Lime2-eMMC board.

 

What should we do with this board?

  • Don't provide separate images, write some basic instructions about changing Lime2 images to use eMMC
  • Provide separate images with mainline kernel
  • Provide separate images with mainline and legacy kernels

I remember about default DRAM frequency issues, but we always can lower default value in u-boot configuration patches.

 

 

Also I reworked Pine64 configuration and, now build process for legacy u-boot should be more reliable, and mainline (dev) target is also available for building.

I think we should start providing preliminary images (Jessie CLI) for Pine64 and Pine64+, at least with legacy kernel.

Share this post


Link to post
Share on other sites

Yes, but there still is a question about DRAM frequency, if default value for Lime2 is too high for eMMC variant, then we'll have to switch to separate images.

 

Why not decreasing DRAM clockspeeds for both variants and keep one image? My understanding is that literally no one ever tested DRAM reliability on any Lime2 (Olimex' Tsvetan proudly announced DRAM trace routing would've been improved compared to Lime and 532 MHz are possible based on playing video for a few hours since this is their usual test procedure). On the other hand based on forum discussions the serious Lime2 users are all interested in stability over laughable performance gains (downclock DRAM to 432 MHz and you loose how much percent performance in real world applications? 2? Or even 3?)

 

Edit: Here it's still 384 MHz, in our fex files it's 384 MHz and I wouldn't be surprised if the very same value is still used by Olimex themselves in their OS image for Lime2. So we currently deal with one 532 MHz claim made by a proud vendor that led to u-boot maintainer choosing 480 MHz (upper limit -- 532 not possible) and now all Lime2 users who rely on mainline u-boot have a problem, right? And everyone thinks this 480 MHz value is something that's the result of reliability testing but in reality it's quite the opposite and users face all sorts of problems.

 

Edit2: And here we're seeing 384 MHz, there again but there 480 MHz. But we still don't know where the 480 MHz originate from? Reliability testing or Tsvetan simply claiming '532 MHz!'?

 

Edit3: In mainline u-boot they rely on defaults which are 480 MHz (for whatever reasons) and according to their instructions they use it for both normal and eMMC variant. So we have 532 MHz as a 'it's working that fast!1!!' claim, 480 MHz as the results of trusting in this and 384 MHz as leftover from older Lime settings scattered all over the place. Why do we trust in any of these numbers?

 

Edit4: And after reading this I'm convinced we're dealing with random numbers without meaning :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0