Bringing up new hardware, and GPIO definitions
Philip Prindeville
philipp_subx at redfish-solutions.com
Mon Aug 21 20:29:45 PDT 2023
Seems logger isn't available in preinit, so I have to echo "$@" >/dev/kmsg instead.
I made this further change:
diff --git a/target/linux/x86/base-files/etc/board.d/02_network b/target/linux/x86/base-files/etc/board.d/02_network
index e00e8c04dd..188cff7e1c 100644
--- a/target/linux/x86/base-files/etc/board.d/02_network
+++ b/target/linux/x86/base-files/etc/board.d/02_network
@@ -75,6 +75,18 @@ traverse-technologies-geos)
macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null
[ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr"
;;
+silicom-80500-0214-g02-sl01a)
+ ucidef_set_network_device_path "eth0" "pci0000:00/0000:00:17.0/0000:02:00.1"
+ ucidef_set_network_device_path "eth1" "pci0000:00/0000:00:17.0/0000:02:00.0"
+ ucidef_set_network_device_path "eth2" "pci0000:00/0000:00:16.0/0000:03:00.0"
+ ucidef_set_network_device_path "eth3" "pci0000:00/0000:00:16.0/0000:03:00.1"
+ ucidef_set_network_device_path "eth4" "pci0000:00/0000:00:0c.0/0000:04:00.0"
+ ucidef_set_network_device_path "eth5" "pci0000:00/0000:00:0e.0/0000:05:00.0"
+ ucidef_set_network_device_path "eth6" "pci0000:00/0000:00:0f.0/0000:06:00.0"
+ ucidef_set_network_device_path "eth7" "pci0000:00/0000:00:10.0/0000:07:00.0"
+
+ ucidef_set_interfaces_lan_wan "eth4 eth5 eth6 eth7" "eth0 eth1 eth2 eth3"
+ ;;
esac
board_config_flush
Digging into this, the problem seems to be here in preinit_config_board()
# Find the current highest eth*
max_eth=$(grep -o '^ *eth[0-9]*:' /proc/net/dev | tr -dc '[0-9]\n' | sort -n | tail -1)
# Find and move netdevs using eth*s we are configuring
json_get_keys keys "network_device"
for netdev in $keys; do
json_select "network_device"
json_select "$netdev"
json_get_vars path path
if [ -n "$path" -a -h "/sys/class/net/$netdev" ]; then
ip link set "$netdev" down
ip link set "$netdev" name eth$((++max_eth))
fi
json_select ..
json_select ..
done
Before this block runs, all that exists in /sys/class/net/* is "lo". None of the other devices have yet been created, because they're of type "ixgbe" or "igc"...
The difference being that they get loaded not with /etc/modules-boot.d/* but with /etc/modules.d/* ... which happens *after* the preinit script runs.
Looking at netdevices.mk it seems a little arbitrary which modules have the "required for boot" flag and which ones don't:
philipp at ubuntu22:~/lede$ grep -e KernelPackage -e AUTOLOAD:= package/kernel/linux/modules/netdevices.mk
...
define KernelPackage/e1000
AUTOLOAD:=$(call AutoLoad,35,e1000)
...
define KernelPackage/igb
AUTOLOAD:=$(call AutoLoad,35,igb,1)
...
define KernelPackage/ixgbe
AUTOLOAD:=$(call AutoLoad,35,ixgbe)
...
define KernelPackage/i40e
AUTOLOAD:=$(call AutoProbe,i40e)
...
define KernelPackage/igc
AUTOLOAD:=$(call AutoProbe,igc)
...
So, "igb" is "required for boot" (it is???) but "e1000", "ixgbe", "i40e", and "igc" aren't.
Wha.....aaat?
So name assignments can only be done for a select few devices? Why can't renumbering also be handled for devices that get loaded later?
Can boot() in /etc/init.d/boot be modified to finish the job? It's not as simple as duplicating the code, because you don't want to do it to the devices that have already been handled...
> On Aug 21, 2023, at 1:49 PM, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
>
> On a somewhat related note, I got into my /etc/board.d/02_network file and made this change:
>
> #
> # Copyright © 2017 OpenWrt.org
> #
>
> . /lib/functions/system.sh
> . /lib/functions/uci-defaults.sh
>
> board_config_update
>
> +logger -p daemon.info <http://daemon.info/> "board_name: $(board_name)"
>
> case "$(board_name)" in
>
> But best as I can tell that line isn't being hit... or rather, the whole file isn't.
>
> What would prevent that from happening? I'm not very familiar with the preinit logic.
>
> Thanks
>
>
>
>> On Aug 21, 2023, at 11:34 AM, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
>>
>> I have a new x86 prototype box I'm working with, and it doesn't have a DTSI file (obviously) or a platform driver... and given my experiences with getting APU platform drivers upstream last time, I'm hesitant to do that all over again.
>>
>> Anyway, is there an easy way to do GPIO assignments for LEDs and switches if the kernel isn't doing this for me?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list