ManoftheSea

Members
  • Content Count

    9
  • Joined

  • Last visited

About ManoftheSea

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ManoftheSea

    Espressobin support development efforts

    My numbers look very similar to yours. I'm using the 1000-1000 u-boot, and it looks like I'm doing about 6% better http://ix.io/1Ars
  2. It appears boot.cmd, and the compiled (?) boot.scr are not installed/modified by packages. Therefore, you can set the current line that points to espressobin to your own dtb file, which is generated with my patch to switch the names. The existing espressobin DTB has a lot of patches in the armbian-build system. What I think I want, and maybe FlashBurn does too, is to take the final 3720-espressobin.dtb, build that for legacy users, and then patch it once more to create a 3720-espressobinv7.dtb. Then, we can modify our boot.cmd for our board variant. But I don't understand the kernel compilation and patching well enough to accomplish this on my own. Can I add a dtb that includes the existing one, and simply overwrites the &mdio node? Is there some existing mechanism in the Makefiles that would accomplish this? Lastly, assuming I do get a v7.dtb, I don't know where the file lists are for the debian package builds. So even though I think I've built an (incorrect at the moment) v7.dtb, it isn't being added to the linux-dtb-next-mvebu64 package.
  3. ManoftheSea

    Espressobin - etherchannel?

    It was my understanding that the whole Topaz switch has only the 1 Gbps connection to the SOC, and that all three ethernet ports were from that switch. The labels for wan, lan0, and lan1 are just labels, on switch ports 1, 2, and 3.
  4. ManoftheSea

    Espressobin support development efforts

    It turned out I had edited the "dev" config rather than the "next" config, also. Since then, I added #1252 which was accepted. However, it seems nothing's built since then. Is that my fault (some error in some log?) Is there somewhere I should look, to assist in fixing the problem? Is there some other reason builds aren't "daily" but are perhaps backlogged?
  5. ManoftheSea

    Is ESPRESSObin v7 Supported?

    I have an EspressoBINv7, I'm running Armbian 5.72 (Stretch) with kernel 4.19. It appears to be supported.
  6. ManoftheSea

    Espressobin support development efforts

    If I'm understanding things correctly, the names of the ethernet ports on the espressobin come from the device tree - Specifically: port@1 { reg = <1>; label = "wan"; phy-handle = <&switch0phy0>; }; port@2 { reg = <2>; label = "lan0"; phy-handle = <&switch0phy1>; }; port@3 { reg = <3>; label = "lan1"; phy-handle = <&switch0phy2>; }; But the layout on the board actually has {[wan],[lan0]} {lan1}. A correction would relabel the ports that, I assume, others are using. Armbian's 5.70 image clumps them all together in br0, so new users will not be affected, but upgrades to the DTS would change the naming of ports, potentially catastrophically for users with an Espressobin firewall or in a remote location. Which is to say, I know how to solve the problem for me, but not how to do so for everyone.
  7. ManoftheSea

    Espressobin support development efforts

    The "working board" is a debian stretch amd64 - my personal laptop, on 4.19. From comparing the configs, I have submitted pull request 1234 - However, the build system doesn't let Debian reach the kconfig menu to do it *right*. I will see if I can use the Docker instructions.
  8. ManoftheSea

    Espressobin support development efforts

    Nothing found by that name From running the commands on a system that has a more complete build, the full list appears to be: nft_masq_ipv4 16384 1 nft_masq 16384 1 nft_masq_ipv4 nft_chain_nat_ipv4 16384 2 nf_nat_ipv4 16384 2 nft_chain_nat_ipv4,nft_masq_ipv4 nf_nat 36864 1 nf_nat_ipv4 nf_conntrack 163840 4 nf_nat,nf_nat_ipv4,nft_masq,nft_masq_ipv4 nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack libcrc32c 16384 2 nf_conntrack,nf_nat Of these, my espressobin system has nf_nat_ipv4, but neither nft_{masq,chain_nat}_ipv4. The rest all load on espressobin "4.19.14-mvebu64 #5.70"
  9. ManoftheSea

    Espressobin support development efforts

    Hello, short time reader and first time poster here. Love what you're doing. Got an Espressobin v7 on ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.14-mvebu64. First thing I discovered, my "wan" port is in the 2-port block with lan0, and lan1 is off by itself. Could someone direct me to where the driver assigns the names? It doesn't seem to be a udev rule. Second, I can't get systemd-networkd to get a dhcp-assigned address on "wan". Running dhclient works. Maybe that's not an Armbian specific issue. systemd says it's version 232. Last (for now), I tried to do ipv4 masquerading with nft. My guess is that some modules are missing from the build. iptables allowed me to apply the masquerade rule alright. I'll look into how to contribute a patch to build, but it may take me some time. I suggest I'm missing "nft_chain_nat_ipv4", but again if someone can tell me how to discover what modules are failing to load when I try to add the nft rule, I'll provide the feedback. Thank you in advance for any help