barish

Members
  • Content Count

    64
  • Joined

  • Last visited

About barish

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Bremen Germany

Contact Methods

  • Website URL
    https://nashorn.eu

Recent Profile Visitors

880 profile views
  1. Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!! Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really s
  2. Could one of the experienced developers advise me please, if I am right with my above assumption? I don't want to make an unnecessary PR for the documentation, if I haven't understood correctly the process.
  3. I followed the documentation and cloned the repo in the Host first, changed to config/templates and started the Vagrant virtual machine. If I am not mistaken, inside the Guest, the repo is cloned again for the actual development. This implies that cloning on the Host system has only the purpose to provide config/templates/Vagrantfile and config-vagrant.conf, is that right? All other cloned files on the HOST have no relevance (except for the directories userpatches and output, which are mounted)? I find that quite confusing and if I am right with my assumption, I would like to add
  4. I finally managed to get a stable U-Boot for my EspressoBin v7 with 1GB DDR4. I changed lib/main.sh to replace github.com/MarvellEmbeddedProcessors/A3700-utils-marvell with github.com/globalscaletechnologies/A3700-utils-marvell as well as some other lines – would there be a more elegant way to patch this, I would love to know? I changed config/sources/families/mvebu64.conf too to use the repository by GlobalscaleTechnologies and I even tried out the current U-Boot 2020.10 instead of Marvell's old U-Boot – I have not encountered any errors. Should I make a pull request for these cha
  5. Many thanks, Werner, for the hint! I just found out that we have no direct influence on the U-Boot since it is also provided by Marvell/Globalscaletechnologies and they do not provide a newer version.
  6. Well, I am building all then, time is not everything... The resulting U-Boot gives me a version string: U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian Does this mean that U-Boot version is 2018.03? If so, how can I possibly change to a current U-Boot?
  7. If I build all it works fine (but takes a long time, and I want to experiment with u-boot parameters).
  8. I tried to build the espressobin u-boot only with the command given in the docs: ./compile.sh 'compile_uboot' But I get ... COPY u-boot.bin CFGCHK u-boot.cfg rm: missing operand Try 'rm --help' for more information. [ o.k. ] Building flash-image-DDR3-512m_1cs_0-600_600.bin cp: cannot stat 'build/a3700/debug/flash-image.bin': No such file or directory [ o.k. ] Building flash-image-DDR3-512m_2cs_0-600_600.bin cp: cannot stat 'build/a3700/debug/flash-image.bin': No such file or directory ... Do I need more/different parameters or a different config-default.conf ? Sor
  9. I purchased 10 and will most probably buy more in future. :-P I had no issues with U-Boot 17.10 despite intensive testing. If you are in Germany, I can offer you a tested EspressoBin v7 1GB.
  10. My guess is that your Linux got corrupted and you should copy the backup of your SD card to a new SD card and try with that.
  11. I changed now to the legacy U-Boot (17.10) because it boots very reliably (which is what I need). I am not sure of the negative effects (testing is ongoing) but there is no option for me at the moment. I hope that someone with U-Boot and/or Marvell skills can tell me what changes from 17.10 -> 18.12 led to the unreliable booting. Since it takes place at the start of the WTMI RAM tuning process, I can only assume that there is the rub.
  12. By now, I found some more information regarding TIM and WTMI. According to Marvell's A3700-utils documents, TIM is a first aproach to address DDR3/DD4 at fixed freq of 300/400MHz, while WTMI "performs dynamic DDR PHY training" to gain higher memory speed. Apparently, the Armbian U-Boot uses a later version of WTMI (and maybe uses different parameters?), does anyone know about this?
  13. Then change fstab device to mmcblk1p1 or even better to the UUID of the SD card, no?
  14. Can anyone tell me what are the differences between the legacy U-Boot WTMI-armada-17.10.5-bb8f823 and the one used by Armbian ( WTMI-devel-18.12.1-e6bb176 )? The unmodified boards boot perfectly each time, but when I change to Armbian u-boot, no matter what frequency (I tried 800 and 1000 MHz), the boards need one to four power cycles till they boot even into u-boot. On serial console, I get: TIM-1.0 WTMI-devel-18.12.1-e6bb176 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.108V And that's it. I need to pull the power plug and put it back in for several times, then finally the bo
  15. As a workaround, try putting the following line into /boot/armbianEnv.txt: rootdev="/dev/mmcblk1p1" Or modify and compile boot.cmd accordingly. Why the SD card's device has changed though, I cannot tell. I know that Linux changes device names for HDDs, which might be called /dev/sda or /dev/sdb with no apparent hardware or software change.