• Posts

  • Joined

  • Last visited

Profile Information

  • Gender
  • Location
    Bremen Germany

Contact Methods

  • Website URL
  • Github

Recent Profile Visitors

1186 profile views

barish's Achievements

  1. There is no way I know of to change environment parameters or U-Boot of the onboard SPI without UART access (I broke one off myself, it seemed to be very poorly connected to the board at the v5 models). If you compare the contents of the /boot directory: has there changed anything from the version that was running and the one you are trying now? Because, if boot.cmd (boot.scr) and armbianEnv.txt are still the same, the old U-Boot shouldn't have issues booting. Have a look if you can use the old files instead of the ones that come with the new Armbian, maybe that works (actually, boot.scr is the important file, the compiled version of boot.cmd ).
  2. With help from @Pali, I managed to put the Pull Request at the right spot, so when it's accepted, EspressoBin v7 1GB and 2GB will be stable with most current U-Boot and Marvell sources! Unfortunately, I have no board with 2GB, so maybe someone can test it who owns a 2GB v7. Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version. Edit: The Pull Request has just been merged. I will make a PR at Armbian Build to use newest Marvell repo branches.
  3. 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 stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors).
  4. 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.
  5. 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 a note to the documentation for future users. Or: Would it be possible to mount the whole repo to the Guest?
  6. I finally managed to get a stable U-Boot for my EspressoBin v7 with 1GB DDR4. I changed lib/ to replace with 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 changes? Edit: Or better make a pull request upstream...?
  7. 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.
  8. 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?
  9. If I build all it works fine (but takes a long time, and I want to experiment with u-boot parameters).
  10. I tried to build the espressobin u-boot only with the command given in the docs: ./ '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 ? Sorry for these maybe stupid questions, I am aware that I don't really see through the build system yet...
  11. 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.
  12. 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.
  13. 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.
  14. 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?
  15. Then change fstab device to mmcblk1p1 or even better to the UUID of the SD card, no?