Jump to content

Search the Community

Showing results for tags 'espressobin'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. I've been running the Ubuntu from GlobalScale until now. -I finally had a chance for switching to Armbian, so I did; now I'm running 5.50: Ubuntu Xenial (4.17.3). So far, I've installed it onto my SATA harddisk, it boots, network is available via DHCP, web-server is up, SSHD is up, I can update via apt-get, etc... But there's still one important piece missing; I need to make the IP-address static (which was one of the main reasons I switched to Armbian). On GlobalScale's forum, I get the impression that Armbian is much easier to configure static IP address for, but I have the impression that I should not touch anything /etc/network/interfaces*. Instead it seems I'm supposed to write something in /etc/systemd/network/ - I just have no clue what to write where. I'm assuming I'll be using the "WAN" interface, so my guess is I should change /etc/systemd/network/10-wan.network. -If my netmask is 255.0.0.0 and the static ip address is 10.0.1.2 and my gateway is 10.0.0.1, what's supposed to go where ? Currently, my 10-wan.network is unchanged and looks like this: [Match] Name=wan [Network] Bridge=br0 I've tried searching for Network manager and how to configure using it, but I just ended up more confused. :/ (I also tried selecting 'static ip' in Armbian-config, but it does not seem to do anything).
  2. Hi there, as already discussed here, https://forum.armbian.com/topic/5318-looking-for-an-enclosure-for-espressobin/?do=findComment&comment=49396 it seems that this 4-sata mini pci express card is supposed to be supported by armbian. As I wrote in that post, it doesn't work for me. I've tried Armbian default and next. The cards work, since I got them running with espressobin's Ubuntu distribution. Also, I've compiled a 4.4.52 Kernel according to: http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel It also works just fine with Armbian. So, my guess is that there's something different in the kernel config provided by linux-marvel and armbian when it comes to this chipset. For reference, I've attached the screen output from a boot with the sata card. I can not seem to find the kernel-config in the armbian-buildroot. Where do I find that? I've already set *KERNEL_KEEP_CONFIG="yes"* in default-config.conf Any help is aprreciated. Cheers! udo, screenlog.0.defauft
  3. Hi, similar to the issue reported in https://forum.armbian.com/topic/6566-le-potato-serial-getty-on-ttys0-starts-stops-restarts/ the /var/log/syslog file is being spammed with the following entries: Jul 11 00:37:04 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart. Jul 11 00:37:04 localhost systemd[1]: Stopped Serial Getty on ttyS0. Jul 11 00:37:04 localhost systemd[1]: Started Serial Getty on ttyS0. Jul 11 00:37:14 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart. Jul 11 00:37:14 localhost systemd[1]: Stopped Serial Getty on ttyS0. Jul 11 00:37:14 localhost systemd[1]: Started Serial Getty on ttyS0. Jul 11 00:37:25 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart. Jul 11 00:37:25 localhost systemd[1]: Stopped Serial Getty on ttyS0. Jul 11 00:37:25 localhost systemd[1]: Started Serial Getty on ttyS0. The only working serial interface is probably "/dev/ttyMV0" which is being brought up at boot together with "/dev/ttyS0": [ OK ] Found device /dev/ttyS0. [ OK ] Found device /dev/ttyMV0. I could observe this behaviour on the following ARMBIAN, kernel and U-Boot versions: ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.14.40-mvebu64, U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200) ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.5-mvebu64, U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200) Can this be fixed in armbian? Should I open a bug in git?
  4. Just in case someone else experience this problem, this might be a solution. In order to try and get my EspressoBIN to work with a port multiplier, I figured that I'd boot via a microSD card, which then does the real boot from SATA. But I had plenty of problems writing to my microSD card, which worked fine for the CubieBoard2 a few minutes ago. The thing I did wrong was to write (armbian) to the /dev/mmcblk1 using the DD command. eg. dd if=/some/path/Armbian_5.50_Espressobin_Ubuntu_xenial_next_4.17.3.img of=/dev/mmcblk1 bs=1048576 ... I also tried cp /some/path/Armbian_5.50_Espressobin_Ubuntu_xenial_next_4.17.3.img /dev/mmcblk1 -but that failed as well. So I decided to use a $1-china-crap USB-cardreader and insert in the USB2.0 port. I then used cp /some/path/Armbian_5.50_Espressobin_Ubuntu_xenial_next_4.17.3.img /dev/sdb ... and to my big surprise, this works! I do not know if there's something wrong with the microSD card slot on the board (it reads fine from it), or if it's something else. The only goal of this post is to tell others who experience problems with "wrong fs type" during mount attempts, even though lsblk shows it's "ext4", that they can try writing using a USB-card reader instead. - and just use 'cp' instead lf 'dd'; it does the job just as well (still you have to be careful that you're writing to the correct device, always think twice when you're writing to anything in /dev).
  5. I am running armbian 5.44 testing Debian GNU/Linux 9 (stretch) 4.14.40-mvebu64 on the espressobin and quite enjoy the default setting of plugin it into my my network without having to change anything (no changes to DHCP, routing, existing firewall and port redirection settings), but I have no way of introspecting the network like I would like. My project is to have a monitoring device on my home network that then helps me set up traffic shaping rules (eg. stop those annoying updates of the "other OS" from preventing everyone from using the internet, simple browsing rendered unusable). For that I want to use ntopng bridging and policying https://www.ntop.org/guides/ntopng/advanced_features/bridging_and_policing.html (haven't figured out yet if it's in the pro version or the community version), or simply a setup with fireqos and firehol https://firehol.org/#fireqos (which has some nice visualisation in netdata https://github.com/firehol/netdata/wiki/You-should-install-QoS-on-all-your-servers. On the espressobin forum, there is topic about the Topaz Switch asking if there is a low level bridge in the hardware that should be disabled and the answers there are un clear : http://espressobin.net/forums/topic/are-lan0-and-lan1-bridged-in-hardware/ I am stuck not being able to see the TCP traffic going through any of the network interfaces with jnettop, tcpdump or ntopng (which only sees udp and arp traffic). I've looked at the networkd default configuration and the brctl outputs which all look OK so far... I have tried a few things with ebtables and iptables, but failed and I am beginning to think that this is hardware related, the above mentioned thread seems to point that this is the case. (ebtables ressources are a bit scarse as far as I can find) I have flashed the uboot to a newer version to be able to use armbian, so I can do settings there if needed. I would really appreciate not having to turn this transparent switch into a router to reach my goal. Thanks in advance for any help or pointer on this matter.
  6. Don't know if this is a Arabian issue or a driver issue But i got a ath9k mpcie board in en ExpressoBIN running Armbian nightly WIP lspci 00:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter dmesg shows: 20.892457] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x44 [ 21.154426] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x4 [ 21.505762] ath9k 0000:00:00.0: enabling device (0000 -> 0002) [ 21.505794] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x3c [ 21.657293] dsa dsa@0 wan: Link is Up - 1Gbps/Full - flow control rx/tx [ 21.771223] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0xc [ 21.954333] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x4 [ 22.208975] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x40 [ 22.458432] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0xc [ 22.758269] Unhandled fault: synchronous external abort (0x96000210) at 0xffffff8000a84020 [ 22.995638] Internal error: : 96000210 [#1] PREEMPT SMP [ 23.000798] Modules linked in: ath9k(+) ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill bridge stp llc zram zsmalloc lz4_compress [ 23.013237] CPU: 1 PID: 462 Comm: systemd-udevd Not tainted 4.4.108-mvebu64 #6 [ 23.020813] Hardware name: Marvell Armada 3720 Community Board (DT) [ 23.020819] task: ffffffc038722e00 ti: ffffffc038628000 task.ti: ffffffc038628000 [ 23.020892] PC is at ath9k_ioread32+0x28/0x78 [ath9k] [ 23.020963] LR is at ath9k_hw_init+0xc0/0xad8 [ath9k_hw] [ 23.020967] pc : [<ffffffbffc1efd30>] lr : [<ffffffbffc161df0>] pstate: 80000145 [ 23.020968] sp : ffffffc03862b900 [ 23.020975] x29: ffffffc03862b900 x28: ffffffc038b7c068 [ 23.020979] x27: ffffffbffc202f60 x26: ffffffc038473420 [ 23.020983] x25: ffffffbffc203700 x24: 0000000000000000 [ 23.020987] x23: ffffffc038b7c068 x22: ffffffc038b7c068 [ 23.020991] x21: ffffffc0384706e0 x20: ffffffc038471420 [ 23.020995] x19: ffffff8000a80000 x18: 0000000000000a03 [ 23.020999] x17: 0000007f8bb33310 x16: 0000000000428018 [ 23.021002] x15: 0000007f8bcbe000 x14: 00000000000005c9 [ 23.021006] x13: 0000000000000003 x12: 0000000000000002 [ 23.021010] x11: 0000000000000000 x10: 00000000000007a0 [ 23.021014] x9 : ffffffc03862b850 x8 : ffffffc038723600 [ 23.021018] x7 : ffffffc03ffd8fc0 x6 : 0000000000000000 [ 23.021021] x5 : 0000000000000000 x4 : 000000000001035f [ 23.021025] x3 : 0000000000000032 x2 : 0000000000000000 [ 23.021029] x1 : ffffff8000a84020 x0 : ffffffc038b7c018 [ 23.021034] Process systemd-udevd (pid: 462, stack limit = 0xffffffc038628020) [ 23.021037] Stack: (0xffffffc03862b900 to 0xffffffc03862c000) [ 23.021043] b900: ffffffc03862b930 ffffffbffc161df0 ffffffc038b7c018 ffffffc038b7c018 [ 23.021047] b920: ffffffc0384706e0 ffffffc038b7c018 ffffffc03862b9a0 ffffffbffc1f07a0 [ 23.021052] b940: ffffffc038471420 ffffffc038b7c018 ffffffc0384706e0 ffffffc038b7c068 [ 23.021056] b960: ffffffc038b7c018 0000000000000000 ffffffbffc203700 ffffffc038473420 [ 23.021061] b980: ffffffbffc202f60 ffffffbffc1f0778 ffffffc038471420 00ffffc0378ff098 [ 23.021065] b9a0: ffffffc03862ba50 ffffffbffc1ff88c ffffffc0378ff000 ffffffc0378ff098 [ 23.021069] b9c0: ffffffc038471420 ffffffc0384706e0 0000000000000000 ffffffbffc201410 [ 23.021074] b9e0: 0000000000000001 ffffffc000120e50 ffffffc037cdccf8 0000000000000124 [ 23.021078] ba00: ffffffc03862ba50 ffffffbffc1ff86c ffffffc0378ff000 ffffffc0378ff098 [ 23.021083] ba20: 0000000838471420 ffffffc0384706e0 ffffffbffc202738 ffffffbffc201410 [ 23.021087] ba40: 0000000000000001 ffffffc000120e50 ffffffc03862bae0 ffffffc0005fe3b0 [ 23.021092] ba60: ffffffc0378ff098 ffffffbffc201410 ffffffc0378ff000 ffffffbffc203288 [ 23.021096] ba80: ffffffbffc203220 ffffffbffc203450 ffffffc000c8d568 000000002023d808 [ 23.021101] baa0: ffffffc03862bab0 ffffffc0006ca640 ffffffc03862bae0 ffffffc0005fe39c [ 23.021105] bac0: ffffffc0378ff098 ffffffbffc201410 ffffffc0378ff000 ffffffbffc203288 [ 23.021110] bae0: ffffffc03862bb20 ffffffc0006bfd3c ffffffc0378ff098 ffffffc000e6c000 [ 23.021115] bb00: 0000000000000000 ffffffbffc203288 0000000000000016 ffffffc000e6c000 [ 23.021119] bb20: ffffffc03862bb60 ffffffc0006bfec4 ffffffc0378ff098 ffffffbffc203288 [ 23.021124] bb40: ffffffc0378ff0f8 ffffffc000df15d8 ffffffc000e01000 ffffffc0006bfe50 [ 23.021128] bb60: ffffffc03862bb90 ffffffc0006bdebc 0000000000000000 ffffffbffc203288 [ 23.021132] bb80: ffffffc0006bfe28 ffffffc03862bbe0 ffffffc03862bbd0 ffffffc0006bf620 [ 23.021136] bba0: ffffffbffc203288 ffffffc038321f00 0000000000000000 ffffffc0009e1a58 [ 23.021141] bbc0: ffffffc039123ea8 ffffffc037947f68 ffffffc03862bbe0 ffffffc0006bf190 [ 23.021146] bbe0: ffffffc03862bc20 ffffffc0006c0678 ffffffbffc203288 ffffffc000dbb220 [ 23.021150] bc00: ffffffc038b84180 ffffffbffc20b000 0000000000000000 00000000ffffffd0 [ 23.021154] bc20: ffffffc03862bc40 ffffffc0005fd1b8 ffffffc000dbb220 ffffffc000dbb220 [ 23.021159] bc40: ffffffc03862bc50 ffffffbffc1ffbd0 ffffffc03862bc60 ffffffbffc20b00c [ 23.021163] bc60: ffffffc03862bc70 ffffffc000082950 ffffffc03862bcf0 ffffffc00015f46c [ 23.021168] bc80: ffffffbffc203400 ffffffc000dca000 0000000000000001 ffffffc038b84100 [ 23.021172] bca0: ffffffbffc203400 ffffffc000dca000 0000000000000001 ffffffc0389cb580 [ 23.021177] bcc0: ffffffbffc203400 ffffffbffc203450 0000000000000001 ffffffc000120e50 [ 23.021181] bce0: ffffffc037cdccf8 ffffffc0389cb5c8 ffffffc03862bd20 ffffffc00012407c [ 23.021186] bd00: ffffffc03862be58 ffffffc0389cb5c8 0000000000000001 ffffffc0389cb580 [ 23.021190] bd20: ffffffc03862be20 ffffffc000124810 0000000000000000 0000000000000014 [ 23.021194] bd40: 0000007f966d80f0 0000007f96617af4 0000000040000000 0000000000000015 [ 23.021198] bd60: 000000000000011d 0000000000000111 ffffffc0009f2000 ffffffc038628000 [ 23.021203] bd80: ffffffc000000064 ffffffc00000006e ffffffbf0000003f ffffff800000feff [ 23.021207] bda0: ffffffbffc20b048 ffffffc000a02280 ffffffbffc203730 ffffffc0024000c0 [ 23.021212] bdc0: ffff81a40b300001 0000000000000001 0000000000000000 000000000002f4c8 [ 23.021216] bde0: 000000005a4222a4 0000000000000000 0000000000000000 0000000000000000 [ 23.021220] be00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 23.021224] be20: 0000007feb928c10 ffffffc000085e30 0000000000000000 0000000000000000 [ 23.021228] be40: ffffffffffffffff ffffffc0000895b0 0000000000000000 ffffff8000995000 [ 23.021232] be60: 000000000002f4c8 ffffff80009c3d08 ffffff80009c3bd8 ffffff80009b66c8 [ 23.021237] be80: 0000000000015730 00000000000194e0 0000000000000000 0000000000000000 [ 23.021241] bea0: 000000000000d6a8 0000001e0000001d 0000000000000017 0000000000000011 [ 23.021245] bec0: 0000000000000014 0000007f966d80f0 0000000000000000 0000000000000014 [ 23.021249] bee0: 0000000000000000 302f2f2f2f753968 0000000000000000 0000000000000000 [ 23.021254] bf00: 0000000000000111 0000007f966969a0 0000007feb927b50 0000000000000003 [ 23.021258] bf20: 0000000000000000 0000000000000000 0000000000000000 0000007f967a6000 [ 23.021262] bf40: 0000007f966ea1d0 0000007f96617ad0 0000007feb9282c8 00000055929a20d0 [ 23.021266] bf60: 0000000000000000 0000007f966d80f0 000000559298f9b0 0000000000020000 [ 23.021271] bf80: 0000000000000000 00000055929948d0 0000000000000000 0000000000020000 [ 23.021275] bfa0: 0000007feb928da0 0000007feb928c10 0000007f966d1980 0000007feb928c10 [ 23.021279] bfc0: 0000007f96617af4 0000000040000000 0000000000000014 0000000000000111 [ 23.021283] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 23.021284] Call trace: [ 23.021349] [<ffffffbffc1efd30>] ath9k_ioread32+0x28/0x78 [ath9k] [ 23.021412] [<ffffffbffc161df0>] ath9k_hw_init+0xc0/0xad8 [ath9k_hw] [ 23.021462] [<ffffffbffc1f07a0>] ath9k_init_device+0x400/0xce0 [ath9k] [ 23.021511] [<ffffffbffc1ff88c>] ath_pci_probe+0x194/0x378 [ath9k] [ 23.021523] [<ffffffc0005fe3b0>] pci_device_probe+0xa0/0x118 [ 23.021530] [<ffffffc0006bfd3c>] driver_probe_device+0x1ec/0x2d8 [ 23.021534] [<ffffffc0006bfec4>] __driver_attach+0x9c/0xa0 [ 23.021540] [<ffffffc0006bdebc>] bus_for_each_dev+0x64/0xa0 [ 23.021544] [<ffffffc0006bf620>] driver_attach+0x20/0x28 [ 23.021547] [<ffffffc0006bf190>] bus_add_driver+0x108/0x228 [ 23.021552] [<ffffffc0006c0678>] driver_register+0x60/0xf8 [ 23.021556] [<ffffffc0005fd1b8>] __pci_register_driver+0x38/0x40 [ 23.021604] [<ffffffbffc1ffbd0>] ath_pci_init+0x18/0x38 [ath9k] [ 23.021652] [<ffffffbffc20b00c>] ath9k_init+0xc/0x48 [ath9k] [ 23.021659] [<ffffffc000082950>] do_one_initcall+0x90/0x1a0 [ 23.021666] [<ffffffc00015f46c>] do_init_module+0x60/0x1ac [ 23.021673] [<ffffffc00012407c>] load_module+0x188c/0x1df0 [ 23.021678] [<ffffffc000124810>] SyS_finit_module+0xb0/0xc0 [ 23.021683] [<ffffffc000085e30>] el0_svc_naked+0x24/0x28
  7. I purchased a 1GB EspressoBin off of Amazon with the plan to run Armbian + OMV on it. Here's what it looked like upon initial boot with factory firmware. Which showed 1GB version. TIM-1.0 WTMI-armada-17.10.1-b90dbf0 ENTER init_ddrgen DDR_TOPOLOGY is 4 : DDR3, 1CS 1G WTMI_CLOCK=2 Fill memory before self refresh...done Now in Self-refresh Mode Restore CAS Read and Write Latency Restore termination values to original values Exited self-refresh ... DLL TUNING ============== DLL 0xc0001050[21:16]: [0,2f,17] DLL 0xc0001050[29:24]: [1,35,1b] DLL 0xc0001054[21:16]: [0,2d,16] DLL 0xc0001054[29:24]: [4,34,1c] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.3(release):armada-17.10.3:a3306ab NOTICE: BL1: Built : 18:22:43, Jan 29 2NOTICE: BL2: v1.3(release):armada-17.10.3:a3306ab NOTICE: BL2: Built : 18:22:44, Jan 29 2018NOTICE: BL31: v1.3(release):armada-17.10.3:a3306ab NOTICE: BL31: U-Boot 2017.03-armada-17.10.1-gaee49fc (Jan 29 2018 - 18:21:49 +0800) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] DRAM: 1 GiB U-Boot DT blob at : 000000003f7161b8 Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 41 MMC Device 0 not found no mmc device at slot 0 Card did not respond to voltage select! mmc_init: -95, time 23 ** Bad device mmc 0 ** Card did not respond to voltage select! mmc_init: -95, time 23 ** Bad device mmc 0 ** Bad Linux ARM64 Image magic! Marvell>> Upon updating with Armbian U-Boot for the 1GB version flash-image-1g-1000_800_boot_sd_and_usb.bin It seems to take just fine...... Marvell>> bubt flash-image-1g-1000_800_boot_sd_and_usb.bin spi tftp Burning U-BOOT image "flash-image-1g-1000_800_boot_sd_and_usb.bin" from "tftp" to "spi" Using neta@30000 device TFTP from server 192.168.1.113; our IP address is 192.168.1.201 Filename 'flash-image-1g-1000_800_boot_sd_and_usb.bin'. Load address: 0x5000000 Loading: ######################################################## 3.3 MiB/s done Bytes transferred = 820472 (c84f8 hex) Image checksum...OK! SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB 636152 bytes written, 184320 bytes skipped in 11.985s, speed 70095 B/s Done! But then upon reboot. Marvell>> TIM-1.0 WTMI-armada-17.10.1-4809244 ENTER init_ddrgen DDR_TOPOLOGY is 2 : DDR3, 2CS 512M + 512M WTMI_CLOCK=2 Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore CAS Read and Write Latency Restore termination values to original values Exited self-refresh ... DLL TUNING ============== DLL: fail DLL TUNING FAILED It fails. So then I have to go to SATA Recovery Which boots just fine. And then upon updating the bootloader using the Factory 1GB file espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin It AGAIN seems to take the file just fine...... Marvell>> bubt espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin spi tftp Burning U-BOOT image "espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin" from "tftp" to "spi" Using neta0 device TFTP from server 192.168.1.113; our IP address is 192.168.1.201 Filename 'espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin'. Load address: 0x2000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########################## 2.3 MiB/s done Bytes transferred = 4194304 (400000 hex) Image checksum...OK! SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB 1048576 bytes written, 3145728 bytes skipped in 22.16s, speed 199728 B/s Done! But then upon reboot it fails as well..... Marvell>> TIM-1.0 WTMI-armada-17.10.1-b90dbf0 ENTER init_ddrgen DDR_TOPOLOGY is 2 : DDR3, 2CS 512M + 512M WTMI_CLOCK=2 Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore CAS Read and Write Latency Restore termination values to original values Exited self-refresh ... DLL TUNING ============== DLL: fail DLL TUNING FAILED So then I try to flash the Armbian 512MB Version of U-Boot and boot Marvell>> bubt flash-image-512m-1000_800_boot_sd_and_usb.bin spi tftp Burning U-BOOT image "flash-image-512m-1000_800_boot_sd_and_usb.bin" from "tftp" to "spi" Using neta0 device TFTP from server 192.168.1.113; our IP address is 192.168.1.201 Filename 'flash-image-512m-1000_800_boot_sd_and_usb.bin'. Load address: 0x2000000 Loading: ######################################################## 2.2 MiB/s done Bytes transferred = 818696 (c7e08 hex) Image checksum...OK! SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB 753160 bytes written, 65536 bytes skipped in 15.292s, speed 54818 B/s Done! And it works just fine...... Marvell>> TIM-1.0 WTMI-armada-17.10.3-06f9861 WTMI: system early-init Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to original values Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! QS GATING ============= Calibration done: cycle = 0x00 tap =0x59 CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x00000059 CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x00000059 DLL TUNING ============== DLL 0xc0001050[21:16]: [0,2d,16] DLL 0xc0001050[29:24]: [0,35,1a] DLL 0xc0001054[21:16]: [0,2e,17] DLL 0xc0001054[29:24]: [2,36,1c] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.3(release):armada-17.10.7:4396548 NOTICE: BL1: Built : 08:31:45, Mar 13 2NOTICE: BL2: v1.3(release):armada-17.10.7:4396548 NOTICE: BL2: Built : 08:31:45, Mar 13 2018 NNOTICE: BL31: v1.3(release):armada-17.10.7:4396548 NOTICE: BL31: U-Boot 2017.03-armada-17.10.2-g6a6581a-armbian (Mar 13 2018 - 08:31:14 +0100) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] DRAM: 512 MiB U-Boot DT blob at : 000000001f7192d8 Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@d0000: 0 SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 *** ERROR: `serverip' not set *** ERROR: `serverip' not set Bad Linux ARM64 Image magic! Marvell>> Is someone on Amazon selling 512MB versions of EspressoBins as 1GB versions? Or am I doing it wrong? ?
  8. I’m having a lot of trouble getting started with Armbian Ubuntu 16 (SD Boot) and the board. I downloaded the default image from https://dl.armbian.com/espressobin/ and wrote it successfully to the SD card. In UBoot, I have tried using the cmd at https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd and there is no armada-3720-espressobin.dtb file at the path that is called. It also cacks out on the if statement saying there is no “load” command. If I don’t call the expressobin.dtb and bypass the if statement, using “run bootmmc” starts it loading but it hangs and throws some errors and then hangs. Note that I don’t have a physical linux box, I’m using Windows to create the boot/install SD card so editing TXT files is pretty much impossible. Any help would be greatly appreciated.
  9. I've attempted to install Ubuntu_xenial_default_4.4.112. In order to get this to work, I tried to follow the instructions on the download page as close as I could... Downloaded flash-image-2g-1000_800_boot_sd_and_usb.bin (because I have a 2GB model, which reports CPU-speed 1000 MHz and DDR 800 MHz. Formatted an USB-stick as FAT, copied flash-image-2g-1000_800_boot_sd_and_usb.bin to that stick, unmounted it. Inserted the USB-stick in the EspressoBIN, rebooted the EspressoBIN. Via the terminal I typed ... When it was done updating and returned to the "Marvell>>" prompt, I pressed the RESET button on the board. The board attempts to reboot, I get the board info, and right after the SF line, I get a warning and later a few errors... CRC-error - does that mean that the boot image was not written properly to the SPI flash ? Note: The bootcmd *has* changed; now it reads: ... As I understand it, it seems it's attempting to netboot via tftp (which is why I looked at the IP adresses). Note: I can still do a ... ... which displays the directory on /dev/sda1 (boot partition) I assume that the boot image should be "Image", but I have no clue which of the 28 .dtb files I should use. (and whether to load them from /dtb/marvell or /dtb-4.4.112-mvebu64/marvell.
  10. I've been running 5.36 successfully on my espressobin. Saw the upgrade to 5.38, so ran apt-get update and upgrade. Now the boot process shows this log snippet: [ 6.251662] md: autorun ... [ 6.254188] md: ... autorun DONE. [ 6.258090] Waiting for root device /dev/mmcblk0p1... [ 6.267577] mmc1: new high speed SDHC card at address aaaa [ 6.273478] mmcblk1: mmc1:aaaa SL16G 14.8 GiB [ 6.279091] mmcblk1: p1 [ 201.869175] random: crng init done I've let it sit for a while after this (200 seconds in), but no more log lines. Any other espressobin users successfully running 5.38?
  11. Does armbian builds for Espressobin support u-boot's driver MVEBU_EFUSE_FAKE to fake efuse access? From my understanding efuse is needed to test trusted boot. https://github.com/u-boot/u-boot/commit/a1b6b0a9c1f91756b93e6d804837dc178d79d39e I am testing secure boot(trusted boot) on my 2GB EspressoBIN, using the armada-17.10 versions of u-boot, a3700utils, and atf-marvell. Following the trusted_boot.txt document, I successfully built an untrusted and trusted flash.bin and a u-boot.bin with mvebu efuse enabled. I was able to boot the board with the untrusted boot image and ran the efuse write commands. My board had a loss of power before I burned the trusted boot image using bubt. Now that I have set ‘efuse write BOOT_DEVICE’, mentioned in the trusted_boot.txt doc, I am unable to boot from SATA or SPI to burn the trusted boot image. I am unable to boot anything. Switching the jumper pins has no effect. Is there any alternative options to burn SPINOR with my trusted boot image? Or is my hardware gone? https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.10/doc/mvebu/trusted_boot.txt#L261 Marvell>> efuse write ENCRYPTION 10 Returned EFUSE value after write: ENCRYPTION 10 Marvell>> efuse write AES256_KEY Returned EFUSE value after write: AES256_KEY Marvell>> efuse write BOOT_DEVICE SPINOR Returned EFUSE value after write: BOOT_DEVICE SPINOR (1) Marvell>> efuse write KAK_DIGEST Returned EFUSE value after write: KAK_DIGEST Marvell>> efuse write CSK_INDEX 3 Returned EFUSE value after write: CSK_INDEX 3 Marvell>> efuse write OPER_MODE 2 Returned EFUSE value after write: OPER_MODE 2 Marvell>> efuse DEV_DEPLOY 0 0 - Invalid eFuse ID efuse - efuse - read/Write SoC eFuse entries Usage: efuse Access to SoC eFuse entry values list - Display all supported eFuse entry ids dump - Dump all supported eFuse entries raw - Dump all eFuses in raw format read id - Read eFuse entry "id" write id val - Write "val" to eFuse entry "id" Marvell>> efuse write DEV_DEPLOY 0 efuse_write: Invalid value 0, expected 1 DEV_DEPLOY === ERROR WRITING EFUSE VALUE === Marvell>> efuse write DEV_DEPLOY 1 Returned EFUSE value after write: DEV_DEPLOY DEPLOYED (1) Any information would be helpful! Thank you.
  12. Hi there, I've recently ordered a miniPCIe Wifi adapter for the Espressobin, so it can act as WiFi Access Point. The device does recognise the card (using `pci` in u-boot lists the device), but the kernel doesn't. All I can see is the following in dmesg output: [ 2.969072] advk-pcie d0070000.pcie: link never came up [ 2.974496] advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00 [ 2.980995] pci_bus 0000:00: root bus resource [bus 00-ff] [ 2.986325] pci_bus 0000:00: root bus resource [mem 0xe8000000-0xe8ffffff] [ 2.993793] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0xe9000000-0xe9) [ 4.435260] advk-pcie d0070000.pcie: Posted PIO Response Status: CA, 0xe00 @ 0x0 u-boot is at its latest version from the Espressobin website. The affected Wifi card is a Compex WLE600VX which should work with the ath10k driver. What options do I have? GlobalScale (the manufacturer of the Espressobin board) recommended to buy their miniPCIe Wifi module, which needs to be shipped from overseas which I want to avoid if possible. Thanks for any hints.
  13. Hi, I have bought a couple of ESPRESSOBin and I want to start some experiments. I have encounter some oddities on schematics and gpio description. Schematics question: On my two boars there is written that the circuit version is 5.1 but on the official wiki I have found only 4.0.1 schematics. Someone known were the updated schematics can be find? I have found some different links: Official wiki page Documents name report V4.0, schematics file report v4.0.1, date 21/01/2017 Official tech spec Documents name report V5.0, schematics file report v4.0.1, date 08/03/2017 Gpio question: On gpio map there is some NC but assigned pin, I report a couple of this 9 | pwr_button | NC -> what this mean? Is not connected or is connected to power button? 11 | UART4_TDX | NC -> what this mean? Is that pin connected to the uart or not? Check on schematics don't help in fact these pins don't have name (I report the J9 connector for convenience) What do you think about?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines