Alors les « patches » n'aident malheureusement pas du tout, puisqu'il y a 3 fichiers, et ça ne dit pas lequel est utilisé dans ton cas.
Les datasheets/block diagrams ne donnent aucune information technique... :(
Au mieux, en farfouillant dans HW info on a un lien vers Atlassian qui ensuite pointe vers une image, dans laquelle on trouve un /boot/cn9130-cf-base.dtb (qui peut être examinée via dtc). Est-ce cela que tu utilises ?
Quoi qu'il en soit, il semble s'agir d'un adaptateur Ethernet double, du coup je continue à ne pas comprendre pourquoi les deux ports ont des modes différents. J'ai réussi à trouver le pinout du Marvell 88E1512 qui semble être embarqué, mais pas la façon dont il est utilisé dans ton produit...
Si je regarde la DTB susmentionnée, on a ceci (je condense à nouveau) :
on garde en tête que phandle c'est grossièrement une notion de référence ;
dans mdio@12a200, les deux sections ethernet-phy@0 et ethernet-phy@1 semblent bien correspondre aux interfaces eth2 et eth1 respectivement (le genre de symétrie que j'attendais) ;
pourtant l'interface eth2 a un mode différent ;
et l'interface eth2 passe par un pinctrl plutôt que d'avoir un attribut phys directement.
C'est là que les docs précises d'architecture pourraient permettre de vérifier que tout est branché et déclaré correctement.
Cela étant, je n'y connais rien en matériel, donc une fois ces observations random effectuées, je t'invite à contacter le support pour vérifier si l'interface est effectivement censée fonctionner, et s'il y a une configuration particulière pour celle-ci.
Et pour clore ma probable dernière intervention sur ce fil vu que je suis au bout de ma besace : ça me rappelle les histoires de RTC sur le CM4, de routage configurable de certains pins/gpios, pour lesquels il était question d'utiliser du pin muxing (e.g. i2c-mux-pinctrl). Pour que cela fonctionne il fallait activer certaines options de noyau (e.g. CONFIG_I2C_MUX_PINCTRL). Il pourrait être pertinent d'activer tout ce qui ressemble à du PINCTRL, juste pour être sûr que ça n'est pas un module qui serait trivialement manquant. Ceci dit, je n'ai aucune idée de si on s'attend à avoir une interface qui apparaît et qui arrive à Link is Up si c'est une partie du problème...
Au passage, je note de fuir SolidRun, qui n'a pas fait intégrer ses DTB dans mainline. Ça me rappelle une certaine fondation couleur framboise...
[^] # Re: DTB ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Port ethernet up mais aucun flux. Évalué à 3.
Alors les « patches » n'aident malheureusement pas du tout, puisqu'il y a 3 fichiers, et ça ne dit pas lequel est utilisé dans ton cas.
Les datasheets/block diagrams ne donnent aucune information technique... :(
Au mieux, en farfouillant dans HW info on a un lien vers Atlassian qui ensuite pointe vers une image, dans laquelle on trouve un
/boot/cn9130-cf-base.dtb(qui peut être examinée viadtc). Est-ce cela que tu utilises ?Quoi qu'il en soit, il semble s'agir d'un adaptateur Ethernet double, du coup je continue à ne pas comprendre pourquoi les deux ports ont des modes différents. J'ai réussi à trouver le pinout du Marvell 88E1512 qui semble être embarqué, mais pas la façon dont il est utilisé dans ton produit...
Si je regarde la DTB susmentionnée, on a ceci (je condense à nouveau) :
Ce qui ne descend pas mon niveau de perplexité :
phandlec'est grossièrement une notion de référence ;mdio@12a200, les deux sectionsethernet-phy@0etethernet-phy@1semblent bien correspondre aux interfaceseth2eteth1respectivement (le genre de symétrie que j'attendais) ;eth2a un mode différent ;eth2passe par unpinctrlplutôt que d'avoir un attributphysdirectement.C'est là que les docs précises d'architecture pourraient permettre de vérifier que tout est branché et déclaré correctement.
Cela étant, je n'y connais rien en matériel, donc une fois ces observations random effectuées, je t'invite à contacter le support pour vérifier si l'interface est effectivement censée fonctionner, et s'il y a une configuration particulière pour celle-ci.
Et pour clore ma probable dernière intervention sur ce fil vu que je suis au bout de ma besace : ça me rappelle les histoires de RTC sur le CM4, de routage configurable de certains pins/gpios, pour lesquels il était question d'utiliser du pin muxing (e.g.
i2c-mux-pinctrl). Pour que cela fonctionne il fallait activer certaines options de noyau (e.g.CONFIG_I2C_MUX_PINCTRL). Il pourrait être pertinent d'activer tout ce qui ressemble à duPINCTRL, juste pour être sûr que ça n'est pas un module qui serait trivialement manquant. Ceci dit, je n'ai aucune idée de si on s'attend à avoir une interface qui apparaît et qui arrive àLink is Upsi c'est une partie du problème...Au passage, je note de fuir SolidRun, qui n'a pas fait intégrer ses DTB dans
mainline. Ça me rappelle une certaine fondation couleur framboise...Debian Consultant @ DEBAMAX