blood

Members
  • Content Count

    5
  • Joined

  • Last visited

  1. For what it's worth, a Debian 9 image for this board was posted recently and is available at: http://share.loverpi.com/board/libre-computer-project/libre-computer-board-roc-rk3328-cc/image/debian/ I just threw it on an eMMC and booted up my board and it's working nicely now - though I'd prefer Armbian all the same. Since it's on my mind, I don't understand why they (Libre? Firefly? Rockchip?) chose 1.5mbps as the baud rate for the serial port. The only thing I can get to work with it is minicom and specifically minicom on Linux - on my MBP it won't let me use that speed, and even on Linux ckermit refuses to go that fast as well. It's a console... why not use a compatible speed? Also, not burning in a MAC address is lame too. I managed to get around that at least. On a positive note, I uninstalled network manager and lightdm and now it boots soup-to-nuts in under 10s.
  2. I bought one of these too after the project reported that they'd be supporting Armbian. It arrived last week. I did try to boot the rock64 armbian image on it but didn't have much success: Starting kernel ... <hit enter to activate fiq debugger> Loading, please wait... starting version 229 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block .... Begin: Running /scripts/local-block ... done. That last line then repeats a bunch of times and it reboots in a loop like that. All things considered I'm used to these sorts of boards shipping with terrible support (not throwing shade at Armbian; you guys rock - it's the vendors' fault) so I won't say I'm surprised or even disappointed. I'm not sure whether their promise of Armbian support was an assumption that this project would pick up their slack, or if they were actually going to contribute such support. Any news on how/if this is progressing?
  3. On my Clearfog Base, I noticed that the temperature reported in motd was different than that reported by /sys/devices/virtual/thermal/thermal_zone0/temp - and reading the script at /etc/update-motd.d/30-sysinfo I found towards the end a comment about readings being done on the heatsink for Marvell systems (of which this is one), and the code subtracts 30 degrees Celsius from the reading. I searched around and couldn't find any other mentions of needing to do that. I guess I'm curious how it was determined that this was necessary - and how accurate it actually should be. It seems like a questionable assumption that the sensor would report a temperature that was always a constant 30 degrees too hot - but if this is the only sensor we have I get that it's better than nothing.
  4. I think I found a workaround for this. Is there a way to make the existing Clearfog images handle both boards? Should there be distinct images for the Base and Pro versions of the Clearfog boards?
  5. I'm running into a problem using the second interface with my Clearfog Base. I don't have an SFP to test the third interface, but the first works fine, though the second does not. I've tried images with 3.x and 4.x kernels from both SolidRun and Armbian and they all have the same behavior. My first concern is whether this has worked for anyone else so that I can rule out faulty hardware. Can anyone chime in with whether they've successfully used the 2nd copper interface on a Clearfog Base? If so, did it work out of the box, or did it require any extra steps? Next, can someone more familiar with ARM SOCs and device trees comment as to whether the same device tree for the Pro should work for the Base? In case it helps, here is some output I cherry-picked from the boot sequence that seems related to the NICs: Board configuration detected: Net: | port | Interface | PHY address | |--------|-----------|--------------| | egiga0 | RGMII | 0x00 | | egiga1 | SGMII | In-Band | | egiga2 | SGMII | In-Band | egiga0 [PRIME], egiga1, egiga2 | Lane # | Speed| Type | ------------------------------| | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 | ------------------------------- PCIe, Idx 1: detected no link PCIe, Idx 2: detected no link High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.39.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED SoC: model = 0x6828, revision = 0x4 mvPncVirtBase = 0xf0400000, pncTcamSize = 1024 o 3 Giga ports supported o SKB recycle supported for SWF (Disabled) o NETA acceleration mode 4 o BM supported for CPU: 4 BM pools o PnC supported (Enabled) o RX Queue support: 8 Queues * 256 Descriptors o TX Queue support: 8 Queues * 532 Descriptors o GSO supported o GRO supported o Receive checksum offload supported o Transmit checksum offload supported o Driver ERROR statistics enabled o Driver INFO statistics enabled o Driver DEBUG statistics enabled port #0: is_sgmii=0, is_rgmii=1, phy_addr=0 o Loading network interface(s) for port #0: cpu_mask=0x3, tx_csum_limit=9800 o Port 0 is connected to Linux netdevice o eth0, ifindex = 3, GbE port = 0 giga p=0: mtu=1500, mac=00:50:43:02:02:01 (platform) port #1: is_sgmii=1, is_rgmii=0, phy_addr=-1 o Loading network interface(s) for port #1: cpu_mask=0x3, tx_csum_limit=2048 o Port 1 is connected to Linux netdevice o eth1, ifindex = 4, GbE port = 1 giga p=1: mtu=1500, mac=00:50:43:02:02:02 (platform) port #2: is_sgmii=1, is_rgmii=0, phy_addr=-1 o Loading network interface(s) for port #2: cpu_mask=0x3, tx_csum_limit=2048 o Port 2 is connected to Linux netdevice o eth2, ifindex = 5, GbE port = 2 giga p=2: mtu=1500, mac=00:50:43:02:02:03 (platform) libphy: orion_mdio_bus: probed