zador.blood.stained Posted August 18, 2016 Posted August 18, 2016 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.
Igor Posted August 18, 2016 Posted August 18, 2016 I am fine with Pine legacy. Can be included in next batch ... With Lime2 -> the diff is uboot and DTB?
zador.blood.stained Posted August 18, 2016 Author Posted August 18, 2016 With Lime2 -> the diff is uboot and DTB? Yes, but u-boot can be shared between eMMC and non-eMMC version since we probably won't have NAND support in u-boot for a while.
Igor Posted August 18, 2016 Posted August 18, 2016 Than we could solve it this way? http://www.armbian.com/banana-pi-plus/
zador.blood.stained Posted August 18, 2016 Author Posted August 18, 2016 Than we could solve it this way? http://www.armbian.com/banana-pi-plus/ 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.
Igor Posted August 18, 2016 Posted August 18, 2016 Or if we only provide a lime2emmc uboot for apt-get ? ("in case of troubles / recommended"?) ... or going lower for all?
zador.blood.stained Posted August 18, 2016 Author Posted August 18, 2016 You have to boot the board first to use apt-get, and according to @chradev there may be problems with this, at least on some boards. (loop mount image + chroot + QEMU is not a user-friendly option to offer compared to 2 simple commands on BananaPi+ page)
Igor Posted August 18, 2016 Posted August 18, 2016 Than let's provide one dedicated CLI image, Xenial server and voila.
tkaiser Posted August 19, 2016 Posted August 19, 2016 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 2
tkaiser Posted August 19, 2016 Posted August 19, 2016 Update: Oliver Schinagl is going to test soon: https://irclog.whitequark.org/linux-sunxi/2016-08-19#17300528;
zador.blood.stained Posted August 19, 2016 Author Posted August 19, 2016 Update: Oliver Schinagl is going to test soon: https://irclog.whitequark.org/linux-sunxi/2016-08-19#17300528; Yes, I'm keeping an eye on IRC logs. I hope results can be applied to both variants (NAND and eMMC) and all revisions.
Recommended Posts