U-Boot, the switch and the ESPRESSObin

[jernst]

In the current ArchLinux ARM configuration, the ESPRESSOBin's on-board switch comes on immediately upon power-on, and starts acting like a switch. If I don't want that -- e.g. because my network topology needs it to be a router -- I'm screwed for 60 sec or so from power-on until the Linux networking subsystem is ready and can configure it differently. By that time, DHCP requests and responses have long leaked across LAN and WAN, creating havoc in terms of IP assignment, and for security.

Apparently that default switch behavior can be changed through u-boot. I admit I'm not entirely following, but in these two threads [1] [2], smart people claim they have managed to make it work by upgrading u-boot.

Is there a chance that Arch Linux ARM might produce an upgraded u-boot package that incorporates this?


[1] http://espressobin.net/forums/topic/boo ... -security/
[2] http://espressobin.net/forums/topic/how ... sh-u-boot/

[summers]

Posted earlier - but it barfed - let me try again.

I'm not convinced that uboot is the method of setting up a router. Router is about network configuration, and that in arch is typically handled by a task hanging of systemd. So you'll do better to look up network configuration under systemd.

Typically you'll want to bring up all interfaces with fixed ip addresses. You'll need to configure whatever routing you need, probably on two or more machines (e.g. each side of the routing needs to know what is on the far side). You'll also need to set up whatever firewalls you need.

I do this with my BBB, where I bring up a USB gadget on the USB power cable, this gives the host machine another internet port - which I bring up on a district IP range (192.168.7.x). Then routing takes need setting up on the host machine, so the BBB can reach the internet. Routing also needs setting up on the local LAN, so local machines know where to find the BBB (e.g. forward packets to the host PC, which needs to know to forward to the BBB).

Its not too bad for IPv4. Probably don't even try stateless IPv6 - I'm not convinced that stateless IPv6 and routing are compatible.

Oh yes - may be worth reading this:

https://github.com/torvalds/linux/blob/ ... sa/dsa.txt

As your ethernet ports come of the same marvel chip - and so you'll need to know how that is displayed in the kernel. Also gives questions like can the marvel chip do routing by itself (e.g. without kenrel involvement). So looks like you'll need to split up the ethernet device inside the kernel dependent on state of the packet (e.g. which port it comes from).

[jernst]

You missed the essential point about my post This is about how to keep the hardware from going into a default state for the minute or such it takes for the device to boot into a state where systemd-networked etc can actually do something.

[summers]

SO you say that the kernel, with no service running, brings up the ethernet incorrectly?

The dsa link above suggests that there is a driver for the switch in the kernel. The ESPRESSObin device tree:

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts

Suggests that the device tree describes the hardware correctly.

So guess the question is, if you disable systemd-netword, and let the machine come up, then type

$this->bbcode_second_pass_code('', 'ip a')

What do you see?

I'd expect:

eth0
eth0:0
eth0:1
eth0:2

Where eth is the general device, which comes and goes to all ports, and the number ones go via specific ports. Names in the device tree suggest they may come up as "wan" "lan0" and "lan1" (or at least thats how you talk to them via mdio).

Anyway if it comes up to this level, then you should be able to configure the devices as you wish.

If however it doesn't come up - and you need to run some 3rd party software to configure the switch (This is common on routers with minimal open-wrt on them); then gut feeling yes changing the device tree so that the ethernet devices aren't listed would be the way. And yes recent uboot, have the ability to modify the device tree before boot.

But anyway need more detail ...

[summers]

And reading some more on that TOPAZ switch, sounds like it has a Z80 processor on board, and at power up can set up its own hub. So guess that what you are talking about?

My guess is there is probably a pin that you can connect to stop such behavior. So need to find that pin, then see how the ESPRESSObin is wired, hopefully wired to a GPIO pin on the arm processor. Hopefully you can set that pin in uboot, to stop switch coming up; but even then its a race between the Z80 and the arm.

Race conditions aren't a great design idea, so maybe some though has been put into this as to how to avoid it. You'll need to read the spec though, both for the topaz switch, and for the ESPRESSObin board layout ...

[Usually there would be a data sheet describing the topaz pin out and functionality - but can't find it on the Marvell web site ...]

[WarheadsSE]

It's about the config of the TOPAZ switch, during uboot, before the kernel then re-initializes the chip.

The thread documents all the needs, but ideally you'd have a setting in uboot that would control which behavior you actually want. There is one flash'able image present (for 1G model only), but that opens the WAN port only, which you may want the opposite of? Perhaps you want to leave the WAN shut, and turn LAN as open switch.

[jernst]

I settle for "do no harm" i.e. leave the switch off entirely until it can be configured from Linux. Seems reasonable to say that a box does not do anything until it is fully booted.