15 15
lanefu

Espressobin support development efforts

Recommended Posts

5 minutes ago, danglin said:

The delay won't fix the mmc read error problem.

I should mention that there is a difference between the linux and u-boot device trees for the espressobin.  There is a voltage

regulator that switches between 1.8V and 3.3V to power SD card.  The linux tree has an entry for this regulator that the u-boot

tree lacks.  Possibly, this affects hot reboots.

 

        vcc_sd_reg1: regulator {
                compatible = "regulator-gpio";
                regulator-name = "vcc_sd1";
                regulator-min-microvolt = <1800000>;
                regulator-max-microvolt = <3300000>;
                regulator-boot-on;

                gpios = <&gpionb 4 GPIO_ACTIVE_HIGH>;
                gpios-states = <0>;
                states = <1800000 0x1
                          3300000 0x0>;
                enable-active-high;
        };

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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"

Share this post


Link to post
Share on other sites
16 minutes ago, ManoftheSea said:

From running the commands on a system that has a more complete build

this is from "lsmod", but can you grep "NFT_" /boot/config-* instead on the working board.

Then, do the same on this ExpressoBin to compare both ...

Do you have enough skills to build you own kernel using Armbian scripts ?

If Yes, you can create a patch against this file : https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu64-next.config

Then, do the build, if you get it working, you can submit a PR for your patch to be merged ...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
15 15