Ich verwende einen Cryptoauthlib-kompatiblen Chip für ein Board, an dem ich arbeite. Es verfügt über eine vom Benutzer programmierbare Konfigurationszone, die die EUI-64 des Geräts enthält.
Ich möchte dies als Quelle für luid_base()
, um das EUI-64 an die angeschlossenen Netzwerkschnittstellen zu bringen.
Ich begann mit der Implementierung von luid_base()
indem ich die EUI-64 im laufenden Betrieb vom Krypto-Chip holte. Aber danach kann RIOT nicht booten.
Das Problem ist, dass luid_base()
aufgerufen wird, bevor die auto_init-Funktion der cryptoauthlib ausgeführt wurde, was zu einem fehlgeschlagenen Booten führt.
Ich konnte dieses Problem lösen, indem ich die auto_init. Die alte Reihenfolge:
Die neue Ordnung:
Hat jemand ähnliche Schwierigkeiten? Oder verwende ich RIOT falsch?
Ich denke, was du wirklich willst, ist #12641
Dies blieb leider stecken, als es darum ging, mit mehreren Netifs und mehreren EUIs richtig umzugehen…
Ich habe einen Zweig, in dem ich angefangen habe, Netifs eindeutige (aufsteigende) IDs zuzuweisen, damit diese von board_get_eui64()
- ich sollte das wahrscheinlich beenden.
Schön! Damit wäre mein Konflikt gelöst. Das einzige verbleibende Problem besteht darin, dass die netif-auto_init-Funktionen vor der cryptoauthlib-auto_init-Funktion aufgerufen werden. Wäre es eine akzeptable Lösung, die auto_init-Funktionen neu anzuordnen?
Die Bestellung muss wahrscheinlich aufgeräumt werden - es läuft bereits eine: #13542
Die Bestellung muss wahrscheinlich aufgeräumt werden - es läuft bereits eine: #13542
Dass man die Funktionsaufrufe _nicht_ neu anordnet (und da es schon ziemlich groß und nicht sehr leicht zu verfolgen ist, würde ich es vorziehen, in einer separaten PR neu zu ordnen).
Ja, aber wenn @jue89 etwas
Hilfreichster Kommentar
Ja, aber wenn @jue89 etwas