Eigenes i.MX6 Board - JTAG läuft. Wie nun weiter mit U-Boot?

[Holger K. (holgerkraehe)]

Hallo zusammen

Da ich seit einigen Jahren immer wieder mal etwas mit STM32 und anderen 
uCs gemacht haben, wollte ich mal eine Stufe höher gehen. Deshalb habe 
ich mir ein eigenes Board mit i.MX6 Prozessor inkl. DDR3 RAM designt.

Nun liegt das Teil vor mir und ich habe bemerkt, dass der eingesetzt 
iMX6ULL leider keinen Seriellen (UART) Bootloader besitzt. Auch direkt 
von der SD-Karte kann dieser nicht booten ohne entsprechend 
konfigurierte eFuses.
Und USB hab ich nicht herausgeführt...

Zum Glück jedoch habe ich den JTAG herausgeführt. Segger J-Link dran, 
connect und hoffen.... Und, siehe da, der Segger erkennt den Prozessor 
tatsächlch.

Nun sind also schon mal so 15% geschafft...

Nächster Schritt wäre, ein U-Boot aufzuspielen.
Ich habe bereits ein Paar Erfahrungen mit U-Boot und dem danach ladenden 
Kernel gemacht. Jedoch bin ich noch nicht wirklich ein Experte auf 
diesem Gebiet. Daher hoffe ich, dass mir hier vielleicht jemand ein Paar 
Tipps geben kann, damit ich nicht schon von Beginn an in die falsche 
Richtung laufe bzw. das Rad neu erfinde...

Da das Board Customized ist, ist wohl eine der grösseren Baustellen das 
richtige Timing des DDR3 Rams.

Gibt es hier vielleicht eine art "Template" womit ich mal beginnen 
könnte?

Wie würden die Experten unter euch nun weiter vorgehen?

Ich möchte U-Boot über JTAG auf das Target laden, da es nach meinem 
Wissenstand die einzige, aktuell aktive verbleibende Schnittstelle zu 
meinem Board ist.

Hier habe ich etwas ähnliches gefunden:
https://community.nxp.com/thread/446425

Bin über jegliche Inputs dankbar.

[soso... (Gast)]

Holger K. schrieb:
> Da das Board Customized ist, ist wohl eine der grösseren Baustellen das
> richtige Timing des DDR3 Rams.
>
> Gibt es hier vielleicht eine art "Template" womit ich mal beginnen
> könnte?

Leider bin ich nur Hardwareentwickler, daher kann ich nur begrenzt 
helfen.

Ich gehe immer so vor (natürlich NACH dem Test der Stromversorgung..), 
dass ich erst mal dieses Tool verwende:
https://community.nxp.com/docs/DOC-105652
Also das NXP DDR3 stress test tool.

Du schickts das Bord in den external Boot über USB, verbindest dich auf 
deinen Prozessor, stellst die Parameter deines Speichers ein, und lässt 
mal die cal laufen. Die so erhaltenen Abgleichwerte kann man dann für 
Linux verwenden.
Zumindest ist das bei Solo, Dual und Quad so. Das Tool unterstützt den 
i.MX6 UL jedoch auch.

Wenn das Tool durchläuft, kannst du erst einmal erleichtert Durchatmen 
;-)

Hast du USB nicht, oder kein Strapping für USB-Boot, dann gibt es noch 
ein Tool für die UART. Das habe ich aber noch nie verwendet. Es ist auch 
nicht so komfortabel.

PS:
Die Boot-Options für den internal Boot lassen sich (vermutlich) auf der 
Leiterplatte strappen - über NAND bis hin zu SD-Karte oder EMMC müsste 
eigentlich alles möglich sein. Zumindest ist das bei den größeren i.MX6 
so.

[Holger K. (holgerkraehe)]

Vielen Dank für deine Antwort.
Das sieht ja schonmal sehr vielversprechend aus

Habe in der Zwischenzeit das Embedded Studio von Segger geladen und dort 
mal ein "hello world" geladen (nur variable hochzählen).

Ich kann tatsächlich durch den code steppen. Jedoch enthalten die 
Variablen nichts gescheites. Sie ändern sich zwar beim addieren jedoch 
kommt da nur müll raus.

Jedoch glaube ich, dass dies eher ein Problem der falschen Code 
platzierung ist.

Aktuell hat der Linker den Code an Adresse 0x60000000 gelegt.

Ich werde mal versuchen, das Stresstesttool zu starten :)

Drückt mir die Daumen :)

[Holger K. (holgerkraehe)]

soso... schrieb:
> PS:
> Die Boot-Options für den internal Boot lassen sich (vermutlich) auf der
> Leiterplatte strappen - über NAND bis hin zu SD-Karte oder EMMC müsste
> eigentlich alles möglich sein. Zumindest ist das bei den größeren i.MX6
> so.

Ja, normalerweise schon. Ich hab die aber nicht rausgeführt...


Übrigens:

Laut IMX6ULLRM.pdf auf Seite 321 steht:

The ROM supports the UART1 and UART2 ports for boot purposes. The other 
UART
ports on the chip are not supported for boot purposes.

Scheint also doch einen Bootloader über Uart zu geben. Irgendwo in der 
NXP Community hatte jemand geschrieben, dass der UL und ULL nur USB 
unterstütze...

[Holger K. (holgerkraehe)]

In dem von dir erwähnten Link gibt es auch elf files für den Download 
mit einem Debugger.

Leider unterstützt jlink keine ELF File downloads.
Hat schonmal jemand efolgreich ein elf file in ein bin file umgewandelt?

Dabei gehen ja die Zusatzinformationen wie die Startadresse verloren.

[Niklas G. (erlkoenig)]

Holger K. schrieb:
> Leider unterstützt jlink keine ELF File downloads.

Der GDB aber schon, und der JLink hat einen JLink-GDB-Server:

JLinkGDBServer -Device XXX -Interface JTAG -Speed YYY

Und dann auf einem anderen Terminal:

arm-none-eabi-gdb Prog.elf
target extended-remote :2331
mon reset
load
c

Holger K. schrieb:
> Hat schonmal jemand efolgreich ein elf file in ein bin file umgewandelt?

arm-none-eabi-objcopy -O binary input.elf output.bin

Im "loadbin"-Befehl vom JLink-Commander musst du dann die Ladeadresse 
angeben.

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Holger K. schrieb:
>> Hat schonmal jemand efolgreich ein elf file in ein bin file umgewandelt?
> arm-none-eabi-objcopy -O binary input.elf output.bin
> Im "loadbin"-Befehl vom JLink-Commander musst du dann die Ladeadresse
> angeben.

Danke für deine Antwort.

Das habe ich soeben versucht und erfolgreich aus einem 241kb Elf ein 
66kb out.bin gemacht.

Ich bin mir nur nicht sicher, an welche adresse ich dies laden soll.
Ich hab mal 0x60000000 versucht, da auch embedded studio an diese 
Adresse schreibt. Jlink meldet: RAM area configured for this target is 
too small.

Memorymap habe ich mal angehängt. Wo würdet ihr das bin hinschreiben?


- Den GDB werde ich gleich auch noch testen.

[Niklas G. (erlkoenig)]

Holger K. schrieb:
> Memorymap habe ich mal angehängt. Wo würdet ihr das bin hinschreiben?

Am besten an die Adresse, für die es gelinkt wurde?! Schau mal ins 
Linkerscript! Mit "readelf -S" kannst du dir auch die Anfangsadresse der 
ersten "PROGBITS" Section anschauen. Einfacher ist es aber mit dem GDB, 
der macht das alles automatisch.

Holger K. schrieb:
> Das habe ich soeben versucht und erfolgreich aus einem 241kb Elf ein
> 66kb out.bin gemacht.

Und weg sind die Debug-Informationen :) Das geht übrigens auch 
umgekehrt: Wenn zwischen zwei Sections in der ELF-Datei eine große Lücke 
ist (z.B. weil es Sections für SRAM und SDRAM gibt), wird diese in der 
.bin-Datei explizit angelegt und mit Nullen gefüllt. Bei 4GB Adressraum 
kann die dann entsprechend groß werden...

Holger K. schrieb:
> Memorymap habe ich mal angehängt. Wo würdet ihr das bin hinschreiben?

Da nirgendwohin, weil das nur der ROM und interne SRAM sind...

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Holger K. schrieb:
>> Memorymap habe ich mal angehängt. Wo würdet ihr das bin hinschreiben?
>
> Da nirgendwohin, weil das nur der ROM und interne SRAM sind...

Nun aber ich kann das ganze ja nicht ins externe DDRAM laden bevor 
dieses nicht intitialisiert wurde, wofür ja genau dieses programm 
gedacht ist?


J-Link GDB meldet:

Reading all registers
WARNING: Register with index 74 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 74 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 75 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 75 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 76 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 76 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 77 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 77 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 78 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 78 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 79 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 79 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)
WARNING: Register with index 80 could not be read. Reason: CPSR indicates a non-valid CPU mode.
ERROR: Reading register 80 failed: Register is temporarily not available on connected CPU (FPU disabled etc.)

Und arm-none-eabi GDB:

warning: while parsing target description: XML declaration not well-formed
warning: Could not load XML target description; ignoring
Remote 'g' packet reply is too long (expected 168 bytes, got 308 bytes):

Den Processor bzw. das Device habe ich korrekt auch MCIMX6Y0 
eingestellt.
Habe einen MCIMX6Y0DVM05AB drauf.

Jemand eine Idee, was das sein könnte?
Eventuell doch ein Hardware-Fehler?

Habe mir die neueste Toolchain von arm geladen und auch jlink firmware 
wie auch software ist die letzte aktuellste.

[Niklas G. (erlkoenig)]

Holger K. schrieb:
> Nun aber ich kann das ganze ja nicht ins externe DDRAM laden bevor
> dieses nicht intitialisiert wurde, wofür ja genau dieses programm
> gedacht ist?

Achso, ich dachte es ginge um U-Boot. Dann wohl ins OCRAM. Muss aber mit 
der Adresse im Linkerscript übereinstimmen.

Hmm, vielleicht ist arm-none-eabi-gdb falsch. Linaro hatte doch 
Toolchains für Cortex-A...

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Achso, ich dachte es ginge um U-Boot. Dann wohl ins OCRAM. Muss aber mit
> der Adresse im Linkerscript übereinstimmen.

Nein nein, bin leider noch nicht so weit...
Ich weiss nur, dass U-Boot eines der Ziele sein wird/muss.

Niklas G. schrieb:
> Hmm, vielleicht ist arm-none-eabi-gdb falsch. Linaro hatte doch
> Toolchains für Cortex-A..

Hab das Problem gefunden:
https://forum.segger.com/index.php/Thread/6140-JLinkGDBServer-issues-with-6-44d/

Scheint ein Bug zu sein in einer der letzten JLINKGDB Server...
Neueste versionen sind nicht immer die besten.

[Holger K. (holgerkraehe)]

Ok mit Jlink 642 funktioniert nun auch GDB.
Konnte das ELF downloaden und mit c starten.

Ich habe an UART1 ein USB-Seriell konverter.
Eigentlich habe ich erwartet, dass ich nun hier was sehen müsste.
Leider hat sich noch nichts getan.

Das ist die Info aus dem Readme:

By default, ddr-test-uboot-jtag-mx??.elf deploy UART1 as its debug port. 
The ELF image can auto-detect which UART port you want, then deploy that port as your debug port.
You should add initial command in script to support auto-detect feature.

Note that most Freescale scripts ungate all of the clocks in the CCM, so the UART clock should 
already be ungated.  If for some reason the clocks are not ungated, make sure to ungate the
clocks in the CCM (for example, for MX6DQ: "setmem /32 0x020c407c = 0xFFFFFFFF"). 

Here is an example for mx6dq-UART2
1. configure IOMUX pins
  setmem /32  0x020e00bc = 0x00000004    //IOMUXC_SW_MUX_CTL_PAD_EIM_D26
  setmem /32  0x020e00c0 = 0x00000004   //IOMUXC_SW_MUX_CTL_PAD_EIM_D27
  setmem /32  0x020e0928 = 0x00000001   //IOMUXC_UART2_IPP_UART_RXD_MUX_SELECT_INPUT

2. enable UART_EN in UCR1
  setmem /32  0x021e8080 = 0x00000001   //UART2_UCR1

Note, in some i.MX SoCs, the ROM enables UART1, hence it is important to disable UART1 if
that is not the desired UART instance. Although the MX6DQ ROM does not enable UART1,
the disabling of UART1 is shown here for completeness:
  setmem /32  0x02020080 = 0x00000000   //disable UART1 in UART1_UCR1

Gibt es eine möglichkeit mittels gdb zu prüfen, ob die CPU überhaupt 
etwas tut?

[Niklas G. (erlkoenig)]

Holger K. schrieb:
> Gibt es eine möglichkeit mittels gdb zu prüfen, ob die CPU überhaupt
> etwas tut?

Mit Ctrl+C das Programm unterbrechen und mit "bt" und "info regs" 
schauen wo man ist? Oder im JLink Commander ein paar Mal "Regs" eingeben 
während das Programm läuft.

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Holger K. schrieb:
>> Gibt es eine möglichkeit mittels gdb zu prüfen, ob die CPU überhaupt
>> etwas tut?
>
> Mit Ctrl+C das Programm unterbrechen und mit "bt" und "info regs"
> schauen wo man ist? Oder im JLink Commander ein paar Mal "Regs" eingeben
> während das Programm läuft.

Hab ich sogleich getestet.

Leider sagt mir der GDB Server:

WARNING: CPU could not be halted
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
...


Ist das ein Grund zur Beunruhigung?

[Niklas G. (erlkoenig)]

Holger K. schrieb:
> WARNING: CPU could not be halted

Klingt als würde JTAG noch nicht so richtig funktionieren, oder die CPU 
vielleicht in einem Standby-Zustand hängen.

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Holger K. schrieb:
>> WARNING: CPU could not be halted
>
> Klingt als würde JTAG noch nicht so richtig funktionieren, oder die CPU
> vielleicht in einem Standby-Zustand hängen.

Info Reg liest zb den PC so aus:

pc             0xdeadbeef          0xdeadbeef

Wobei die Werte vermutlich falsch sind, da JLink ja garnicht lesen 
kann...

Wenn ich die CPU bzw. das Board neustarte und mit JLINK Commander darauf 
zugreifen, dann kann dieser die CPU halten und die regs auslesen.

Wenn ich jedoch mit dem GDB das Elf geladen habe, kann der commander 
nicht mal mehr zum target verbinden:

Output:



Connecting to target via JTAG
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[1]: APB-AP (IDR: Not set)
Using preconfigured AP[1] as APB-AP
AP[1]: APB-AP found
ROMTbl[0][0]: CompAddr: 80001000 CID: B105900D, PID:04-001BB961 TMC
ROMTbl[0][1]: CompAddr: 80002000 CID: B105900D, PID:04-004BB906 CTI
ROMTbl[0][2]: CompAddr: 80003000 CID: B105900D, PID:04-004BB912 TPIU
ROMTbl[0][3]: CompAddr: 80004000 CID: B105F00D, PID:04-001BB101 TSG
ROMTbl[0][4]: CompAddr: 80020000 CID: B105100D, PID:04-000BB4A7 ROM 
Table
ROMTbl[1][0]: CompAddr: 80030000 CID: B105900D, PID:04-005BBC07 
Cortex-A7
Found Cortex-A7 r0p5
6 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.1
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP

****** Error: Cortex-A/R (connect): Failed to temporarily halting CPU 
for reading CP15 registers.
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
Cannot connect to target.

[Msd (Gast)]

Holger K. schrieb:
> iMX6ULL leider keinen Seriellen (UART) Bootloader besitzt. Auch direkt
> von der SD-Karte kann dieser nicht booten ohne entsprechend
> konfigurierte eFuses.

Das ist nicht korrekt. Du must die Boot-Modes korrekt setzen.

Holger K. schrieb:
> Ja, normalerweise schon. Ich hab die aber nicht rausgeführt...

Du hast die Boot-Mode-Pins nicht rausgeführt? Kannst dort also nichts 
behelfsmäßig anlöten?

War das absicht?

[Holger K. (holgerkraehe)]

Msd schrieb:
> Das ist nicht korrekt. Du must die Boot-Modes korrekt setzen.

Danke für deinen Input.
Habs inzwischen auch im RM gefunden...
Ein paar posts weiter oben stehts:

Holger K. schrieb:
> Übrigens:
>
> Laut IMX6ULLRM.pdf auf Seite 321 steht:
>
> The ROM supports the UART1 and UART2 ports for boot purposes. The other
> UART
> ports on the chip are not supported for boot purposes.

Msd schrieb:
> Du hast die Boot-Mode-Pins nicht rausgeführt? Kannst dort also nichts
> behelfsmäßig anlöten?
>
> War das absicht?

Doch. Die beiten Pin Boot0 und Boot1 sind rausgeführt.
Aber damit lässt sich nur wählen ob intern, extern, seriel oder 
nochwas...
Bei extern gibts dann z.B. sd karte etc.

Ob jedoch die SD Karte oder ein NAND benutzt wird hängt von weiteren 
Pins oder eben eFuses ab.

Diese eFuses kann und möchte ich (noch) nicht setzen.
Die entsprechenden GPIOs für die feinere definition habe ich nicht 
rausgeführt.

[Holger K. (holgerkraehe)]

Niklas G. schrieb:
> Holger K. schrieb:
>> Gibt es eine möglichkeit mittels gdb zu prüfen, ob die CPU überhaupt
>> etwas tut?
>
> Mit Ctrl+C das Programm unterbrechen und mit "bt" und "info regs"
> schauen wo man ist? Oder im JLink Commander ein paar Mal "Regs" eingeben
> während das Programm läuft.

Hab ich sogleich getestet.

Leider sagt mir der GDB Server:

WARNING: CPU could not be halted
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
...


Ist das ein Grund zur Beunruhigung?

Info Reg liest zb den PC so aus:

pc             0xdeadbeef          0xdeadbeef

Wobei die Werte vermutlich falsch sind, da JLink ja garnicht lesen 
kann...

Wenn ich die CPU bzw. das Board neustarte und mit JLINK Commander darauf 
zugreifen, dann kann dieser die CPU halten und die regs auslesen.

Wenn ich jedoch mit dem GDB das Elf geladen habe, kann der commander 
nicht mal mehr zum target verbinden:

Wenn ich dann jedoch den GDB server schliesse, kann der commander wieder 
mit dem target verbinden und dieses auch halten.

Output:



Connecting to target via JTAG
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[1]: APB-AP (IDR: Not set)
Using preconfigured AP[1] as APB-AP
AP[1]: APB-AP found
ROMTbl[0][0]: CompAddr: 80001000 CID: B105900D, PID:04-001BB961 TMC
ROMTbl[0][1]: CompAddr: 80002000 CID: B105900D, PID:04-004BB906 CTI
ROMTbl[0][2]: CompAddr: 80003000 CID: B105900D, PID:04-004BB912 TPIU
ROMTbl[0][3]: CompAddr: 80004000 CID: B105F00D, PID:04-001BB101 TSG
ROMTbl[0][4]: CompAddr: 80020000 CID: B105100D, PID:04-000BB4A7 ROM 
Table
ROMTbl[1][0]: CompAddr: 80030000 CID: B105900D, PID:04-005BBC07 
Cortex-A7
Found Cortex-A7 r0p5
6 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.1
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP

****** Error: Cortex-A/R (connect): Failed to temporarily halting CPU 
for reading CP15 registers.
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
ConfigTargetSettings() start
J-Link script: Setting up AP map
ConfigTargetSettings() end
TotalIRLen = 13, IRPrint = 0x0101

**************************
WARNING: At least one of the connected devices is not JTAG compliant 
(IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 3, NumBitsSet = 2)

**************************

JTAG chain detection found 3 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x00000001, IRLen: 05, Unknown device
 #2 Id: 0x088C101D, IRLen: 04, JTAG-DP
Cannot connect to target.

[Holger K. (holgerkraehe)]

Ok ich hab mal folgendes probiert.

Im Embedded Studio hab ich ein Projekt angelegt und da in den Optionen 
bei MemorySegments folgendes Definiert:

FLASH RX 0x907000 0x2000;RAM RWX 0x909000 0x2000

Damit sollte mein Programm ja in den RAM Bereich abgelegt werden.
Compiliert - Debugging gestartet und, siehe da, die Variablen zählen 
diesesmal korrekt hoch.

Auch im Continue Modus, zählen sie hoch. Daher gehe ich davon aus, dass 
der Oszillator auch funktionieren muss.

Ich gehe nun also mal davon aus, dass die CPU selbst, funktionieren 
sollte.
Auch JTAG sollte funktionieren.

Nun muss der Fehler wohl an dem von NXP bereitgestellten ELF File 
liegen?

[Holger K. (holgerkraehe)]

Ok toll, eine LED ist nun am blinken :)

volatile uint32_t *GPIO1_DIR = (volatile uint32_t *)0x209C004;
volatile uint32_t *GPIO1_DAT = (volatile uint32_t *)0x209C000;
volatile uint32_t *IOMUX_GP1_00 = (volatile uint32_t *)0x20E02E8;

#define LED_H *GPIO1_DAT = (uint32_t)0x01;
#define LED_L *GPIO1_DAT = (uint32_t)0x00;

void delay(delay_ms)
{
  uint32_t i = 578000;
  while(i--);
}

void main(void) {
  //Pad K13 als Ausgang definieren im IOMUX
  *IOMUX_GP1_00 = (uint32_t)0x08;
  //GPIO1.00 als Ausgang im GPIO Register definieren
  *GPIO1_DIR = (uint32_t)0x01;
  
  while(1)
  {
    delay(500);
    LED_H;
    delay(500);
    LED_L;
  }
}

Es muss also wirklich am ELF file liegen.

[Holger K. (Gast)]

Ich glaube ich weiss nun, warum das programm nicht startet.

Hier gibts informationen:

https://community.nxp.com/thread/490967

Weiss jemand, wie man ein RealView.inc file in ein jlink script 
umwandelt?

Konkret geht es darum:

//=============================================================================      
//init script for i.MX6ULL DDR3      
//=============================================================================      
      
wait = on      
//=============================================================================      
// Disable  WDOG    
//=============================================================================      
//setmem /16  0x020bc000 =  0x30  
      
//=============================================================================      
// Enable all clocks (they are disabled by ROM code)      
//=============================================================================      
setmem /32  0x020c4068 =  0xffffffff  
setmem /32  0x020c406c =  0xffffffff  
setmem /32  0x020c4070 =  0xffffffff  
setmem /32  0x020c4074 =  0xffffffff  
setmem /32  0x020c4078 =  0xffffffff  
setmem /32  0x020c407c =  0xffffffff  
setmem /32  0x020c4080 =  0xffffffff  
      
      
//=============================================================================      
// IOMUX      
//=============================================================================      
//DDR IO TYPE:      
setmem /32  0x020e04b4 =  0x000C0000  // IOMUXC_SW_PAD_CTL_GRP_DDR_TYPE 
setmem /32  0x020e04ac =  0x00000000  // IOMUXC_SW_PAD_CTL_GRP_DDRPKE 
      
//CLOCK:      
setmem /32  0x020e027c =  0x00000008  // IOMUXC_SW_PAD_CTL_PAD_DRAM_SDCLK_0
      
//ADDRESS:      
setmem /32  0x020e0250 =  0x00000008  // IOMUXC_SW_PAD_CTL_PAD_DRAM_CAS
setmem /32  0x020e024c =  0x00000008  // IOMUXC_SW_PAD_CTL_PAD_DRAM_RAS
setmem /32  0x020e0490 =  0x00000008  // IOMUXC_SW_PAD_CTL_GRP_ADDDS 
....

Obiges script soll automatisch abgearbeitet werden mit einem jlink 
script oder ähnlichem.

[Holger K. (Gast)]

Ok hab gesehen, dass jlink mittels dem w4 befehl register bzw. speicher 
beschreiben kann.

Meine Konfig sieht nun so aus:

w4 0x020c4078  0xffffffff
w4 0x020c407c  0xffffffff
w4 0x020c4080  0xffffffff
w4 0x020e04b4  0x000C0000
w4 0x020e04ac  0x00000000
w4 0x020e027c  0x00000008
w4 0x020e0250  0x00000008
w4 0x020e024c  0x00000008
w4 0x020e0490  0x00000008
...

Nun muss ich nur noch hinkriegen, dass jlink mein textfile, zeile um 
zeile abarbeitet.

[soso... (Gast)]

Holger K. schrieb:
> Doch. Die beiten Pin Boot0 und Boot1 sind rausgeführt.
> Aber damit lässt sich nur wählen ob intern, extern, seriel oder
> nochwas...
> Bei extern gibts dann z.B. sd karte etc.

In dem Fall kannst du immerhin über den USB-OTG booten, und damit hat 
das DDR3-Stress-Test-Tool Zugriff.
Wenn die DDR3-Kalibrierung erfolgreich durchgelaufen ist, weißt du, dass 
die Hardware schon mal gut ist. Mit dieser Information sucht es sich 
entspannter in der Software ;-)

Mit den Fuses wäre ich wirklich vorsichtig. Bei uns wurde immer 
mindestens eine CPU zerballert, bevor das richtig war. Hier zum Glück 
nur die MAC-Adresse. Bei uns sind die Bootmodi immer auf den Boards 
gestrappt.

[Holger K. (holgerkraehe)]

Danke für deine Antwort.

Leider läuft die Kalibrierung noch nicht wirklich.


0004DDR Freq: 396 MHz

ddr_mr1=0x00000004
Start write leveling calibration...
running Write level HW calibration
  MPWLHWERR register read out for factory diagnostics:
  MPWLHWERR PHY0 = 0x00000000


HW WL cal status: no suitable delay value found for byte 0

HW WL cal status: no suitable delay value found for byte 1
Write leveling calibration completed but failed, the following results 
were found:
    MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x001F001F
Write DQS delay result:
   Write DQS0 delay: 31/256 CK
   Write DQS1 delay: 31/256 CK


Error: failed during write leveling calibration


Im Excel tool zur generierung der Konfiguration gibt es ein paar Felder:

DRAM DSE Setting - DQ/DQM (ohm)  240
DRAM DSE Setting - ADDR/CMD/CTL (ohm)  240
DRAM DSE Setting - CK (ohm)  240
DRAM DSE Setting - DQS (ohm)  240
System ODT Setting (ohm)  120

Eine Idee, woran dies liegen könnte?

[Holger K. (holgerkraehe)]

Ok es gibt Neuigkeiten...

Kalibration erfolgreich beendet :)

Byte 0: (0x08 - 0x4c), middle value:0x2a
Byte 1: (0x08 - 0x58), middle value:0x30

MMDC0 MPWRDLCTL = 0x4040302A


   MMDC registers updated from calibration

   Write leveling calibration
   MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x000C0025
   MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x000D000D

   Read DQS Gating calibration
   MPDGCTRL0 PHY0 (0x021b083c) = 0x01580154
   MPDGCTRL1 PHY0 (0x021b0840) = 0x00000000

   Read calibration
   MPRDDLCTL PHY0 (0x021b0848) = 0x40403436

   Write calibration
   MPWRDLCTL PHY0 (0x021b0850) = 0x4040302A


Success: DDR calibration completed!!!

Ich vermute mal, dass kann man schon mal als Erfolg verzeichnen :)

Obschon ich die vie DQS Leitungen mit feinen Drähtchen kreuzen musste.

[soso... (Gast)]

Holger K. schrieb:
> Ich vermute mal, dass kann man schon mal als Erfolg verzeichnen :)

Glückwunsch. Das ist ein wichtiger Schritt.

Denn jetzt weist du, dass folgendes läuft:
- CPU-Kern
- Takt
- Stromversorgung
- RAM
- USB-OTG
Also alle kritischen Dinge.

Im Übrigen würde ich zunächst versuchen, ohne JTAG da reinzukommen.
Bei uns läuft das, soweit mir bekannt, über eine SD-Karte (in F&E). Dazu 
braucht man aber die Strap-Options. Ich hab da einen Jumper dafür (mit 
etwas Logik dahinter).
Jedenfalls ist kein JTAG nötig, dieser wurde bei inzwischen 3 Platinen 
noch nie benutzt.
Möglicherweise wirst du mit USB-OTG am Besten fahren, das läuft bei dir 
ja schon.

Noch ein Tipp (falls du es nicht schon kennst), wäre dieses Tool:
https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX
Das wirft schon fertige Header und C-Files für den Devicetree aus. Das 
hilft sehr bei den ganzen Pinmuxing Geschichten.

Die kleinen Fehler sind keine große Schande bei solchen Dingen. Dann 
kannst du ja bei Version 2 gleich die Boot-Mode-Strap-Options 
herausziehen.

[Holger K. (Gast)]

Vielen Dank für deine Antwort.

USB habe ich ebdnfalls nicht herausgeführt. Habe den stresstest mittels 
jtag geladen. Die Ausgabe erfolgte über UART1.

Habe nebst der Kalibration auch noch den test selbst ca 50 mal laufen 
lassen. Funktionierte ohne probleme.

Wobei ich 400MHz DDR3 Frequenz gewählt habe und 700MHz CPU. Erhöhe ich 
die RAM Frequenz auf zb 587MHz, schlägt die calibration an einem punkt 
fehl.

Hauptsache das ganze läuft mal mit einer frequenz stabil.

Nun muss ich herausfinden, wie ich u-boot compilieren kann und dazu 
bringen, den kernel von der sd-karte zu laden. Bzw wie ich das board 
grundsätzlich dazu bringe, von einer sd zu booten.

[soso... (Gast)]

Holger K. schrieb:
> Wobei ich 400MHz DDR3 Frequenz gewählt habe und 700MHz CPU. Erhöhe ich
> die RAM Frequenz auf zb 587MHz, schlägt die calibration an einem punkt
> fehl.

Das liegt vermutlich daran, dass der i.MX6UL nur 400MHz DDR3 kann.

Bei einem Redesign würde ich auf alle Fälle den USB-OTG herausziehen. 
Das ist sehr nützlich.
Üblich ist ein Jumper, mit dem man zwischen internal und external boot 
umstellen kann.
Für die Schnellinbetriebnahme hängt einen PC an die USB, und wenn der 
Prozessor funktioniert bekommt man ein USB-Device.

Über USB kann man problemlos booten.

Bin aber leider kein Experte für diesen Linux-Kram.

[Holger K. (Gast)]

Hallo zusammen

Mal ein kurzes Updated.

Habe inzwischen U-Boot für das Board portiert bzw. die entsprechenden 
Konfigs hinzugefügt.

Nun habe ich jedoch festgestellt, dass u-boot im kompilierten Zustand 
gut 150kByte gross ist. Wenn das ganze auf eine SD-Karte kommt ist das 
natürlich kein Problem.

Da ich ja aber ungünstigerweise vergessen habe, meine GPIOs für das 
eFuse strapping herauszuführen, kann ich nicht direkt von der SD-Karte 
booten.

Daher wollte ich U-Boot direkt über JTAG in den internen RAM laden und 
starten. Leider ist der interne RAM jedoch nur 68kByte gross.

Ich habe nun also ein Problem....

Was wäre euer Vorschlag?
Kann man die eFuses wirklich nur ein einziges mal ändern?

Grundsätzlich muss das Board nur von der SD-Karte booten können.

Bin für alle Ideen offen.
Danke

[Gerd E. (robberknight)]

Ich kenne jetzt die i.MX6 bisher überhaupt nicht, vielleicht ist die 
Idee ja daher komplett unpassend.

Aber bei den TI AM335x die ich schon verwendet habe ist es grundsätzlich 
ähnlich. Da muss man über Pinstraps festlegen welche Reihenfolge von 
Bootmedien er prüfen soll. Bei NAND-Flash gibt es dann noch jede Menge 
lustige Einschränkungen bezügl. der unterstützten Organisation, der 
unterstützten Partitionierung und Wear-Leveling etc.

Ich habe NAND-Flash verwendet, wollte mir aber nicht den Ärger mit den 
Einschränkungen geben. Ich habe daher einfach ein kleines SPI-NOR-Flash 
mit aufs Board gepackt auf dem mein U-Boot liegt. Der Flashbaustein 
kostet vielleicht 20 Cent extra, spielt also quasi keine Rolle. Wenn das 
U-Boot davon mal geladen ist hab ich keine Einschränkungen mehr was 
NAND, UBI-Support usw. angeht.

Kannst Du das nicht ähnlich machen? Ein SPI-NOR-Flash braucht nur wenige 
Leitungen, die müsste man zur Not auch noch mit Fädeldraht ranbekommen 
wenn es nicht gerade um offen gelassene BGA-Balls geht.

[Holger K. (Gast)]

Gerd E. schrieb:
> Kannst Du das nicht ähnlich machen? Ein SPI-NOR-Flash braucht nur wenige
> Leitungen, die müsste man zur Not auch noch mit Fädeldraht ranbekommen
> wenn es nicht gerade um offen gelassene BGA-Balls geht.

Danke für deine Antwort.

Doch, es geht um offen gelassene BGA-Balls :)

[Dergute W. (derguteweka)]

Moin,

Holger K. schrieb:
> Da ich ja aber ungünstigerweise vergessen habe, meine GPIOs für das
> eFuse strapping herauszuführen, kann ich nicht direkt von der SD-Karte
> booten.

Da haste dir ja ein paar ueble Eier gelegt...Meinlieberherrgesangverein.

> Daher wollte ich U-Boot direkt über JTAG in den internen RAM laden und
> starten. Leider ist der interne RAM jedoch nur 68kByte gross.

Wird wahrscheinlich softwaretechnisch ein Riesenaufriss, aber iirc gibts 
bei TI - es koennten die Sitatras oder sowas sein - einen weiteren 
Bootloader, der dem uboot vorgeschaltet wird und auch irgendwie in den 
uboot-sourcen rumoxidiert. Ich glaub', das Ding hiess MLO. Der ist auch 
viel kleiner als das echte uboot, initialiert hauptsaechlich das DRAM, 
laedt dann das "grosse" uboot nach und laeuft eben auch auf einem 
kleinen on-chip-ram.

Gruss
WK

[Gerd E. (robberknight)]

Dergute W. schrieb:
> Wird wahrscheinlich softwaretechnisch ein Riesenaufriss, aber iirc gibts
> bei TI - es koennten die Sitatras oder sowas sein - einen weiteren
> Bootloader, der dem uboot vorgeschaltet wird und auch irgendwie in den
> uboot-sourcen rumoxidiert. Ich glaub', das Ding hiess MLO.

Ja, bei den Sitaras läuft das mehrstufig. MLO ist der Dateiname der 
dafür normal verwendet wird, der Name dieser Stufe ist aber SPL 
(Secondary Program Loader). Damit findet man das auch in den 
u-boot-Sourcen und -Dokus.

Dieser Weg könnte evtl. auch beim i.MX6 funktionieren.

[Holger K. (Gast)]

Danke für eure Antworten.

Ja, ist wirklich nicht optimal, dass diese GPIOs ungenutzt bzw 
ungeroutet blieben.

Ich habe mir SPL angeschaut. Scheint genau das richtige zu sein.

Wenn ich das richtig verstanden habe, muss ich in de u-boot konfig nur 
CONFIG_SPL mit angeben?

Kennt sich da jemand aus?

[Dergute W. (derguteweka)]

Moin,

Holger K. schrieb:
> Wenn ich das richtig verstanden habe, muss ich in de u-boot konfig nur
> CONFIG_SPL mit angeben?

Waer' natuerlich toll, wenn's das alleine schon gewesen waere. Wuerde 
mich aber arg wundern, wenn dann alle Gimmicks und Speicherbereiche 
gleich automatisch passen wuerden...

Gruss
WK

[Holger K. (Gast)]

Hab mal ein wenig gegooglet

https://github.com/ARM-software/u-boot/blob/master/doc/README.SPL

In diesem Readme steht eigentlich, dass der Build mit CONFIG_BUILD_SPL 
geschehen soll. Hab dies mal in mein defconfig file hineingeschrieben. 
Leider erhalte ich kein zusätzliches binary...

Ich erhalte aber auch keine Fehlermeldung während dem builden.

[Holger K. (Gast)]

Holger K. schrieb:
> Hab mal ein wenig gegooglet
>
> https://github.com/ARM-software/u-boot/blob/master/doc/README.SPL
>
> In diesem Readme steht eigentlich, dass der Build mit CONFIG_SPL_BUILD
> geschehen soll. Hab dies mal in mein defconfig file hineingeschrieben.
> Leider erhalte ich kein zusätzliches binary...
>
> Ich erhalte aber auch keine Fehlermeldung während dem builden.

[Holger K. (Gast)]

vielleicht ist es am ende einfacher, einen SPL selbst zu schreiben.

Mehr als etwas Soft-SPI plus ElmChans petite Fat-FS plus die DDR3 
initialisierungswerte braucht es ja nicht oder?

Wenn ich das richtig verstanden habe, dann kann ich, nach dem 
initialisieren des DDR3 Controllers, direkt über den Speicherbereich auf 
den DDR3 speicher zugreifen?

Somit müsste der SPL ja wirklich relativ einfach zu implementieren sein.

Ich würde dann folgendes tun:

Beim Kompilieren von U-Boot dessen Startadresse (ist das 
CONFIG_SYS_TEXT_BASE?) korrekt auf die spätere Adresse im RAM 
definieren.

- SD-Karte initialisieren und mittels Elm-Chan das u-boot.bin einlesen 
und byte für byte in das DDR3 schreiben.

- Nun den ProgrammCounter auf die Adresse stellen und fertig.

Muss ich eventuell zuvor noch irgendwelche andere Register zurücksetzen, 
damit das U-Boot statet, oder genügt der ProgramCounter?

[ui (Gast)]

Ich trau mich fast wetten das es von NXP auch eine Art ATF gibt
BL2
   -> BL31 (Arm trusted firmware)
   -> BL32 (optional) OPtee
   -> U-Boot
BL2 ist i.d.R. klein genug um im SRAM ausgeführt zu werden, der lädt 
dann U-Boot von der SD-Karte nach.
(Hab aber keine Erfahrung mit iMX6, nur etwas potentere HW).

Man kann aber von atf immer gut "abspicken".

[Holger K. (holgerkraehe)]

ATF klingt interessant. Habe auf die schnelle googlen jedoch noch nicht 
so viel dazu gefunden. Werde jedoch weiter dran bleiben.

Aber bitte weiterhin Hinweise und Ideen liefern :)

Habe soeben bemerkt, dass das Thema nun wieder zum Threadtitel passt :)

[Systemd (Gast)]

Holger K. schrieb:
> Deshalb habe ich mir ein eigenes Board mit i.MX6 Prozessor inkl. DDR3
> RAM designt.

Poste mal bitte die Dateien hier. Würde mich interessieren.

[Μαtthias W. (matthias)]

Hi

Zur Inbetriebnahme reicht es doch auch den DRAM mit einem JLink Script 
zu initialisieren. U-Boot dann ins RAM und sich selbst ins NAND flashen 
lassen. Was ist denn eigentlich dein geplanter Bootspeicher? 
Grundsätzlich unterstützen die iMX6 doch eine Art Script im Image das 
zuerst abgearbeitet wird bevor der Payload and dem Image ins DRAM 
kopiert wird. Und dieses Script kann das DRAM initialisieren. Im U-Boot 
konfiguriert man das WIMRE in einer imxconfig.cfg oder so ähnlich.

Matthias

[Μαtthias W. (matthias)]

Nachtrag

Sowas meinte ich
https://github.com/u-boot/u-boot/blob/master/board/freescale/mx6ullevk/imximage.cfg

Matthias

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Zur Inbetriebnahme reicht es doch auch den DRAM mit einem JLink Script
> zu initialisieren. U-Boot dann ins RAM und sich selbst ins NAND flashen
> lassen.

Interessant. Stimmt. Daran habe ich noch garnicht gedacht :)
NAND ist nicht vorhanden. Aber SD-Karte.


Μαtthias W. schrieb:
> Was ist denn eigentlich dein geplanter Bootspeicher?

Geplanter Bootspeicher ist eine SD-Karte

Μαtthias W. schrieb:
> Sowas meinte ich
> 
https://github.com/u-boot/u-boot/blob/master/board/freescale/mx6ullevk/imximage.cfg
>
> Matthias

Danke für den Hinweis. Habe vom ullevk abgeschaut gehabt und habe daher 
auch eine solche cfg datei für mein Board erstellt.

Darin ist ja auch die initialisierung des DRAM-Controllers enthalten.
Ich habe ja eine eigene, mit eigenen kalib.-werten aus der 
DRAM-Kalibration erstellt. Genügt es, diese Werte zu schreiben, um 
direkt über den Adressbereich, auf das RAM zugreifen zu können?

Systemd schrieb:
> Poste mal bitte die Dateien hier. Würde mich interessieren.

Mache ich, sobald ich weiss, dass es auch was vernünftiges tut :)

Leiterplatten wären noch welche vorhanden. Man müsste einfach zwei drei 
drähtchen löten.

[Holger K. (holgerkraehe)]

So, hab mal versucht, u-boot ins DRAM zu kopieren.

Was ich vielleicht noch ganz allgemein erwähnen sollte ist, dass es mit 
dem aktuellen Board nur darum geht, zu prüfen, ob ein lauffähiges Linux 
hinzubekommen ist. Ob ich bei diesem board dann z.B. jedesmal U-Boot 
mittels JTAG laden muss ist momentan nebensächlich.
Es wird ohnehin eine zweite Version geben.

Also, habe über JTAG die register initialisiert.
Nun habe ich mittels

J-Link>loadfile C:\development\imx6\u-boot.bin 0x80000000

versucht den bootloader ins DRAM zu laden.
Leider kriege ich von jlink

Unspecified error -1

Ganz toll. Wonach soll man denn nun suchen :)

Hab mal noch ein kleineres binary in den internen speicherbereich (RAM) 
geschrieben. Dies war erfolgreich. U-Boot in den internen RAM, welcher 
zu klein ist ergibt ebenfalls unspecified error -1.

Scheint also so zu sein, dass ich mit JLink nicht direkt auf das DRAM 
zugreifen kann.

[Μαtthias W. (matthias)]

Hi

U-Boot kann direkt auf den DRAM zugreifen wenn er läuft. Genau wie dein 
JLink. Du kannst Mal versuchen nach dem DRAM init per JLink auf den DRAM 
Bereich zu schreiben und wieder daraus zu lesen. Das sollte eigentlich 
funktionieren. Wenn nicht erhälst du nicht die Daten zurück die du da 
rein geschrieben hast. Mir hat zum Verständnis damals geholfen das 
Script aus der cfg Datei zu "dekodieren" und auf die Initsequenzen aus 
dem reference Manual von imx und dram zu mappen. Dann versteht man auch 
was da passiert und kann auch ermitteln wann da was schief geht. Ein 
JLink ist da viel Wert da man schön ins System schauen kann und diverse 
Statusregister lesen kann.

Matthias

[Holger K. (holgerkraehe)]

Oke, ich sehe gerade ein Problem.

Habe die Konfig für DRAM manuell mittels JTAG geladen, dann nochmals den 
DDR3 Stresstest gestartet und anstatt die Kalibrierung zu starten, 
direkt den Stresstest ausgeführt.

Dann gabs sogleich Adresserrors bei einzelnen Bits.
Sollte meiner Meinung nach ja nach der Initialisierung mit den Werten 
aus dem Excel und den Kalibrationswerten dann passen.

Wenn ich den RAM Test direkt im Anschluss an die Kalibration laufen 
lasse, dann ist alles gut.

Es muss also irgendwo noch ein Register geben, welches ich noch nicht 
richtig gesetzt habe...

Vielleicht kann ich deshalb auch nicht mit dem Jlink korrekt ins DDR3 
schreiben.

[Μαtthias W. (matthias)]

Hi

Kommst du nach dem stresstest noch per jtag an den imx? Dann kannst du 
die Register vom DRAM Controller dumpen und mit deinen Einstellungen 
vergleichen.

[Holger K. (holgerkraehe)]

Ja, es lag an der Initsequenz.

Hab die Kalibration erneut laufen lassen und die neuen Werte 
abgespeichert.
Nun kann ich mit dem J-Link ins DDR3 schreiben und lesen.

Was bisher jedoch noch nie geklapt hat war,
mit dem jlink und setPC und anschliessendem g, code von einer bestimmten 
Stelle zu starten.

Bisher musste ich immer den GDB hernehmen.

Hatte dies auch schonmal jemand festgestellt?

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Hi
>
> Kommst du nach dem stresstest noch per jtag an den imx? Dann kannst du
> die Register vom DRAM Controller dumpen und mit deinen Einstellungen
> vergleichen.

Danke für den Tipp, ja, das wäre auch gegangen :)
Warst ein bisschen schneller. Siehe meine Antwort.


Eben, mein Problem, ich habe den Stresstest auch als binary vorliegen, 
direkt aus dem zip von nxp. Wenn ich dieses in den internen RAM lade und 
setPC = 0x907000 und dann g mache, kommt nichts auf dem UART.

Wenn ich das elf file mit GDB lade, dann muss ich jump *0x907000 machen, 
dann steht erstmal continue... Dann CTRL+C, dann steht halted, und 
irgendeine komische adresse, im bereich 0x00000-F0000, zumindest weit 
weg von meiner sprungadresse. Wenn ich nun nochmals jumpe, dann springt 
GDB oder jlink auch tatsächlich an diese adresse und auf dem UART kommt 
der Stresstest.

Mit dem JLINK Commander alleine, hab ich es bisher nie hingekriegt, das 
stresstest binary zu starten.

Hat jemand eine Idee, woran das liegen könnte?
Wäre nämlich noch wichtig, dass dies klappt, bevor ich versuche 
irgendwelche selbstkompilierten binaries zu starten :)

Danke

[Holger K. (holgerkraehe)]

Toll... Ich bin nun wieder etwas weiter :)

Ich hab mir das u-boot.elf geschnappt und die CPU mit den DDR3 Werten 
initialisiert. Nun mit GDB das elf file geladen, an die adresse 
gesprungen und, siehe da, tatsächlich eine Ausgabe auf dem UART1.

U-Boot lebt :) Und das im DDR3 Ram.

Was kann ich denn nun schönes mit dem U-Boot machen?
Kann ich auf einfache art und weise prüfen, ob es Zugang zur SD-Karte 
hat?

[Μαtthias W. (matthias)]

Wenn dein U-Boot korrekt konfiguriert ist kannst auf deine sd Karte 
zugreifen. An die Kommandos erinnere ich mich jetzt nicht aber ein help 
und evtl. noch ein printenv sind da sehr hilfreich. Ab jetzt wird's 
einfach. Device tree an dein Board anpassen und schon bootet ein Linux.

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Ab jetzt wird's einfach.

Wenn man sich denn auskennt :)
Dies ist für mich ebenfalls noch neuland.
Hab zwar schon einiges gehört aber selbst umgesetz noch nicht.

Μαtthias W. schrieb:
> Device tree an dein Board anpassen und schon bootet ein Linux.

Welcher Teil benötigt den DT bzw. das DeviceTreeBlob?
Ist es U-Boot oder der Linux-Kernel?

Ich habe mir vor einigen Jahren mal ein Linux mit "buildroot" 
zusammengestrickt. Musste damals aber keine eigenen Device-Trees 
erstellen.

[Μαtthias W. (matthias)]

Ein aktueller U-Boot arbeitet auch mit DT. Ich setze aber noch einen 
ohne ein. Also erst Linux braucht bei mir den DT. Den musst du an deine 
Hardware (Pinbelegung, verwendete Hardware) anpassen. Ist aber echt 
einfach wenn man sich Mal einlässt dts-Dateien angesehen hat. Was extrem 
hilfreich ist wenn dein U-Boot Ethernet kann. Dann brauchst du nicht 
ständig deine sd Karte flashen sondern bootest Linux direkt per tftp und 
mountest das roof fs per nfs. Super für die turnaround Zeit :-)

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Was extrem
> hilfreich ist wenn dein U-Boot Ethernet kann. Dann brauchst du nicht
> ständig deine sd Karte flashen sondern bootest Linux direkt per tftp und
> mountest das roof fs per nfs. Super für die turnaround Zeit :-)

Das versuche ich aktuell gerade.

Habe auf dem Board einen KSZ8041. Bin jedoch nicht sicher, ob dieser 
korrekt angeschlossen ist. Ich hoffe es natürlich. Aber die chancen, 
dass etwas nicht stimmt, sind natürlich grösser :)

mal sehen, welche CONFIG_ ich aktivieren muss für den Support der SD und 
der Ethernets. Und wo man die Treiber einbindet.

Μαtthias W. schrieb:
> Ein aktueller U-Boot

Ist die aktuellste, verfügbare, version.

[S. R. (svenska)]

U-Boot kann SPL, also ein minimales Binary, welches RAM initialisiert 
und dann "u-boot proper" von woanders (NAND, SD o.ä.) lädt und ausführt.

Du kannst auch den eigentlichen U-Boot soweit abspecken, dass er unter 
deine magische Größe fällt. Wenn er dann nicht mehr hinreichend fähig 
für deine Wünsche ist, kann er ja einen vollwertigen U-Boot von SD-Karte 
nachladen. Dieser braucht dann z.B. keine RAM-Initialisierung mehr 
machen.

Viele Treiber in U-Boot benutzen inzwischen den device-tree, aber du 
wirst vermutlich unterschiedliche device-trees für U-Boot und Linux 
brauchen. Ersterer braucht ja nicht alle Details wissen, nur die zum 
Booten nötigen.

Linux selbst wird einen vollständigen device-tree brauchen, den du 
sinnvollerweise als Datei neben Kernel und Initrd/initramfs legst und 
von U-Boot auch lädst.

U-Boot kann neben Netzwerkboot (via TFTP oder auch HTTP) Daten auch 
seriell (via Kermit) empfangen. Damit habe ich dbox2 geflasht, ohne 
Netzwerkkabel legen zu müssen.

[Holger K. (holgerkraehe)]

Vielen Dank für deine Antwort.

Das mit dem SPL habe ich bereits mitbekommen.
Leider habe ich noch nicht herausgefunden, wie ich einen SPL erzeugen 
kann.

CONFIG_BUILD_SPL alleine genügt nicht.

Ich konnte in der Zwischenzeit die SD-Karte für U-Boot sichtbar machen.
Mit dem Netzwerk haperts noch ein wenig, da ich nicht weiss, wo bzw. wie 
ich den Treiber für den KSZ8041 in U-Boot einbinden kann.

Gibt man sowas beim Device-Tree an?

Habe gesehen, dass es für die iMX eine Konfig namens CONFIG_BMODE gibt. 
Damit scheint sich im U-Boot den Bootmodus des ROM-Bootloaders wählen zu 
lassen.

Habe ich jedoch noch nicht ausprobiert.


Mein U-Boot kennt nun also meine SD-Karte. Diese Anbindung scheint also 
korrekt zu sein, da U-Boot bei mmcinfo plausible Werte liefert.

Nun muss ich noch herausfinden, wie ich die SD-Karte als Bootmedium 
auswähle und U-Boot davon booten lasse.

Kennt sich da jemand aus?

[S. R. (svenska)]

Holger K. schrieb:
> Ich konnte in der Zwischenzeit die SD-Karte für U-Boot sichtbar machen.
> Mit dem Netzwerk haperts noch ein wenig, da ich nicht weiss, wo bzw. wie
> ich den Treiber für den KSZ8041 in U-Boot einbinden kann.
>
> Gibt man sowas beim Device-Tree an?

Der Treiber muss im U-Boot aktiviert sein und das Gerät muss korrekt 
im Device-Tree eingetragen sein.

Holger K. schrieb:
> Nun muss ich noch herausfinden, wie ich die SD-Karte als Bootmedium
> auswähle und U-Boot davon booten lasse.

"fatload mmc 0 0x12345678 uImage" ?

Von den iMX habe ich allerdings keine Ahnung.

[Holger K. (holgerkraehe)]

S. R. schrieb:
> Holger K. schrieb:
>> Nun muss ich noch herausfinden, wie ich die SD-Karte als Bootmedium
>> auswähle und U-Boot davon booten lasse.
>
> "fatload mmc 0 0x12345678 uImage" ?
>
> Von den iMX habe ich allerdings keine Ahnung

Jap, das ist korrekt.
Leider habe ich noch kein entsprechend korrektes linux beisammen.
Somit macht dies noch nicht viel sinn...

S. R. schrieb:
> Der Treiber muss im U-Boot aktiviert sein und das Gerät muss korrekt
> im Device-Tree eingetragen sein.

Weist du per Zufall, wie man den aktiviert?
Oder kennst du eventuell eine gute Quelle für diese Informationen?

Wie könnte ich den KSZ wohl am einfachsten testen? Vermutlich schon 
innerhalb des U-Boots. hmm....

[Lothar (Gast)]

Es gibt fertige uboot für alle möglichen i.MX6 Boards:

https://www.wandboard.org/

https://github.com/wandboard-org/uboot-imx

Oder nimm statt Linux RiscOS dann braucht es kein uboot :-)

https://www.riscosopen.org/content/downloads/imx6

[No Y. (noy)]

Oder man nimmt Barebox.
Finde ich persönlich besser als UBoot

[Holger K. (holgerkraehe)]

Lothar schrieb:
> Es gibt fertige uboot für alle möglichen i.MX6 Boards:
>
> https://www.wandboard.org/
>
> https://github.com/wandboard-org/uboot-imx

Danke.

Meintest du als inspirationsquelle? Weil ich kann ja kein anderes u-boot 
direkt einsetzen, da mein Board ja nicht genau identisch ist. Alleine 
schon wegen der unterschiedlichen DDR3 Konfiguration.

Lothar schrieb:
> Oder nimm statt Linux RiscOS dann braucht es kein uboot :-)
>
> https://www.riscosopen.org/content/downloads/imx6

Das ist zwar interessant, aber aktuell nicht mein Ziel.
Dennoch danke für deinen Hinweis :)

No Y. schrieb:
> Oder man nimmt Barebox.
> Finde ich persönlich besser als UBoot

Habe ich mir sogleich angeschaut.
Werde ich mir auf jedenfall für spätere Entwicklungen merken.
Da mein Ziel Linux ist, und U-Boot für die Einbindung des Ethernets 
ohnehin einen Device-Tree möchte, werde ich aktuell diesen Weg 
weiterverfolgen, da ich den Device-Tree ja auch fürs Linux benötige.

Heutiges Ziel ist also, Ethernet ans Laufen zu bekommen und wenn 
mögliche auch noch das endgültige Linux System.

Ich suche aktuell also nach Informationen bezüglich der Einbindung des 
KSZ8041 in U-Boot.

Wenn jemand etwas dazu beitragen kann, schreibt bitte.

[Μαtthias W. (matthias)]

Mit einem SMSC PHY musste ich garnix machen im U-Boot. Der war im 
Default schon korrekt eingestellt so das ich in U-Boot gar keinen PHY 
Support einbauen musste.

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Mit einem SMSC PHY musste ich garnix machen im U-Boot. Der war im
> Default schon korrekt eingestellt so das ich in U-Boot gar keinen PHY
> Support einbauen musste.

Aber du musstest bestimmt bei deiner Boardconfig die entsprechenden Pins 
in für die entsprechende Funktion konfigurieren?

[S. R. (svenska)]

Hmm. Google sagt, dass KSZ8041 ein PHY ist. Den muss man normalerweise 
nicht separat in den device-tree eintragen, weil er kein selbständiges 
Gerät ist.

Relevant ist der MAC, also die Ethernet-Hardware. Wenn die verschiedene 
PHY-Schnittstellen und Pinmappings unterstützt, dann trägt man die dort 
als Subdevices ein (wie z.B. hier: 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842124/U-Boot+Ethernet+Driver 
- ist aber für Zynq).

Wie man das genau macht, ist treiberspezifisch. Schau also einfach in 
die Linux-Sourcen unter Documentation/devicetree/bindings/ für deine 
Ethernet-Hardware und hoffe, dass U-Boot die gleiche Struktur benutzt.

U-Boot benutzt verschiedene Variablen für die Netzwerkkonfiguration 
(macaddr, ipaddr, serverip). Laden tut man dann z.B. mit "tftp uImage 
0x12345678". Es sollte dir dann schon sagen, ob Ethernet vorhanden ist 
oder nicht (normalerweise sollte das beim Start angezeigt werden).

[Dergute W. (derguteweka)]

Moin,

Ich kenn' jetzt weder den PHY noch den imx6 im Detail, aber allgemein: 
Das MII zwischen den beiden sollte passen - also beide auf die selbe 
Geschmacksrichtung, z.b. MII, RGMII, ..., Clk etc. konfiguriert sein. 
Die richtige Adresse des PHYs beim MDI sollte uboot kennen.
Dann halt das Board per Ethernetkabel mit einem PC verbinden, dort 
Wireshark starten, die LEDs an den Netzwerkschnittstellen angucken, und 
lospingen...
Die uboote, die ich kenne, reagieren nicht auf einen Ping von aussen, 
sondern nur wenn sie selber pingen kann das was werden.

Gruss
WK

[No Y. (noy)]

Schau dir am besten die Webseiten von
Phytec i.MX6UL BSP oder ggf. Toradex oder TQ an..

Da wirst du wohl alles finden was du benötigst ..
Das Yocto Build System von Phytec für den UL ist ausgereift und mit ein 
bisschen Anpassungen fällt relativ schnell was passendes auch für dein 
Board raus...

[Holger K. (holgerkraehe)]

S. R. schrieb:
> Hmm. Google sagt, dass KSZ8041 ein PHY ist. Den muss man normalerweise
> nicht separat in den device-tree eintragen, weil er kein selbständiges
> Gerät ist.

Danke für den Hinweis.
Das hört sich schonmal vielversprechend und vorallem logisch an.

S. R. schrieb:
> Relevant ist der MAC, also die Ethernet-Hardware. Wenn die verschiedene
> PHY-Schnittstellen und Pinmappings unterstützt, dann trägt man die dort
> als Subdevices ein (wie z.B. hier:
> 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842124/U-Boot+Ethernet+Driver
> - ist aber für Zynq).

Danke für den Link.
Sieht schonmal nicht schlecht aus.
Werde mir da bestimmt was abschauen können.

S. R. schrieb:
> U-Boot benutzt verschiedene Variablen für die Netzwerkkonfiguration
> (macaddr, ipaddr, serverip). Laden tut man dann z.B. mit "tftp uImage
> 0x12345678". Es sollte dir dann schon sagen, ob Ethernet vorhanden ist
> oder nicht (normalerweise sollte das beim Start angezeigt werden).
Ja, es sagt zu beginn:

No ethernet found.

Habe nun MII und MDIO mit im U-Boot.
MII List devices zeigt mir keine Devices an.
Da frage ich mich, ob ich dafür selbst welche eintragen müsste oder ob 
es diese scannen kann.

Dergute W. schrieb:
> Ich kenn' jetzt weder den PHY noch den imx6 im Detail, aber allgemein:
> Das MII zwischen den beiden sollte passen - also beide auf die selbe
> Geschmacksrichtung, z.b. MII, RGMII, ..., Clk etc. konfiguriert sein.
> Die richtige Adresse des PHYs beim MDI sollte uboot kennen.

Das hoffe ich, dass ich es richtig konfiguriert habe.

No Y. schrieb:
> Schau dir am besten die Webseiten von
> Phytec i.MX6UL BSP oder ggf. Toradex oder TQ an..
>
> Da wirst du wohl alles finden was du benötigst ..
> Das Yocto Build System von Phytec für den UL ist ausgereift und mit ein
> bisschen Anpassungen fällt relativ schnell was passendes auch für dein
> Board raus...

Danke, werde ich mir anschauen.

[S. R. (svenska)]

Holger K. schrieb:
> Habe nun MII und MDIO mit im U-Boot.
> MII List devices zeigt mir keine Devices an.
> Da frage ich mich, ob ich dafür selbst welche
> eintragen müsste oder ob es diese scannen kann.

Der Sinn des devicetree ist, dass U-Boot weiß, welche Geräte vorhanden 
sind. Da muss nichts mehr gescannt werden (außer PCI, USB oder 
vergleichbare Bussysteme).

Du musst dein Ethernet-Device im devicetree eintragen und den passenden 
Treiber im U-Boot aktivieren. Sonst findet er kein Ethernet, logisch.

Wenn die Einträge falsch sind, schlägt das probe fehl und du solltest 
eine Fehlermeldung bekommen. Oder es gelingt trotzdem, funktioniert dann 
aber nicht.

Schau dir nicht den Eintrag vom Zynq ab, sondern schau in die 
binding-Dokumentation vom Kernel. Für deinen MAC und nichts anderes!

[Holger K. (holgerkraehe)]

S. R. schrieb:
> Schau dir nicht den Eintrag vom Zynq ab, sondern schau in die
> binding-Dokumentation vom Kernel. Für deinen MAC und nichts anderes!

Binding dokumentation ist mir bisher leider noch kein Begriff.
Du sprichst vom Kernel, ich möchte aber erstmal Ethernet für U-Boot 
haben.

Ein Auschnitt aus meinem aktuellen Device-Tree:

&fec1 {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_enet1>;
  phy-mode = "rmii";
  phy-handle = <&ethphy0>;
  status = "okay";
};

&fec2 {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_enet2>;
  phy-mode = "rmii";
  phy-handle = <&ethphy1>;
  status = "okay";

  mdio {
    #address-cells = <1>;
    #size-cells = <0>;

    ethphy0: ethernet-phy@2 {
      compatible = "micrel,ksz8081";
      reg = <2>;
    };

    ethphy1: ethernet-phy@1 {
      compatible = "micrel,ksz8081";
      reg = <1>;
    };
  };
};

&iomuxc {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_hog_1>;
  eval1a {

    pinctrl_enet1: enet1grp {
      fsl,pins = <
        MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN  0x1b0b0
        MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER  0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00  0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01  0x1b0b0
        MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN  0x1b0b0
        MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00  0x1b0b0
        MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01  0x1b0b0
        MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1  0x4001b031
      >;
    };

Hab ich so von einem ULL EVK kopiert und angepasst.
Aktuell bekomme ich noch kein 50MHz referenz clock am Ausgang.
Ich denke ich sollte mich erstmal um diesen kümmern.

[S. R. (svenska)]

Holger K. schrieb:
> Binding dokumentation ist mir bisher leider noch kein Begriff.

Die findest du im Linux-Quelltext unter 
Documentation/devicetree/bindings. Das schrieb ich bereits. :-)

> Du sprichst vom Kernel, ich möchte aber erstmal
> Ethernet für U-Boot haben.

Beide Projekte arbeiten zusammen, denn es in deren Interesse, dass die 
Devicetrees kompatibel zueinander sind. Deswegen wirst du - abgesehen 
vom Quelltext in U-Boot - in der Kerneldokumentation die wahrscheinlich 
beste Referenz finden.

Ansonsten, wie gesagt, vom i.MX6 direkt habe ich keine Ahnung.

[Holger K. (holgerkraehe)]

Vielen Dank für deinen Hinweis

Habe nun nochmals nachgeschaut.

https://www.kernel.org/doc/Documentation/devicetree/bindings/net/fsl-fec.txt

Sieht vielversprechend aus.
Jedoch habe ich das Gefühl, dass mir massiv zu viel Hintergrundwissen 
fehlt.

Mein Eintrag im DT sieht mal so aus:

ethernet@83fec000 {
  compatible = "fsl,imx6-fec";
  reg = <0x83fec000 0x4000>;
  interrupts = <87>;
  phy-mode = "mii";
  phy-reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* GPIO4_10 */
  local-mac-address = [00 04 9F 01 1B B9];
  phy-supply = <&reg_fec_supply>;
  phy-handle = <&ethphy>;
  mdio {
    ethphy: ethernet-phy@2 {
      compatible = "ethernet-phy-ieee802.3-c22";
      reg = <2>;
      max-speed = <100>;
    };
  };
};

Jedoch verstehe ich nicht ganz den Sinn der Adresse nach dem @.
Zuerst dachte ich, es handelt sich um die Adresse, ab wo die Register 
des MAC sind. Jedoch sind dies einige (siehe Bild im Anhang)

Den RST-GPIO habe ich korrekt gesetzt.
Der Chip befindet sich im RMII Modus (habe ich anhand der Pin-Zustände 
verfiziert) Zudem ist die HW-Adresse 2 (010)

Angenommen, der DT ist korrekt, dann weiss ich immer noch nicht, was ich 
in meinem *.c file und meinem *.h file alles deklarieren muss.

Aufgrund der anderen "Vorlagen" habe ich gesehen, dass es z.B diese 
Defines gibt:

#define IMX_FEC_BASE      ENET_BASE_ADDR
#define CONFIG_FEC_XCV_TYPE    RMII
#define CONFIG_FEC_MXC_PHYADDR    0

Und solche Dinge.
Doch woher weiss ich, was es überhaupt alles gibt?
Wo ist sowas dokumentiert?

in meiner *.c Datei habe ich aktuell auch die Initialisierung der Pins.

#define ENET_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |             \
  PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   |             \
  PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)

#define ETH_PHY_POWER  IMX_GPIO_NR(4, 10)

static iomux_v3_cfg_t const fec_pads[] = {
  MX6_PAD_ENET1_RX_EN__ENET1_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_ER__ENET1_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA0__ENET1_RDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA1__ENET1_RDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_EN__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA0__ENET1_TDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA1__ENET1_TDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
};

static void setup_iomux_fec(void)
{
  imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));

  /* Reset KSZ8041 PHY */
  gpio_request(ETH_PHY_POWER, "eth_pwr");
  gpio_direction_output(ETH_PHY_POWER , 1);
  udelay(15000);
}

int board_eth_init(bd_t *bis)
{
  setup_iomux_fec();

  return 0; //cpu_eth_init(bis);
}

static int setup_fec(void)
{
  struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;

  /* clear gpr1[14], gpr1[18:17] to select anatop clock */
  clrsetbits_le32(&iomuxc_regs->gpr[1], IOMUX_GPR1_FEC_MASK, 0);

  return enable_fec_anatop_clock(0, ENET_50MHZ);
}

//Bei Board Init
setup_fec();

Für mich momentan noch sehr undurchsichtig.
Ich möchte für den Moment auch nicht gleich ein 300 Seitiges Buch über 
Device-Trees lesen. Andererseits komme ich aktuell nicht mehr weiter.

Vielleicht findet sich ja jemand, welcher einige Erfahrung in diesem 
Bereich hat, und mir evtl. helfen kann.

Ansonsten ist das Projekt, so kurz vor dem Ziel, wohl doch noch 
gestorben...

[S. R. (svenska)]

Holger K. schrieb:
> Sieht vielversprechend aus.
> Jedoch habe ich das Gefühl, dass mir massiv
> zu viel Hintergrundwissen fehlt.

Scheint so. Mir fehlt allerdings das Fachwissen...

Ich habe mal eben in den Kernel-Treiber (Linux 4.20.5) geschaut.
Der Treiber ist in drivers/net/ethernet/freescale/.

Und dann habe ich in U-Boot (2019.01) geschaut.
Der Treiber ist in drivers/net/fec_mxc.c.

> Mein Eintrag im DT sieht mal so aus:
> ethernet@83fec000 {
>   compatible = "fsl,imx6-fec";

Den Wert gibt es nicht.
Du meinst sicherlich "fsl,imx6ul-fec".

>   reg = <0x83fec000 0x4000>;
>   interrupts = <87>;

Stimmen Basisadresse und Interrupt für deinen SoC?

>   phy-mode = "mii";

Wenn dein PHY im RMII-Modus ist, dann solltest du "rmii" angeben.

>   phy-reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* GPIO4_10 */
>   local-mac-address = [00 04 9F 01 1B B9];

Eigentlich musst du hier keine MAC-Adresse angeben (damit bindest du den 
Devicetree an dieses spezifische Board). Wenn der Kernel keine 
MAC-Adresse hat, erzeugt er eine zufällige; du kannst aber auch eine per 
Parameter mitgeben. Wenn U-Boot die MAC-Adresse kennt, dann kann er den 
Parameter auch weitergeben.

>   phy-supply = <&reg_fec_supply>;

Hast du eine schaltbare Spannung (einen Regulator) für den PHY?
Falls nein, brauchst du das nicht (der PHY ist dann immer aktiv).

>   phy-handle = <&ethphy>;

>   mdio {
>     ethphy: ethernet-phy@2 {
>       compatible = "ethernet-phy-ieee802.3-c22";
>       reg = <2>;
>       max-speed = <100>;
>     };
>   };

Ich bin mir nicht sicher, ob du diesen Block brauchst. U-Boot scheint 
ihn nicht zu lesen und für Linux scheint er optional.

> };
>
> Jedoch verstehe ich nicht ganz den Sinn der Adresse nach dem @.

Die Adressierung ist Bus-spezifisch, für I2C wäre das z.B. die Adresse. 
Für den MDIO-Bus sehe ich spontan nichts, aber die ID (HW-Adresse) 
scheint sinnvoll.

> Den RST-GPIO habe ich korrekt gesetzt.
> Der Chip befindet sich im RMII Modus (habe ich anhand der Pin-Zustände
> verfiziert) Zudem ist die HW-Adresse 2 (010)

Das solltest du auch so angeben.

> Angenommen, der DT ist korrekt, dann weiss ich immer noch nicht,
> was ich in meinem *.c file und meinem *.h file alles deklarieren muss.

Mal angenommen, der DT ist korrekt und U-Boot bzw. Linux haben einen 
passenden Treiber, dann brauchst du eigentlich garnichts weiter tun. :-)

Der Sinn des DT ist, ohne Codeänderungen sämtliche Treiber an die 
Hardware anpassen zu können. Die gesamte Pin-Struktur beschreibt man im 
Device-Tree in pinctrl (wobei ich nicht weiß, ob i.MX das nutzt).

Was immer du in deinem Bootloader setzt, könnte von Linux anhand der 
Devicetree-Daten oder Defaults überschrieben werden.

> in meiner *.c Datei habe ich aktuell auch die Initialisierung der Pins.
> #define ENET_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |             \
>   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   |             \
>   PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)

Was ist das für eine C-Datei? Wo befindet sich die?

> Für mich momentan noch sehr undurchsichtig.
> Ich möchte für den Moment auch nicht gleich ein 300 Seitiges Buch über
> Device-Trees lesen. Andererseits komme ich aktuell nicht mehr weiter.

Normalerweise macht man eine Standardkonfiguration und trägt alles 
relevante in den Devicetree ein - und gut ist. Plattform- und 
boardspezifische Konfigurationen will man nicht.

> Ansonsten ist das Projekt, so kurz vor dem Ziel,
> wohl doch noch gestorben...

Du gibst ja schnell auf.

[Holger K. (holgerkraehe)]

Vielen Dank für deine Antwort.

S. R. schrieb:
> Den Wert gibt es nicht.
> Du meinst sicherlich "fsl,imx6ul-fec".

Ja, da hast du recht.

S. R. schrieb:
> Stimmen Basisadresse und Interrupt für deinen SoC?

Nein. Das war ein Beispiel aus dem Readme.
Ich habe jedoch inzwischen herausgefunden, dass all diese Definitionen 
bereits von Freescale im dtsi erledigt wurden.

Auszug aus dem imx6ull.dtsi

aliases {
    can0 = &flexcan1;
    can1 = &flexcan2;
    ethernet0 = &fec1;

....
fec1: ethernet@02188000 {
        compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
        reg = <0x02188000 0x4000>;
        interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
               <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&clks IMX6UL_CLK_ENET>,
           <&clks IMX6UL_CLK_ENET_AHB>,
           <&clks IMX6UL_CLK_ENET_PTP>,
           <&clks IMX6UL_CLK_ENET_REF>,
           <&clks IMX6UL_CLK_ENET_REF>;
        clock-names = "ipg", "ahb", "ptp",
                "enet_clk_ref", "enet_out";
        stop-mode = <&gpr 0x10 3>;
        fsl,num-tx-queues=<1>;
        fsl,num-rx-queues=<1>;
        fsl,magic-packet;
        fsl,wakeup_irq = <0>;
        status = "disabled";
                        };

S. R. schrieb:
> Mal angenommen, der DT ist korrekt und U-Boot bzw. Linux haben einen
> passenden Treiber, dann brauchst du eigentlich garnichts weiter tun. :-)

Nun, es gibt aber doch noch die Compiler-flags von U-Boot wie z.B.

CONFIG_FEC_MXC=y
CONFIG_CMD_MII=y
CONFIG_PHYLIB=y
CONFIG_MII=y
CONFIG_DM_ETH=y
CONFIG_ETH=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
CONFIG_RGMII=y
CONFIG_NET_RANDOM_ETHADDR=y

Die muss ich ja durchaus angeben.

Bezüglich Device-Tree habe ich noch folgende Appnote von Freescale 
gefunden:

https://www.nxp.com/docs/en/application-note/AN5125.pdf

Da steht auf Seite 11

U-Boot itself does not use the device tree on current Freescale platforms, although it has several commands that allow you toview and manipulate the FDT itself:

Wenn dies stimmen sollte, dann muss ich den Fehler, warum Ethernet im 
U-Boot nicht geht, nicht beim oder im DT suchen.

S. R. schrieb:
> Was ist das für eine C-Datei? Wo befindet sich die?

Dies ist die Boardspezifische C-Datei.
Zu finden in den u-boot sourcen unter board/vendor/board/board.c

Beispiel:

https://github.com/u-boot/u-boot/blob/master/board/freescale/mx6slevk/mx6slevk.c

in der entsprechenden h datei werden auch einige Dinge konfiguriert.

https://github.com/u-boot/u-boot/blob/master/include/configs/mx6slevk.h

S. R. schrieb:
> Du gibst ja schnell auf.

Nein nein. Aufgeben tu ich nicht :)

[No Y. (noy)]

Benutzt du Mainline Kram oder das Freescale Vendor BSP??

[Holger K. (holgerkraehe)]

No Y. schrieb:
> Benutzt du Mainline Kram oder das Freescale Vendor BSP??

Mainline :)


Aufgrund der Tatsache, dass einiges im dtsi schon vorkonfiguriert wurde, 
habe ich den Eintrag im DT so angepasst:

&fec1 {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_enet1>;
  phy-mode = "rmii";
  phy-handle = <&ethphy0>;
  status = "okay";

  mdio {
    #address-cells = <1>;
    #size-cells = <0>;

    ethphy0: ethernet-phy@2 {
      compatible = "ethernet-phy-ieee802.3-c22";
      reg = <2>;
    };
  };
};

Basierte auf dem imx6ull_evk.

Die konfiguration für den Clock im C-File sieht nun so au:

static int setup_fec(void)
{
  struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;

  //ENET1 TX reference clock driven by ref_enetpll. This clock is also output to pins via the IOMUX.
  //ENET_REF_CLK1 function.
  clrsetbits_le32(&iomuxc_regs->gpr[1], BIT(13), 0);

  //ENET1_TX_CLK output driver is enabled when configured for ALT1
  clrsetbits_le32(&iomuxc_regs->gpr[1], BIT(17), 1);

  return enable_fec_anatop_clock(0, ENET_50MHZ);
}

Leider kriege ich noch keine 50MHz am Ausgang zu sehen.

[No Y. (noy)]

Dann musst / kannst du den Kram den Freescale da schreibt ignorieren...

Da sind teilweise riesen Unterschiede.


Wenn du dich an den Freescale Infos orientieren magst dann 
musst/solltest du auch das Freescale BSP nehmen.

[Holger K. (holgerkraehe)]

No Y. schrieb:
> Dann musst / kannst du den Kram den Freescale da schreibt ignorieren...

Danke für den Hinweis.

No Y. schrieb:
> Wenn du dich an den Freescale Infos orientieren magst dann
> musst/solltest du auch das Freescale BSP nehmen.

Eigentlich wollte ich wenn möglich auf das BSP verzichten.
Ich denke, dass wenn ich es irgendwann ohne BSP geschafft habe, dann 
wird es vermutlich mit dem BSP umso einfacher gehen.



Nachdem ich den Device-Tree wie folgt angepasst habe:

Holger K. schrieb:
> Aufgrund der Tatsache, dass einiges im dtsi schon vorkonfiguriert wurde,
> habe ich den Eintrag im DT so angepasst:
> &fec1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinctrl_enet1>;
>   phy-mode = "rmii";
>   phy-handle = <&ethphy0>;
>...

Zeigt mir U-Boot nun folgendes an:

Net:   FEC
Warning: FEC (eth0) using random MAC address - d2:da:d3:7c:69:9f

Leider aber offenbar noch keine echte kommunikation mit dem Chip.
Scheint eher so zu sein, dass U-Boot weiss, dass da was sein sollte, der 
Chip aber noch nicht korrekt angesprochen wird.

Der Clock bleibt jedenfalls noch aus.

[Holger K. (holgerkraehe)]

Gerade bestätigt....

=> dhcp
FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC

Irgendwo klemmt es noch... :)

[S. R. (svenska)]

Holger K. schrieb:
> Ich habe jedoch inzwischen herausgefunden, dass all diese Definitionen
> bereits von Freescale im dtsi erledigt wurden.

Und langsam tauchen die Vorteile vom Devicetree auf. :-D

> fec1: ethernet@02188000 {
>         compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
>         ...
>         status = "disabled";
> };

Und in deiner eigenen DTS-Datei für dein Board überschreibst du nur die 
Eigenschaften, die anders sein müssen. Zum Beispiel "status" auf "ok".

> S. R. schrieb:
>> Mal angenommen, der DT ist korrekt und U-Boot bzw. Linux haben einen
>> passenden Treiber, dann brauchst du eigentlich garnichts weiter tun. :-)
>
> Nun, es gibt aber doch noch die Compiler-flags von U-Boot wie z.B.
> CONFIG_FEC_MXC=y
> CONFIG_CMD_MII=y
> CONFIG_PHYLIB=y
> CONFIG_MII=y
> CONFIG_DM_ETH=y
> CONFIG_ETH=y
> CONFIG_PHY_MICREL=y
> CONFIG_PHY_MICREL_KSZ8XXX=y
> CONFIG_RGMII=y
> CONFIG_NET_RANDOM_ETHADDR=y
>
> Die muss ich ja durchaus angeben.

Das sind keine Compiler-Flags, sondern Settings, mit denen du die 
Treiber aktivierst. Der Device-Tree sagt nur, welche Geräte auf deinem 
Board wo liegen und wie sie verdrahtet sind - dein U-Boot bzw. Kernel 
muss die Geräte natürlich auch irgendwie unterstützen.

> U-Boot itself does not use the device tree on current Freescale
> platforms, although it has several commands that allow you toview and
> manipulate the FDT itself:

Das ist definitiv falsch/veraltet, denn ich habe passenden Code sowohl 
in U-Boot als auch Linux gefunden.

> Dies ist die Boardspezifische C-Datei.
> Zu finden in den u-boot sourcen unter board/vendor/board/board.c
>
> Beispiel:
> https://github.com/u-boot/u-boot/blob/master/board/freescale/mx6slevk/mx6slevk.c
>
> in der entsprechenden h datei werden auch einige Dinge konfiguriert.
> https://github.com/u-boot/u-boot/blob/master/include/configs/mx6slevk.h

Hmm. Soweit ich weiß, war das mal der übliche Weg, um U-Boot an die 
Hardware anzupassen. Bis auf die frühe Initialisierung (also 
RAM-Initialisierung und so) sollte das aber nicht mehr nötig sein: Der 
Devicetree ersetzt auch das, deswegen ist er bei U-Boot auch ein Teil 
des Binaries.

No Y. schrieb:
> Wenn du dich an den Freescale Infos orientieren magst dann
> musst/solltest du auch das Freescale BSP nehmen.

Jaein. Freescale wird schon an der Mainline-Entwicklung mitmachen, 
dementsprechend wird das BSP davon nicht zu stark abweichen. Allerdings 
sind BSPs selten auf dem gleichen Stand, daher sind viele Informationen 
veraltet. Dafür fehlen dem Mainline-Kernel öfter mal gewisse 
Funktionalitäten.

Holger K. schrieb:
> Eigentlich wollte ich wenn möglich auf das BSP verzichten.
> Ich denke, dass wenn ich es irgendwann ohne BSP geschafft habe,
> dann wird es vermutlich mit dem BSP umso einfacher gehen.

Ich tippe mal stark auf "eher nicht".
Ein BSP enthält eigentlich immer einen mehr oder weniger stark 
gepatchten/zusammengehackten Kernel, der entsprechend anders 
funktioniert, weil er z.B. noch platform_data statt Devicetrees nutzt.

> Zeigt mir U-Boot nun folgendes an:
> Net:   FEC
> Warning: FEC (eth0) using random MAC address - d2:da:d3:7c:69:9f

Das heißt, dass der Ethernet-Treiber aktiviert wird und die Hardware 
erkannt hat. Die MAC-Adresse ist zufällig, weil keine echte Adresse 
gefunden wurde. Das ist aber eine Baustelle für später.

> Leider aber offenbar noch keine echte kommunikation mit dem Chip.
> Scheint eher so zu sein, dass U-Boot weiss, dass da was sein sollte, der
> Chip aber noch nicht korrekt angesprochen wird.

Richtig. Da man einen PHY nicht proben kann, nimmt U-Boot die im 
Devicetree angegebenen Daten für bare Münze. Wenn die nicht stimmen, 
tut's halt nicht.

Aber so sieht Fortschritt aus. Jetzt musst du nur noch den PHY richtig 
eintragen. :-)

[Holger K. (holgerkraehe)]

Danke für deine Antwort.

Ich habe inzwischen einen weiteren Fortschritt.

Wenn ich an Adresse 0x020E4004 die Daten 0x0F420005 schreibe,
dann gibt mir der Prozessor brav die 50MHz am CLK Out aus.
Wenn ich jedoch U-Boot weiterlaufen lasse (hatte es für diese Operation 
angehalten mittels Breakpoint/J-Link) dann wird dieses Bit (Bit17) 
wieder überschrieben und es kommen keine 50MHz mehr heraus.

Fragt sich, wie ich dies im Device-Tree korrekt abbilden kann.

Habe nun einmal im u-boot mittels nm die entsprechende adresse mit 
entsprechenden Daten versorgt.

Nun blinken schonmal die LEDs an der Buchse. Aber DHCP im U-Boot sagt 
weiterhin:

=> DHCP
FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC

[Holger K. (holgerkraehe)]

Ich habe mit dem Oszilloskop mal ein Paar RX-Signale angeschaut. Da 
scheint sich auch was zu tun.

Mal ne doofe frage. Muss man RX und TX auch bei einem PHY auskreuzen?
Vielleicht hab ich das Problem soeben gefunden...

EDIT:

Scheint nicht so zu sein.
Hier noch das Schema aus meinem früheren Thread.

Beitrag "KSZ8041 an i.MX6. AddressPins?"

[S. R. (svenska)]

Zumindest der Kernel kann im Devicetree ein paar Quirks auslesen, um 
fälschlicherweise gekreuzte (oder nichtgekreuzte) Leitungen trotzdem zu 
benutzen...

Weder die Adresse noch die Daten sagen mir was. Wenn du daraus 
Registernamen machst, kannst du in den Treibern selbst schauen, unter 
welchen Umständen die gesetzt werden.

[Holger K. (holgerkraehe)]

S. R. schrieb:
> Weder die Adresse noch die Daten sagen mir was. Wenn du daraus
> Registernamen machst, kannst du in den Treibern selbst schauen, unter
> welchen Umständen die gesetzt werden.

Das Register ist folgendes:

IOMUXC_GPR_GPR1

Es schaltet die Pins entsrpechend zu alternativen Funktionen um.

Ich aktiviere damit BIT17

ENET1_TX_CLK data direction control when anatop. ENET_REF_CLK1 is selected (ALT1)
0 ENET1_TX_CLK output driver is disabled when configured for ALT1
1 ENET1_TX_CLK output driver is enabled when configured for ALT1

Ursprünglich stand im Register: 0x0F400005
Ich schreibe nun 0x0F420005 hinein.

Im U-Boot wäre eigentlich diese Zeile in meinem C-File, welches ich ja 
eigentlich nicht mehr benutzen sollte, bzw. nur begrenzt, 
verantwortlich:

enable_fec_anatop_clock(0, ENET_50MHZ);

Aber offenbar macht diese dies nicht richtig.

Ich habe nun folgendes in meinem C-File ergänzt:

volatile uint32_t *IOMUXC_GPR_GPR1 = (volatile uint32_t *)0x020E4004;
...
*IOMUXC_GPR_GPR1 = (uint32_t) 0x0F420005;
...

Nun schaltet U-Boot zumindest den Clock korrekt ein beim starten.
den PHY benutzen kann ich allerdings trozdem noch nicht.

=> DHCP
FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC

[Holger K. (holgerkraehe)]

Hab soeben noch gesehen, dass der IRQ des Phys nirgends verbunden 
wurde...

Ob die Software wohl ohne IRQ auskommt?

Ich sehe mit dem Oszi jedenfalls Daten auf TX0..2 sowie RX0..2 während 
dem der dhcp versucht daten zu bekommen.

Aber dennoch erhalte ich nur die Meldung:

=> dhcp
FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC
BOOTP broadcast 1
...
BOOTP broadcast 17

Retry time exceeded; starting again
=>

MII info bringt auch keine nennenswerten Informationen:

=> mii info
PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
...
PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX

Bei der abfrage des DHCPs blinkt die ETH-LED im Takt der Abfragen.
Scheint irgendwie schon etwas beim PHY anzukommen....

[S. R. (svenska)]

Holger K. schrieb:
> Hab soeben noch gesehen,
> dass der IRQ des Phys nirgends verbunden wurde...

In Hard- oder Software?

Den IRQ vom PHY musst du natürlich im Devicetree korrekt konfigurieren 
(wie auch pinmux/clock-Konfiguration). Ich fürchte, dass das nicht 
korrekt ist und daher der PHY nicht funktioniert.

Weiter am devicetree feilen... :-)

[Holger K. (holgerkraehe)]

S. R. schrieb:
> Holger K. schrieb:
>> Hab soeben noch gesehen,
>> dass der IRQ des Phys nirgends verbunden wurde...
>
> In Hard- oder Software?
>
> Den IRQ vom PHY musst du natürlich im Devicetree korrekt konfigurieren
> (wie auch pinmux/clock-Konfiguration). Ich fürchte, dass das nicht
> korrekt ist und daher der PHY nicht funktioniert.
>
> Weiter am devicetree feilen... :-)

Leider in Hardware.

Fragt sich, ob dieser an einen speziellen ENET IRQ angeschlossen werden 
muss (sofern es einen solchen überhaupt gibt) oder ob man grundsätzlich 
einen beliebigen Interrupt verwenden kann.

Da es sich im Device-Tree konfigurieren lassen sollte, tippe ich mal auf 
letzteres.

Jetzt muss ich mal versuchen herauszufinden, welche Pins beim i.mx 
überhaupt interrupts sein können.

EDIT

Bezüglich dem Eintragen des IRQs im Devicetree habe ich etwas weiter 
oben diesen Auszug gepostet:

ethernet@83fec000 {
  compatible = "fsl,imx6-fec";
  reg = <0x83fec000 0x4000>;
  interrupts = <87>;
  phy-mode = "mii";
  phy-reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* GPIO4_10 */
...

Hier wird der Interrupt mit einer Nummer definiert.
Nun befinden sich diese Zeilen jedoch im dtsi file.
Dieses sollte ich nicht abändern, da es global von Freescale ist.
Gibt es eine Möglichkeit, diese Einstellungen in meinem dts File zu 
überschreiben?

Danke

EDIT2:

Habe herausgefunden, dass offensichtlich GPIO1 und GPIO2 Pins als 
Interrupt konfiguriert werden können.

Ich habe glücklicherweise für Testzwecke einen Button an GPIO1_01 
angehängt. Vielleicht lässt sich da nun der IRQ verbinden...

Dafür müsste ich aber noch herausfinden, wie ich den IRQ korrekt dem PHY 
im DT zuweise.

[Holger K. (holgerkraehe)]

Kann leider nicht mehr bearbeiten.

Habe hier noch was interessantes gefunden:

https://www.kernel.org/doc/Documentation/networking/phy.txt

Lastly, once the controller is ready to handle network traffic, you call
 phy_start(phydev).  This tells the PAL that you are ready, and configures the
 PHY to connect to the network.  If you want to handle your own interrupts,
 just set phydev->irq to PHY_IGNORE_INTERRUPT before you call phy_start.
 Similarly, if you don't want to use interrupts, set phydev->irq to PHY_POLL.

 When you want to disconnect from the network (even if just briefly), you call
 phy_stop(phydev).

Sieht so aus, als müsste ich noch was aufrufen, bevor der phy 
tatsächlich funktioniert. Zudem scheint es eine Möglichkeit ohne IRQ zu 
geben.

Ich denke mal, dass ich dies in meinem C-File machen muss?

EDIT:
Im gesamten U-Boot Code gibt es leider kein "PHY_POLL".
Scheint also auf den Linux Kernel begrenz zu sein.

[Holger K. (holgerkraehe)]

So... In einem Chat wurde mir geraten:

 You need to set the 'interrupt-parent' property in the phy node to the gpio controller node phandle and then adjust the interrupts property to the gpio line number and flags.

Und zur Interrupt nummer:

 depends on the gpio controller.  Maybe it is obvious from the SoC pin name, maybe not... If the GPIO controller has a bank of 32 GPIOs, then it would typically be in the range of 0-31 for example

Mal sehen, ob mir das weiterhilft.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

So wichtig ist der IRQ des PHY jetzt eigentlich nicht.
Damit bekommste dann zB einen Linkup/down mit ohne andauernd über MDIO 
zu pollen.
Uboot erkennt ja offensichtlich schon, dass ein Link da ist.

Dass ein Paket komplett empfangen wurde erkennt der MAC selber anhand 
von RXDataValid und wirft dann einen imx6 internen IRQ.

Wenn aufn den TXD was anliegt und TX_EN high ist, dann sendet der MAC 
über den PHY.
Ist RX DataValid High, dann empfängt der PHY, dem PHY ist egal was der 
MAC dazu sagt, der empfängt einfach nur und schickt das über den RMII 
weiter.


Die Frage ist ob der PHY nicht ausversehen in einem Loopback modus ist?
Hast du das Hardwarestrapping genutzt oder wird per MDIO eine config 
reingeschrieben?

[Holger K. (holgerkraehe)]

Vielen Dank für deine Antwort.

Eigentlich ist MDIO vorhanden. Aber ich glaube die Kommunikation 
funktioniert noh nicht korrekt.

Eine Konfig schreibe ich bisher nicht hinein. Einige Vorredner haben 
gesagt, dass die Angabe im Devicetree alles regelt.

Ich glaube ich muss dennoch ein paar Dinge im *.c File ergänzen.
Was müsste ich denn wohl per MDIO schreiben?

Woran hast du erkennt, dass U-Boot einen Link erkennt?

Danke

[Μαtthias W. (matthias)]

Sieht für mich so aus als ob der PHY im reset festhängt. Evtl. musst du 
den per gpik freigeben. Das geht in Linux per DT. Beim U-Boot weiß ich 
das jetzt nicht. Am einfachsten den gpio im c file deines Boards den 
gpio entsprechend konfigurieren. Es wäre auch hilfreich wenn du den 
passenden Abschnitt deines schaltplans herzeigen würdest.

[Holger K. (holgerkraehe)]

Μαtthias W. schrieb:
> Sieht für mich so aus als ob der PHY im reset festhängt. Evtl. musst du
> den per gpik freigeben. Das geht in Linux per DT. Beim U-Boot weiß ich
> das jetzt nicht. Am einfachsten den gpio im c file deines Boards den
> gpio entsprechend konfigurieren. Es wäre auch hilfreich wenn du den
> passenden Abschnitt deines schaltplans herzeigen würdest.

Vielen Dank für deine Antwort/Hinweis.

Den Reset setze ich selbst in meiner U-Boot Boardconfig.
Also im c-file

Den Schaltplan hab ich etwas weiter oben gepostet.
Hier ist er:

Beitrag "KSZ8041 an i.MX6. AddressPins?"

Ich bin zu 97% sicher, dass der PHY nicht im Reset ist.
Habe das eigentlich schonmal geprüft.
Aber ich prüfe es sicherheitshalber nochmals nach...

EDIT:
Habs nochmals überprüft.
Reset ist definitiv high.

Bei der U-Boot initialisierung schalte ich diesen kurz high, dann low 
und wieder high... Also ein sauberer reset. Kurz heist hier mit ca. 
5-10ms Delay dazwischen.

EDIT2:

Ist MDIO eine voraussetzung für das funktionieren des PHYs?

=> mdio list
FEC:
2 - Generic PHY <--> FEC
=> mdio read 2
Reading from bus FEC
PHY at address 0:
2 - 0x0
=> mdio rx 2
2 is not a known ethernet
=> mdio read 0 00
0 is not a known ethernet
Reading from bus FEC
PHY at address 0:
0 - 0x0
=> mdio read 0 01
0 is not a known ethernet
Reading from bus FEC
PHY at address 0:
1 - 0x0
=> mdio read 0 00
0 is not a known ethernet
Reading from bus FEC
PHY at address 0:
0 - 0x0

ich glaube da gibts auch noch ein Problem.

[Μαtthias W. (matthias)]

Was liegt denn an XI am PHY an? Da müssen 25MHz sein. REFCLK geht wohin? 
Denn das ist die eigentliche Taktfrequenz des RMII Interface. Deinen 
alternativen Schaltplan kann ich so nicht nachvollziehen. Ich hab aber 
nur Detailwissen mit den SMSC PHYs. Ansonsten solltest du auf jeden Fall 
das MII ans Laufen bekommen. Wenn ich den Schaltplan richtig lese hast 
du den PHY auf Adresse 2 konfiguriert. Das musst du den U-Boot Kommandos 
mitgeben. Es gibt zwei Register aus denen du eine id auslesen kannst. 
Das muss funktionieren. Dann kannst du Diagnoseinfos aus dem PHY lesen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Holger K. schrieb:
> Woran hast du erkennt, dass U-Boot einen Link erkennt?

Hatteste das nicht geschrieben?

Wenn uboot DHCP discovers schickt, dann müsst man die auch mit Wireshark 
an einem anderen Rechner sehen wegen dem Broadcast.
Siehst du die?

Μαtthias W. schrieb:
> Sieht für mich so aus als ob der PHY im reset festhängt.

Wenn der RX DataValid schon gewackelt hat, dann kann der nicht im reset 
sein.

Holger K. schrieb:
> Was müsste ich denn wohl per MDIO schreiben?

Im Datenblatt stehen die Register des PHY.
Da kommt dann das rein was du haben willst.
Geschwindigkeit, Duplex, LED geblinke, Loopbackmode.

Wie ich in deinem Schaltplan sehe hast du nicht alle PIns bootstrapped.
Also der Loopback könnte aktiv sein (wenn er sowas hat).

Dein Uboot will mit dem PHY an MDIO Adresse 0 reden.
Das ist eigentlich die Broadcastadresse (also richtig), aber durch 
fehlendes bootstrapping ist die Adresse wohl aus.
Löte an Pin 19 RXC/BCAST_OFF mal 1k gegen GND.

Die PHYAD kan auch irgendwas sein, weil Pin15 RXD1/PHYAD2 in der Luft 
wackelt nach dem reset.

Pin 19 CRS/CONFIG1 liegt frei.
Die CONFIGx bestimmen aber ob du MII oder RMII willst.
Der PHY läuft also grade irgendwie, nur nicht mit dem was du willst ;)

Was ich andauernd mit bootstrapping meine sind diese pull up/down am 
PHY.
Damit hat er nach dem Start eine Grundconfig.
Bei meinem STM32 gebastel muss ich dann nichtmal mehr per MDIO ran, das 
läuft dann auch so.

[Holger K. (holgerkraehe)]

Mw E. schrieb:
> Hatteste das nicht geschrieben?

Ich meinte damit, dass der PHY selbst das Netzwerkkabel erkennt, bzw. 
den Link, und daher die LEDs entsprechend blinken/leuchten.

Mw E. schrieb:
> Wenn uboot DHCP discovers schickt, dann müsst man die auch mit Wireshark
> an einem anderen Rechner sehen wegen dem Broadcast.
> Siehst du die?

Du bist genial!!
Ja!! Tatsächlich!!! Wireshark sieht die Pakete :)
Da geht also wirklich was raus :)

Mw E. schrieb:
> Wenn der RX DataValid schon gewackelt hat, dann kann der nicht im reset
> sein.

Der hat gewackelt.

Mw E. schrieb:
> Im Datenblatt stehen die Register des PHY.
> Da kommt dann das rein was du haben willst.
> Geschwindigkeit, Duplex, LED geblinke, Loopbackmode.
>
> Wie ich in deinem Schaltplan sehe hast du nicht alle PIns bootstrapped.
> Also der Loopback könnte aktiv sein (wenn er sowas hat).

Das stimmt. Inzwischen hab ich die fehlenden Pins noch gebootsrapped.
Hab das Datenblatt auch studiert. Scheint keine entsprechendes Loopback 
konfiguriert zu sein. Spätestens nach dem die DHCP Requests rausgehen, 
sollte es ja gut aussehen.

Mw E. schrieb:
> Die PHYAD kan auch irgendwas sein, weil Pin15 RXD1/PHYAD2 in der Luft
> wackelt nach dem reset.

Das hab ich mit dem Oszi geprüft.
Die sind 0 vor dem Reset. Denn den Reset führe ich manuell im U-Boot 
durch (selbst codiert und geprüft)

Mw E. schrieb:
> Pin 19 CRS/CONFIG1 liegt frei.
> Die CONFIGx bestimmen aber ob du MII oder RMII willst.
> Der PHY läuft also grade irgendwie, nur nicht mit dem was du willst ;)

Tut mir leid, das hätte ich noch erwähnen sllen. Die CONFIG 1 habe ich 
auch mit widerstand nach GND geschaltet. Somit ist aktiell die Konfig 
001 = RMII

Mw E. schrieb:
> Was ich andauernd mit bootstrapping meine sind diese pull up/down am
> PHY.
> Damit hat er nach dem Start eine Grundconfig.
> Bei meinem STM32 gebastel muss ich dann nichtmal mehr per MDIO ran, das
> läuft dann auch so.

Ich denke für das erfolgreiche versenden eines DHCP Requests ist RMII 
eine grundvoraussetzung oder? Also denkt Ihr / Du, dass RMII laufen 
sollte, da der DHCP Request raus ist?

Μαtthias W. schrieb:
> Was liegt denn an XI am PHY an? Da müssen 25MHz sein.

Liegen 50MHz an. Muss laut DB für den KSZ8041 so sein.

Μαtthias W. schrieb:
> REFCLK geht wohin?
> Denn das ist die eigentliche Taktfrequenz des RMII Interface. Deinen
> alternativen Schaltplan kann ich so nicht nachvollziehen.

Geht aktuell nirgends hin, liegt aber auch keine Frequenz dran an.

Μαtthias W. schrieb:
> Ansonsten solltest du auf jeden Fall
> das MII ans Laufen bekommen. Wenn ich den Schaltplan richtig lese hast
> du den PHY auf Adresse 2 konfiguriert. Das musst du den U-Boot Kommandos
> mitgeben.

Ich dachte, dass ich dies so im DT konfiguriert habe mit dem <REG> 
Bereich.


In Wireshark sehe ich, dass da gar keine Antwort von meinem DHCP auf die 
BOOTP anfrage kommt.

Bild im Anhang.
Eventuell läuft Ethernet schon seit Ewigkeiten und das Problem liegt 
ganz wo anders... Ohjee.... Mal in die DHCP Logs schauen...

EDIT:

DHCP hat der MAC-Adresse ein IP-Angebot unterbreitet.
Ich sehe dies im Wireshark wohl nicht mehr, da es direkt an diese MAC 
gerichtet wurde und der Switch dies entsprechend umleitet.
Mein Board hat das Angebot aber nicht angenommen... Bzw. wohl die Daten 
nicht "gesehen". IRQ Problem?

EDIT2:

Der DHCP fragt danach noch nach, wer denn die IP 30.40 hat

48  10.736624  ZyxelCom_68:1a:96  Broadcast  ARP  60  Who has 
192.168.30.40? Tell 192.168.30.1

[Holger K. (holgerkraehe)]

Hier nochmals der Schaltplan, um Klarheit zu schaffen.

CONFIG1 ist mi 1k gegen GND.

Pin 19 wird noch mit 1k gegen GND beschaltet.

Edit:

Mw E. schrieb:
> Dein Uboot will mit dem PHY an MDIO Adresse 0 reden.
> Das ist eigentlich die Broadcastadresse (also richtig), aber durch
> fehlendes bootstrapping ist die Adresse wohl aus.
> Löte an Pin 19 RXC/BCAST_OFF mal 1k gegen GND.

Habe nochmals im Datenblatt geschaut.

Pin 19 wird nicht als Bootstrapping option aufgeführt.

EDIT2:

Hier hatte jemand das gleiche Problem:

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Ethernet-ping-send-works-but-can-t-receive-data-uboot/td-p/681131

Leider aber nicht für imx6.

[Holger K. (Gast)]

Moin moin zusammen

Bin zuversichtlich, dass das Netzwerk heute zum laufen kommt :)

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Holger K. schrieb:
> Ich denke für das erfolgreiche versenden eines DHCP Requests ist RMII
> eine grundvoraussetzung oder? Also denkt Ihr / Du, dass RMII laufen
> sollte, da der DHCP Request raus ist?

Ja dann läut der PHY wie gewollt.

Holger K. schrieb:
> In Wireshark sehe ich, dass da gar keine Antwort von meinem DHCP auf die
> BOOTP anfrage kommt.

Das kannste auch nicht sehen, das DHCP Offer geht dann direkt an die MAC 
von wo das herkam.
Der englische Wikipediaartikel zu DHCP ist da sehr aufschlussreich.

Holger K. schrieb:
> DHCP hat der MAC-Adresse ein IP-Angebot unterbreitet.
> Ich sehe dies im Wireshark wohl nicht mehr, da es direkt an diese MAC
> gerichtet wurde und der Switch dies entsprechend umleitet.
> Mein Board hat das Angebot aber nicht angenommen... Bzw. wohl die Daten
> nicht "gesehen". IRQ Problem?

Dann aber eher ein IRQ Problem IM imx6, denn der MAC wirft den RX IRQ 
zum Paket abholen. (Wenn der MAC RX DMA fertig ist)
Woher kommt eigentlich die MAC Adresse?
Nicht, dass der MAC Adressenfilter in der MAC einfach alles wegwirft.
Wenn du alle Pakete zum/vom iimx6 sehen willt, dann steck ne USB 
LAnkarte an Rechner, mach ne Netzwerkbrücke auf und belausch die per 
Wireshark.

Holger K. schrieb:
> Habe nochmals im Datenblatt geschaut.
>
> Pin 19 wird nicht als Bootstrapping option aufgeführt.

Da hatte ich jetzt nur auf den Schaltplan gesehen.
Ich nutze hier den KSZ8081, irgendwas muss am 8041 ja anders sein.

[Holger K. (holgerkraehe)]

Danke für deine Antwort.


Mw E. schrieb:
> Dann aber eher ein IRQ Problem IM imx6, denn der MAC wirft den RX IRQ
> zum Paket abholen. (Wenn der MAC RX DMA fertig ist)
> Woher kommt eigentlich die MAC Adresse?
> Nicht, dass der MAC Adressenfilter in der MAC einfach alles wegwirft.
> Wenn du alle Pakete zum/vom iimx6 sehen willt, dann steck ne USB
> LAnkarte an Rechner, mach ne Netzwerkbrücke auf und belausch die per
> Wireshark.

Es könnte durchaus sein, dass der MAC-Filter im MAC die Pakete verwirft.
Die MAC-Adresse kommt von

CONFIG_NET_RANDOM_ETHADDR=y

in der U-Boot my_board_defconf

Der ausgehende Broadcast enthält diese, zufällig generierte MAC-Adresse 
ja auch. Kann es dennoch sein, dass ich den MAC im IMX noch speziell 
konfigurieren muss?

EDIT:

Ok hab das Register gefunden. Werde ich mal nachschauen, was da steht.

EDIT2:

So, leider steht das richtige drinn...

J-Link>mem32 21880e4 1
021880E4 = 6249998A
J-Link>mem32 21880e8 1
021880E8 = 03738808

Die MAC-Adresse ist laut U-Boot: 62:49:99:8a:03:73

Da Ethernet ja big-endian ist, gehe ich mal davon aus, dass das stimmt.
Denn die Abfolge ist klar ersichtlich.

021880E4 = 62 49 99 8A
021880E8 = 03 73 8808

Dies sind die Register ENET1_PALR und ENET1_PAUR

Da steht auch:

used in the
address recognition process to compare with the destination address (DA) field of receive
frames with an individual DA. (Seite 927 IMX6ULLRM.pdf)

[Holger K. (holgerkraehe)]

Mw E. schrieb:
> Wenn du alle Pakete zum/vom iimx6 sehen willt, dann steck ne USB
> LAnkarte an Rechner, mach ne Netzwerkbrücke auf und belausch die per
> Wireshark.

Hab ich mal gemacht.

Ich sehe den Offer vom DHCP.
Der geht an den IMX.

Leider bisher noch immer das gleiche Verhalten.
Irgendwas stimmt einfach noch nicht ganz.

[Holger K. (holgerkraehe)]

Mir fällt auf, dass der PC, an welchem das Board nun angeschlossen ist, 
keine empfangenen Frames anzeigt.

Das deutet doch auf ein Hardware Problem hin oder?

Denn ich sehe die ankommenden Pakete im Wireshark.
Aber offenbar werden diese vom PHY nicht angenommen?

EDIT:

Ich sehe die QAM-Modulierten Signale am PHY RX Eingang.
Sowohl RX+ als auch RX-

[Dirk M. (dirkm)]

Moin,

habe selbst schon einige IMX6(UL) Designs realisiert.

Was mir auffällt: C9 sollte 100pF sein bzw ist in vielen Designs nicht 
bestückt.

Hast du in U-Boot die richtige "CONFIG_FEC_MXC_PHYADDR" definiert? An 
Pin 15 hast du leider keinen Bootstrap Widerstand. Ist dann vermutlich 2 
oder 6.

[Holger K. (holgerkraehe)]

Hallo Dirk

Vielen Dank für deine Antwort.

Ich werde gleich mal versuchen, ob es ohne C9 bzw. mit 100pF C9 besser 
geht.

Ja, ich hab dies so konfiguriert:

#define CONFIG_FEC_MXC_PHYADDR          0x2

Dirk M. schrieb:
> An
> Pin 15 hast du leider keinen Bootstrap Widerstand. Ist dann vermutlich 2
> oder 6.

Nach meinen Messungen, sollte Pin15 beim Reset eigentlich low sein.
Würden denn überhaupt Datenpakete rausgehen, wenn die PHYADDR falsch 
ist?

Was mir noch auffällt, in u-boot kann ich mittels mdio kommandos 
keinerlei register auslesen.

Dirk M. schrieb:
> habe selbst schon einige IMX6(UL) Designs realisiert.

Sehr schön! :)
Weist du eventuell, wo man Informationen bekommt bezüglich der 
Konfigurationen?

Woher weiss man z.B. dass es einen Parameter wie

CONFIG_FEC_MXC_PHYADDR

überhaupt gibt?

Ich habe mir dies einfach aus anderen Boards zusammengereimt.
Per Zufall bin ich über dieses Define gestossen.

[Dirk M. (dirkm)]

Habe bisher immer die NXP u-Boot Referenz implemenation 
(imx6ul-14x14-evk, imx6q-sabre lite etc) genommen, kopiert und an mein 
Board angepasst.

Soweit ich weiß wird bei falscher (MDIO)Phy-Adresse die MAC Adresse & 
einige Register nicht richtig gesetzt, Daten gehen aber über das RMII 
Interface raus.

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Soweit ich weiß wird bei falscher (MDIO)Phy-Adresse die MAC Adresse &
> einige Register nicht richtig gesetzt, Daten gehen aber über das RMII
> Interface raus.

Nun, die MAC-Adresse geht ja eigentlich in den MAC des IMX. Dort habe 
ich die mal ausgelesen. Die Stimmt soweit.

Der PHY hat (laut DB) kein Register für eine MAC.

Vermutlich stimmt dann wohl hier was nicht:

&fec2 {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_enet2>;
  phy-mode = "rmii";
  phy-handle = <&ethphy1>;
  status = "okay";

  mdio {
    #address-cells = <1>;
    #size-cells = <0>;

    ethphy0: ethernet-phy@2 {
      compatible = "micrel,ksz8xxx";
      reg = <2>;
    };
}

Wobei ich nicht weiss, ob ich micrel,ksz8xxx hineinschreiben muss?

Aktuell stehts so:

  mdio {
    ethphy: ethernet-phy@2 {
      compatible = "ethernet-phy-ieee802.3-c22";
      reg = <2>;
      max-speed = <100>;
    };
  };

[Dirk M. (dirkm)]

Würde erstmal zusehen dass DHCP / PING in U-Boot geht.

Welchen Kernel verwendest du? Hast du beide LAN Schnittstellen 
angeschlossen?

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Würde erstmal zusehen dass DHCP / PING in U-Boot geht.

Du meinst DHCP ist unabhängig von einem funktionierenden MDIO?

Dirk M. schrieb:
> Welchen Kernel verwendest du? Hast du beide LAN Schnittstellen
> angeschlossen?

Kernel bisher noch keinen. Später dann den Mainline.
Aktuell bin ich weiterhin nur in U-Boot unterwegs.

Nur eine LAN-Schnittstelle. ENET1

[Dirk M. (dirkm)]

Das wäre mir neu dass U-Boot einen Linux Device Tree benötigt oO Habe 
zuletzt 2018.11 verwendet.

Stimmt dein MIDO Pin Muxing?

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Das wäre mir neu dass U-Boot einen Linux Device Tree benötigt oO Habe
> zuletzt 2018.11 verwendet.

Doch, das scheint den DT zu benützen. War so in der Mitte des Threads 
auch ein Thema... :)


Mein aktuelles Muxing im DT sieht so aus:

&iomuxc {
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_hog_1>;
  eval1a {

    pinctrl_enet1: enet1grp {
      fsl,pins = <
        MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN  0x1b0b0
        MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER  0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00  0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01  0x1b0b0
        MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN  0x1b0b0
        MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00  0x1b0b0
        MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01  0x1b0b0
        MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1  0x4001b031
        MX6UL_PAD_GPIO1_IO07__ENET1_MDC    0x1b0b0
        MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
      >;
    };

Da du offensichtlich keinen DT verwendet hast, hast du das PIN-Muxing 
wohl in der C-Datei erledigt, so wie es bei den meisten Boards auch der 
Fall war?

Da steht bei mir aktuell noch folgendes drin:
Also im C-File noch ohne MDIO-Pins, da ich irgendwann davon überzeugt 
wurde, dass der DT alles selbst erledigt...

static iomux_v3_cfg_t const fec_pads[] = {
  MX6_PAD_ENET1_RX_EN__ENET1_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_ER__ENET1_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA0__ENET1_RDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA1__ENET1_RDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_EN__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA0__ENET1_TDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA1__ENET1_TDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL), //Oder Ref clock???
};

static void setup_iomux_fec(void)
{
  imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));

  /* Reset KSZ8041 PHY */
  gpio_request(ETH_PHY_POWER, "eth_pwr");
  gpio_direction_output(ETH_PHY_POWER , 1);
  udelay(150);
  gpio_set_value(ETH_PHY_POWER, 0);
  udelay(15000);
  gpio_set_value(ETH_PHY_POWER, 1);
  udelay(1500);
}

int board_init(void)
{
  /* Address of boot parameters */
  gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;



  setup_iomux_fec();
}

Weist du, ob es die funktion fecmxc_initialize braucht?
Es gibt auch noch eine fecmxc_initialize_multi. Diese ist aber für mich 
nicht verfügbar.

[Dirk M. (dirkm)]

Habs bisher nur über die C Datei gemacht..

Dann würde noch MDIO und Reset Muxing fehlen ;-)

zb:
MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(MDIO_PAD_CTRL),
MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),

Wofür ist RESET

Dirk M. schrieb:
> Reset Muxing fehlen ;-)

Was meinst du mit letzterem?
Hab den RESET des PHYs an GPIO 4 pin 10


Ok ich versuche mal, die beiden MDIO in die C-Datei hinzuzufügen.

Edit:

Sobald ich

  MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(MDIO_PAD_CTRL),
  MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(MDIO_PAD_CTRL),

hinzufüge, kommt in der U-Boot Konsole: "no ethernet found"

[Holger K. (holgerkraehe)]

Ok, MDIO funktioniert nun!

  MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),

Ich musste ENET_PAD_CTRL verwenden, ansonsten geht nichts mehr.
Obschon andere auch MDIO_PAD_CTRL verwendet haben:

https://github.com/ARM-software/u-boot/blob/master/arch/arm/mach-imx/mx6/opos6ul.c

Nun wird der PHY sogar korrekt erkannt.
MDIO list gibt:

=> mdio read 2 00
2 is not a known ethernet
Reading from bus FEC
PHY at address 2:
0 - 0x3000

=> mdio list
FEC:
2 - Micrel KSZ804 <--> FEC

DHCP gibt nun keine "waiting for link negotiation...." mehr aus.
DHCP selbst geht aber trozdem noch nicht :(

MII Dump zeigt folgendes:

=> mii dump 2
0.     (3000)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0000) 0. 8    =     0    duplex = half
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

[Dergute W. (derguteweka)]

Moin,

Ich wuerd' DHCP erstmal lassen und mit fixen ip-adressen arbeiten. 
Versuch' einen Ping vom imx6 zu deinem PC, Dann muss uboot erst einen 
ARP machen und dann ICMP; also genug Pakete zum wiresharken und beide 
Richtungen kommen auch vor.

Gruss
WK

[Holger K. (holgerkraehe)]

Dergute W. schrieb:
> Versuch' einen Ping vom imx6 zu deinem PC,

Hab ich sogleich mal versucht:

=> setenv ipaddr 192.168.30.200
=> setenv serverip 192.168.30.1
=> setenv netmask 255.255.255.0
=> ping 192.168.30.1
Using FEC device

ARP Retry count exceeded; starting again
ping failed; host 192.168.30.1 is not alive

ARP geht raus. Antwort kommt.
IMX ignoriert diese bzw. bekommt diese nie?

Ich weiss es nicht, denn der Counter der Netzwerkkarte in Windows zeigt 
auch dauern 0 Bytes empfangen. Wenn ich das Board direkt mit dem Switch 
verbinde, ändert sich jedoch auch nichts am Verhalten.

EDIT:

Ist evtl der PHY defekt? Ist zwar ein neuer Chip...
Ich sehe ja auch Daten am RX und TX des RMII interface.
Ebenso sehe ich QAM-Siganle am RX Eingang des PHYs

Es fragt sich, welche Bedingung erfüllt sein muss, dass Windows seinen 
Empfangscounter hochzählt.

EDIT2:

Habe mal ein anderes Gerät an meinen Rechner gehängt.
Dort zählt der Counter tatsächlich hoch. Somit ist dieser Indikator also 
als zuverlässig einzustufen.

[Dergute W. (derguteweka)]

Moin,

Holger K. schrieb:
> ARP geht raus. Antwort kommt.
> IMX ignoriert diese bzw. bekommt diese nie?

Ja, sieht so aus. Kannste mitm scope gucken, was in dem Fall uebers 
(RG)MII-Interface vom PHY zum imx6 geht? evtl. Leitung vertauscht oder 
sowas? Liegt CLk an...?

Holger K. schrieb:
> Es fragt sich, welche Bedingung erfüllt sein muss, dass Windows seinen
> Empfangscounter hochzählt.

Bei so lowlevelkram wuerd' ich mich nicht auf Windowsanzeigen verlassen. 
Da wird keiner so genau wissen (wollen), was da wann angezeigt wird ;-)

Gruss
WK

[Holger K. (Gast)]

Dergute W. schrieb:
> Ja, sieht so aus. Kannste mitm scope gucken, was in dem Fall uebers
> (RG)MII-Interface vom PHY zum imx6 geht? evtl. Leitung vertauscht oder
> sowas? Liegt CLk an...?

Werd ich machen können. Und auch noch machen.

Dergute W. schrieb:
> Bei so lowlevelkram wuerd' ich mich nicht auf Windowsanzeigen verlassen.
> Da wird keiner so genau wissen (wollen), was da wann angezeigt wird ;-)

Das stimmt schon. Aber immerhin sehe ich, dass ein anderes Board bzw. 
Netzwerkgerät, den Empfangscounter hochzählen lässt.

[S. R. (svenska)]

Hallo,

Holger K. schrieb:
> Fragt sich, ob dieser an einen speziellen ENET IRQ angeschlossen
> werden muss (sofern es einen solchen überhaupt gibt) oder ob man
> grundsätzlich einen beliebigen Interrupt verwenden kann.

Grundsätzlich kann man einen beliebigen Interrupt verwenden, weil "ist 
ja nur Software". Deswegen auch die Eigenschaften "interrupt-parent" und 
so. Wenn der Treiber den PHY auch pollen kann, geht's aber auch ohne.

> Bezüglich dem Eintragen des IRQs im Devicetree habe ich etwas
> weiter oben diesen Auszug gepostet:
> ethernet@83fec000 {
>   compatible = "fsl,imx6-fec";
>   reg = <0x83fec000 0x4000>;
>   interrupts = <87>;
>   phy-mode = "mii";
>   phy-reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* GPIO4_10 */
> ...
>
> Hier wird der Interrupt mit einer Nummer definiert.
> Nun befinden sich diese Zeilen jedoch im dtsi file.
> Dieses sollte ich nicht abändern, da es global von Freescale ist.
> Gibt es eine Möglichkeit, diese Einstellungen in meinem dts File zu
> überschreiben?

Ja, du kannst Properties jederzeit hinzufügen oder überschreiben 
(entfernen geht nur, wenn du kein DTBO - Devicetree Binary Overlay - 
verwendest). Der dtc (Devicetree Compiler) geht von oben nach unten 
durch, der jeweils letzte Eintrag gewinnt.

/* &flash_led wurde irgendwo in einem DTSI definiert und
   konfiguriert, aber nicht aktiviert - also einschalten */
&flash_led {
    status = "ok";
};

Holger K. schrieb:
> Ich glaube ich muss dennoch ein paar Dinge im *.c File ergänzen.
> Was müsste ich denn wohl per MDIO schreiben?

Die Frage ist, welche Teile U-Boot vom devicetree benutzt. Es kann sein, 
dass das Pinmuxing z.B. noch nicht portiert wurde und du das nur nicht 
merkst, weil du das in deinem Board-Setup zusätzlich auch nochmal 
einrichtest. Da hilft nur in den Code schauen...

Zumindest der MAC-Treiber liest den devicetree nur partiell und 
generiert daraus die Daten, die sonst in der Board-Datei stehen würden.

Holger K. schrieb:
> Ich weiss es nicht, denn der Counter der Netzwerkkarte
> in Windows zeigt auch dauern 0 Bytes empfangen.

Das hängt vom Netzwerktreiber auf dem Windows-Computer ab. Da moderne 
Netzwerkkarten zunehmend auch Datenverarbeitung übernehmen können, haben 
nicht alle Treiber die Rohdaten zur Verfügung oder leiten sie an Windows 
weiter.

Ich würde an deiner Stelle mal direkt tftp oder so versuchen, weil das 
sehr primitives Handshaking verwendet und direkt auf UDP ohne Broadcasts 
aufsetzt. Sämtliche Pakete sollten im Wireshark sichtbar sein können 
(zumindest auf dem tftp-Server).

[Holger K. (Gast)]

Dergute W. schrieb:
> Ja, sieht so aus. Kannste mitm scope gucken, was in dem Fall uebers
> (RG)MII-Interface vom PHY zum imx6 geht? evtl. Leitung vertauscht oder
> sowas? Liegt CLk an...?

Hab ich nun geschaut mit dem Logicanalyzer.
Bild ist im Anhang.

Ich persönlich werde daraus nicht wirklich schlau.
Kennt sich jemand damit aus? Einen Decoder gibt es leider nicht mal von 
sigrok.

Das Oszi Bild sieht dem Logicanalyzer sehr ähnlich. Daher glaube ich dem 
LA einfach mal. Dieser tastet übrigens mit 400MHz ab.

S. R. schrieb:
> Grundsätzlich kann man einen beliebigen Interrupt verwenden, weil "ist
> ja nur Software". Deswegen auch die Eigenschaften "interrupt-parent" und
> so. Wenn der Treiber den PHY auch pollen kann, geht's aber auch ohne.

Irgendwo wurde erwähnt, dass es sich um einen Internen Interrupt handelt 
und keinen HW-Interrupt. Also müsste ich nichts verbinden.

S. R. schrieb:
> Ja, du kannst Properties jederzeit hinzufügen oder überschreiben
> (entfernen geht nur, wenn du kein DTBO - Devicetree Binary Overlay -
> verwendest). Der dtc (Devicetree Compiler) geht von oben nach unten
> durch, der jeweils letzte Eintrag gewinnt.

Vielen Dank. Das ist ein sehr wertvolles Beispiel für mich.

S. R. schrieb:
> weil du das in deinem Board-Setup zusätzlich auch nochmal
> einrichtest. Da hilft nur in den Code schauen...
>
> Zumindest der MAC-Treiber liest den devicetree nur partiell und
> generiert daraus die Daten, die sonst in der Board-Datei stehen würden.

Inzwischen hab ich es ja doppelt eingetragen. MDIO läuft inzwischen. Nur 
der Empfang geht nicht.

S. R. schrieb:
> Das hängt vom Netzwerktreiber auf dem Windows-Computer ab. Da moderne
> Netzwerkkarten zunehmend auch Datenverarbeitung übernehmen können, haben
> nicht alle Treiber die Rohdaten zur Verfügung oder leiten sie an Windows
> weiter.

Natürlich individuell. Aber wenn Netzwerkgerät A angehängt ist, wird ein 
Empfang angezeigt. Bei Netzwerkgerät B jedoch nicht. Netzwerkgerät B, in 
diesem Fall mein Board, empfängt auch tatsächlich nichts. Daher denke 
ich, ist an dem Counter in diesem Fall tatsächlich etwas dran. Ich 
dachte nur, vielleicht lässt sich von dieser Seite her etwas genaueres 
herausfinden. Evtl. Paketfehler etc.

S. R. schrieb:
> Ich würde an deiner Stelle mal direkt tftp oder so versuchen, weil das
> sehr primitives Handshaking verwendet und direkt auf UDP ohne Broadcasts
> aufsetzt. Sämtliche Pakete sollten im Wireshark sichtbar sein können
> (zumindest auf dem tftp-Server).

Mit fix konfigurierter IP antwortet das Board ja nicht mal auf ARP 
Pakete.
Ich habe wenig Hoffnung, dass da tftp funktioniert.

[Holger K. (Gast)]

Hier noch eine zweite Messung mit zwei RMII Paketen.

[Holger K. (Gast)]

S. R. schrieb:
> Ich würde an deiner Stelle mal direkt tftp oder so versuchen, weil das
> sehr primitives Handshaking verwendet und direkt auf UDP ohne Broadcasts
> aufsetzt. Sämtliche Pakete sollten im Wireshark sichtbar sein können
> (zumindest auf dem tftp-Server).

Habe ich nun probiert. Da werden zuerst ARP gesendet um die MAC des 
Servers zu finden. Die ARP Antworten werden jedoch genau wie beim PING 
nicht weiter verarbeitet / beachtet.

[Holger K. (Gast)]

Guten Morgen zusammen.

Falls Vorschläge vorhanden sind, nehme ich diese gerne entgegen :)

[soso... (Gast)]

Holger K. schrieb:
> Guten Morgen zusammen.
>
> Falls Vorschläge vorhanden sind, nehme ich diese gerne entgegen :)

Schau dir doch mal die Hardware ganauer an. Also:
- der Refclk da ist, und ob Pegel und Flanken passen
- wie die Signale auf der RMII aussehen (RX UND TX)
- Ob die MDIO vernünftig funktioniert
- Ob aus dem Trafo das richtige Signal herauskommt (bei 100MBd geht das 
noch)
- Kommt ein PHY-Reset, und wann
Bei den Ethernet-Leitungen solltest du immer Flanken  auf allen 
Leitungen sehen, wenn ein Link da ist. Dazu sind keine Daten nötig.

Kontrollier auch noch mal ganz genau das Pinning. Ich hatte schon mal 
ein paar Leitungen in der RMII vertauscht (RX1 und RX2), das gab 
seltsame Phenomene. Link war da, aber Daten kamen keine.
Wir hatten auch schon einmal ein falsches zeitliches Handling von 
Phy-Reset und Clock - der Linux-Treiber drehte nach dem letzten Reset 
den Clock nochmal ab, das mochte unser PHY nicht.

[Holger K. (holgerkraehe)]

soso... schrieb:
> der Refclk da ist, und ob Pegel und Flanken passen

Ist beides korrekt.

soso... schrieb:
> wie die Signale auf der RMII aussehen (RX UND TX)

RX hab ich mir gestern angeschaut. Die "Daten" selbst kann ich nicht 
interpretieren. Aber für mich sieht es nicht schlecht aus. TX mach ich 
mir keine Sorgen, da ja Pakete raus gehen.

soso... schrieb:
> Ob die MDIO vernünftig funktioniert

Tut korrekt.

soso... schrieb:
> Ob aus dem Trafo das richtige Signal herauskommt (bei 100MBd geht das
> noch)

Ja, hab ich mir auch schon angeschaut.

soso... schrieb:
> Kontrollier auch noch mal ganz genau das Pinning.

Hab ich gemacht. Stimmt leider alles.


----

Hab mich nun nochmals mit dem MAC beschäftigt.
Wenn ich mit U-Boot das Ethernet Control Register (ENETx_ECR) auslese, 
dann steht da zuerst 0xf0000000 drinn. Nach einem ersten dhcp versuch 
steht 0xf0000100

Das eine bit bedeutet:

Descriptor Byte Swapping Enable
Swaps the byte locations of the buffer descriptors.
NOTE: This field must be written to 1 after reset.
0 The buffer descriptor bytes are not swapped to support big-endian devices.
1 The buffer descriptor bytes are swapped to support little-endian devices.

Soweit so gut.
Aber... Bit1 ist nicht gesetzt.

Ethernet Enable
Enables/disables the Ethernet MAC. When the MAC is disabled, the buffer descriptors for an aborted
transmit frame are not updated. The uDMA, buffer descriptor, and FIFO control logic are reset, including
the buffer descriptor and FIFO pointers.
Hardware clears this field under the following conditions:
• RESET is set by software
• An error condition causes the EBERR field to set.
NOTE: • ETHEREN must be set at the very last step during ENET configuration/setup/initialization,
only after all other ENET-related registers have been configured.
• If ETHEREN is cleared to 0 by software then next time ETHEREN is set, the EIR interrupts
must cleared to 0 due to previous pending interrupts.
0 Reception immediately stops and transmission stops after a bad CRC is appended to any currently
transmitted frame.
1 MAC is enabled, and reception and transmission are possible.

Da frage ich mich allerdings, ob das für jede Transaktion also für jedes 
Paket einzeln gesetzt wird, und ich es deshalb nicht auslesen kann, da 
ich ja während der Übertragung nicht darauf zugreifen kann.

Weil es steht ja "reception and transmission" also dürfte auch nicht 
gesendet werden können.

Ich hab es auch mal manuell gesetzt und dhcp versucht. Gleicher 
Ergebnis. Danach war es wieder gelöscht worden.

EDIT

Was auch auffält ist, dass alle Statistikregister leer sind. Also z.b. 
Frames Transmitted OK Statistic Register (ENETx_IEEE_T_FRAME_OK)

Zeigt nichts an, obwohl ich die Pakete ja im Wireshark sehen kann.
Auch bei den Receiveregistern das gleiche...

[Holger K. (holgerkraehe)]

Der RX-Error Pin des PHYs ist übrigens immer low.
Folglich registriert der PHY noch keine Errors.

Es muss also etwas im IMX probleme machen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Da haste ja echt ne harte Nuss zu knacken.

MII Überträgt pro Takt ein Nibble (=4Bit) es Ethernetframes.
Bei RMII hat man den Takt verdoppelt um mit 2 Leitungen auszukommen.
Also musste wieder die Bytes zusammenbauen und dann haste dein 
Ethernetframe.
Aber das führt glaube zu nix, seidenn du willst mal aus Spaß den 
Ethernetframe zB bis zu den beiden MAC Adressen per Hand angucken.

MII ist bei sigrok in Planung, RMII nichtmal das :/
Aber MDIO könnteste dir angucken, das funzt nach deiner Aussage ja nun.

Aber das klingt alles so als müssteste mal nen Gang zurückschalten.
UBoot bringt hier wohl so viel Komplexität mit, dass wir den Fehler 
nicht sehen.

Du kannst ja mal mit Registergeklimper ein ARP senden, was du vorher per 
Wireshark empfangen hast.
Wireshark kann Pakete als C Array exportieren.

Wenn jetzt natürlich der RX DMA Descriptor nicht richtig gesetzt ist, 
dann wirft der MAC das empfangene Paket einfach weg.

Also das auch mal per Hand machen und per UART Asgeben was der empfangen 
hat?
(sone ARP Antwort is ja schön kurz).

[Holger K. (Gast)]

Mw E. schrieb:
> Da haste ja echt ne harte Nuss zu knacken.

Oh jaa... Bin schon seit Tagen damit beschäftigt.

Seit heute funktioniert MDIO nicht mehr richtig.
Warum? Weiss ich noch nicht.

Habe den Fehler soweit eingerenzt, dass wenn ich im Code

static iomux_v3_cfg_t const fec_pads[] = {
  MX6_PAD_ENET1_RX_EN__ENET1_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_ER__ENET1_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA0__ENET1_RDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_RX_DATA1__ENET1_RDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_EN__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA0__ENET1_TDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_DATA1__ENET1_TDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL), //Oder Ref clock???
  //MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
  //MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
};

Die unteren beiden Zeile auskommentiere, dann sagt er mir wieder:

FEC Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY FEC

Was jedoch nicht weiter shclimm ist, denn die Pakete gehen trozdem raus.

Mw E. schrieb:
> Wenn jetzt natürlich der RX DMA Descriptor nicht richtig gesetzt ist,
> dann wirft der MAC das empfangene Paket einfach weg.

Das ist doch ein interessanter Ansatz.

Meinst du:

Transmit Buffer Descriptor Ring Start Register(ENETx_TDSR)
und
Receive Descriptor Ring Start Register (ENETx_RDSR)
?

RDSR points to the beginning of the circular receive buffer descriptor queue in external
memory. This pointer must be 64-bit aligned (bits 2–0 must be zero); however, for
optimal performance the pointer should be 512-bit aligned, that is, evenly divisible by 64.

Diese sind beide auf null.

Mw E. schrieb:
> Also das auch mal per Hand machen und per UART Asgeben was der empfangen
> hat?

Meinst du das auslesen des Empfangs fifos?

[Holger K. (Gast)]

Habe mir übrigens seit einiger Zeit das U-Boot als makefile projekt in 
eclipse aufgesetzt.

Würde das ganze gerne Debuggen. Hab dafür auch ne konfig. Das 
Runterladen funktioniert auch. Aber beim halten sagt Eclipse, dass es 
nicht weis, was sich an Speicherposition xy befindet und daher keine 
passende quelldatei anzeigen kann.

Weiss evtl. jemand wie man dies anpassen kann?

[Μαtthias W. (matthias)]

https://www.denx.de/wiki/view/DULG/DebuggingUBoot

Evtl. ist es auch hilfreich wenn du den U-Boot von Freescale nimmst. Da 
wimmelt es zwar oft von irgendwelchen Hacks aber der ist auch auf einem 
entsprechenden evalboard gelaufen.

Sonst kannst du auch Mal versuchen einen USB <-> Ethernet Adapter ans 
Laufen zu bekommen. Sollte mit U-Boot auch gehen.

[Holger K. (Gast)]

Μαtthias W. schrieb:
> https://www.denx.de/wiki/view/DULG/DebuggingUBoot

Danke für den Link

Eigentlich genau das, wonach ich suche.
Leider funktioniert es nicht wirklich, wenn ich entsprechendes eintrage 
(siehe bild)

Vielleicht sieht jemand den fehler?

Μαtthias W. schrieb:
> Evtl. ist es auch hilfreich wenn du den U-Boot von Freescale nimmst. Da
> wimmelt es zwar oft von irgendwelchen Hacks aber der ist auch auf einem
> entsprechenden evalboard gelaufen.

Ja, wär evtl auch eine möglichkeit.
Bevor ich jedoch blind die sourcen wechsle, möchte ich noch versuchen zu 
debuggen und versuchen  zu verstehen, was schief läuft.

Μαtthias W. schrieb:
> Sonst kannst du auch Mal versuchen einen USB <-> Ethernet Adapter ans
> Laufen zu bekommen. Sollte mit U-Boot auch gehen.

Würde ich gerne. Hab aber USB nicht rausgeführt...

[S. R. (svenska)]

Holger K. schrieb:
>> Grundsätzlich kann man einen beliebigen Interrupt verwenden,
>> weil "ist ja nur Software". Deswegen auch die Eigenschaften
>> "interrupt-parent" und so. Wenn der Treiber den PHY auch pollen
>> kann, geht's aber auch ohne.
>
> Irgendwo wurde erwähnt, dass es sich um einen Internen Interrupt
> handelt und keinen HW-Interrupt. Also müsste ich nichts verbinden.

Der MAC hat definitiv seinen internen Interrupt, weil er im SoC 
integriert ist. Das gilt aber nicht für den PHY, denn der ist ja extern.

Wenn du also einen falschen Interrupt für den PHY konfiguriert hast, 
dann wird das nicht funktionieren. Wenn du keinen Interrupt gesetzt 
hast, sollte der Treiber entweder eine Fehlermeldung ausgeben 
(notwendige Property nicht gesetzt), oder auf Polling umschalten.

> S. R. schrieb:
>> Zumindest der MAC-Treiber liest den devicetree nur partiell
>> und generiert daraus die Daten, die sonst in der Board-Datei
>> stehen würden.
>
> Inzwischen hab ich es ja doppelt eingetragen.
> MDIO läuft inzwischen. Nur der Empfang geht nicht.

Ist deine Interruptkonfiguration richtig? Nicht, dass der Treiber auf 
den falschen Interrupt vom MAC wartet. Gleiches für den PHY.

Wenn ich hier Stuss erzähle, dann liegt das daran, dass ich mich mit 
Ethernet auf der Ebene nicht auskenne. Nur mit Devicetrees und Hardware 
im Allgemeinen. :-)

Zum Senden braucht man ja keine Interrupts, zumindest nicht für kleine 
Datenmengen - für den Empfang aber schon.

> Daher denke ich, ist an dem Counter in diesem Fall tatsächlich
> etwas dran. Ich dachte nur, vielleicht lässt sich von dieser
> Seite her etwas genaueres herausfinden. Evtl. Paketfehler etc.

Häng mal ein Linux (mit möglichst dummer Netzwerkkarte) ran. Da gibt es 
meist sehr aussagekräftige Statistiken vom Kernel. Wie man vergleichbare 
Daten aus Windows rauskriegt, weiß ich nicht.

Holger K. schrieb:
> S. R. schrieb:
>> Ich würde an deiner Stelle mal direkt tftp oder so versuchen, weil das
>> sehr primitives Handshaking verwendet und direkt auf UDP ohne Broadcasts
>> aufsetzt. Sämtliche Pakete sollten im Wireshark sichtbar sein können
>> (zumindest auf dem tftp-Server).
>
> Habe ich nun probiert. Da werden zuerst ARP gesendet um die MAC des
> Servers zu finden. Die ARP Antworten werden jedoch genau wie beim PING
> nicht weiter verarbeitet / beachtet.

Naja, einen Versuch war's wert. :-)

[St. D. (st_d)]

RX_EN sieht nicht gut aus! Es müsste durchgehend High sein bis Ende des 
Frames.

[Μαtthias W. (matthias)]

Holger K. schrieb:
> Μαtthias W. schrieb:
>> https://www.denx.de/wiki/view/DULG/DebuggingUBoot
>
> Danke für den Link
>
> Eigentlich genau das, wonach ich suche. Leider funktioniert es nicht
> wirklich, wenn ich entsprechendes eintrage (siehe bild)
>
> Vielleicht sieht jemand den fehler?

Ja, der Fehler ist die Verwendung von Eclipse ;-) Nimm nur den gdb und 
den gdbserver für den JLink. Ist erstmal lästig aber du umgehst die 
ganzen Unbekannten in der Kommunikation von Eclipse mit deinem gdb. Wenn 
das dann Mal läuft kannst du noch das TUI vom gdb verwenden oder sowas 
wie gdbgui oder VSCode. Von Eclipse würde ich in dem Zusammenhang die 
Finger lassen.

[Holger K. (Gast)]

S. R. schrieb:
> Wenn du also einen falschen Interrupt für den PHY konfiguriert hast,
> dann wird das nicht funktionieren. Wenn du keinen Interrupt gesetzt
> hast, sollte der Treiber entweder eine Fehlermeldung ausgeben
> (notwendige Property nicht gesetzt), oder auf Polling umschalten.

Nun, ich habe nicht aktiv einen Interrupt gesetzt. Aber im DTSI File 
wird folgendes vorgegeben:

      fec1: ethernet@02188000 {
        compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
        reg = <0x02188000 0x4000>;
        interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
               <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&clks IMX6UL_CLK_ENET>,
           <&clks IMX6UL_CLK_ENET_AHB>,
           <&clks IMX6UL_CLK_ENET_PTP>,
           <&clks IMX6UL_CLK_ENET_REF>,
           <&clks IMX6UL_CLK_ENET_REF>;
        clock-names = "ipg", "ahb", "ptp",
                "enet_clk_ref", "enet_out";
        stop-mode = <&gpr 0x10 3>;
        fsl,num-tx-queues=<1>;
        fsl,num-rx-queues=<1>;
        fsl,magic-packet;
        fsl,wakeup_irq = <0>;
        status = "disabled";
                        };

Muss ich den Interrupt evntuell noch manuell, selbst in meinem C-File 
aktivieren?

S. R. schrieb:
> Wenn ich hier Stuss erzähle, dann liegt das daran, dass ich mich mit
> Ethernet auf der Ebene nicht auskenne. Nur mit Devicetrees und Hardware
> im Allgemeinen. :-)

Nein keineswegs. Ich bin immer froh über Vorschläge und andere 
Meinungen.

S. R. schrieb:
> Häng mal ein Linux (mit möglichst dummer Netzwerkkarte) ran. Da gibt es
> meist sehr aussagekräftige Statistiken vom Kernel. Wie man vergleichbare
> Daten aus Windows rauskriegt, weiß ich nicht.

Werde ich versuchen. Bei Windows wäre es netstats

S. R. schrieb:
> Naja, einen Versuch war's wert. :-)

Auf jeden Fall! :)

St. D. schrieb:
> RX_EN sieht nicht gut aus! Es müsste durchgehend High sein bis
> Ende des
> Frames.

Ok, dann sollte ich mir das mal genauer anschauen. Das würde ja dann auf 
einen defekten PHY hindeuten?

Μαtthias W. schrieb:
> Ja, der Fehler ist die Verwendung von Eclipse ;-) Nimm nur den gdb und
> den gdbserver für den JLink. Ist erstmal lästig aber du umgehst die
> ganzen Unbekannten in der Kommunikation von Eclipse mit deinem gdb. Wenn
> das dann Mal läuft kannst du noch das TUI vom gdb verwenden oder sowas
> wie gdbgui oder VSCode. Von Eclipse würde ich in dem Zusammenhang die
> Finger lassen.

Ich kann verstehen, dass Eclipse nicht jeder manns sache ist. Aber dass 
es deshalb gleich überhaupt nicht funktionieren soll kann ich mir jetzt 
nicht ganz vorstellen :)

Aktuell kompiliere ich u-boot unter ubuntu.
VSCode wäre ja Windows. Eventuell schaue ich mir mal an, ob ich das auf 
windows zügeln kann. Vermutlich aber nicht so leicht, wegen make config 
etc...

[Μαtthias W. (matthias)]

Holger K. schrieb:
> Ich kann verstehen, dass Eclipse nicht jeder manns sache ist. Aber dass
> es deshalb gleich überhaupt nicht funktionieren soll kann ich mir jetzt
> nicht ganz vorstellen :)

Doch Eclipse funktioniert schon. Aber du hast schon einen Spezialfall. 
Baremetal Anwendung, Crosstoolchain, gdbserver, JTAG, JLink und 
relocation. Da dürfte die Anzahl der Eclipse-Anwender mit diesem usecase 
sehr sehr klein sein und damit auch die Testabdeckung. Darum auch meine 
Empfehlung erstmal mit dem gdb alleine zu testen um eben eine ziemlich 
große Fehlerquelle auszuschließen.

> Aktuell kompiliere ich u-boot unter ubuntu. VSCode wäre ja Windows.
> Eventuell schaue ich mir mal an, ob ich das auf windows zügeln kann.
> Vermutlich aber nicht so leicht, wegen make config etc...

VSCode ist Crossplatform. Läuft unter Linux genauso gut wie unter 
Windows und hat meiner Erfahrung nach die deutlich bessere gdb Anbindung 
als Eclipse insbesondere für speziellere Anwendungsfälle. Aber VSCode 
wäre bei mir erst der zweite Schritt wenn gdb in der Shell läuft.

[Holger K. (Gast)]

Hallo Mathias

Danke für deine Antwort.
Das Problem war „relocation“
Nachdem ich diese adresse anstelle meiner sys_text_base ins 
entsprechende feld geschrieben habe, gings sogar mit dem debuggen :)

Mein Setup ist sogar noch etwas komplizierter. Ubuntu läuft in der 
virtuellen maschine. Eclipse ebenfalls. Der jlink ist am host per usb 
verbunden. Kommuniziert per tcp (jlinkrrmotesrrver) über virtuellen 
lanport mit dem jlink in der vm. Aber es läuft.

Vielleicht hilft mir das morgen beim fehler suchen...

Obwohl mich die sache mit dem RX_EN noch beschäftigt... ich hab leiter 
kein referenzboard zum prüfen, wie rx en aussehen müsste.

[Holger K. (holgerkraehe)]

Interessanten Beitrag gefunden.

https://e2e.ti.com/support/legacy_forums/embedded/starterware/f/790/t/503745?Ethernet-frames-received-with-alignment-errors-between-AM335x-and-MICREL-KSZ8041#

Hier hat jemand mit genau dem gleichen PHY das genau gleiche Phänomen 
bzw. Signalbild wie ich.

Er kommt zur Vermutung, dass das RXEN Signal verschoben ist.
Warum, bleibt jedoch offen...

Aber vermutlich hat

St. D. schrieb:
> RX_EN sieht nicht gut aus! Es müsste durchgehend High sein bis Ende des
> Frames.

schon recht...

Die frage ist nun genau die gleiche wie bei dem Herrn oder der Dame von 
Ti. Warum...

[Dergute W. (derguteweka)]

Moin,

Hartnaeckige Sache das...OK, mit RMII hatt' ich auch noch nie ernsthaft 
zu tun. Aber mir kommts schon auch komisch vor, dass das RX_EN Signal 
jeweils am Ende des Pakets nicht eine sauber Flanke hat, sondern da auch 
noch irgendwas "gemorst" wird.
Auf den Bildern mit den Signalen wuerd' ich ansonsten sagen, dass das 
schon ein ARP sein koennte, allerdings und komischerweise mit 
Destination-MAC auf Broadcast (also 6x 0xFF). Das find' ich fuer eine 
Antwort auf einen ARP etwas eigenartig. Und dann auch noch gleich 2x 
hintereinander. Wenn da noch ein Switch zwischen PC und imx ist, wuerd' 
ich den mal rausnehmen - nicht, dass das nur irgendwelcher reflektierte 
Kram aus dem Switch ist und nicht das echte Antwortpaket des PCs auf die 
ARP Anfrage des imx6.

Aber prinzipiell sieht's schon nach einem Ethernetpaket aus. Irgenwelche 
RMII-Spezialitaeten vor dem Takteinlauf sind da (D0=0 und D1=0). 
Takteinlauf laesst sich erkennen (D0=1,D1=0), und eben die Broadcast-MAC 
(D0=1,D1=1); danach halt der Rest von irgendwas evtl. ARP-artigem, dann 
noch etwas Padding und am Schluss die FCS - wo dann schon der RX_EN so 
vor sich hinflubbert; Aber vielleicht gehoert das so, sind hier RMII 
Spezialisten anwesend?

PHY-IRQs hab' ich eigentlich noch nie fuer irgendwas gebraucht und auch 
in Designs eher selten gesehen. Das sollte auch ohne gehen, zumindest 
wenn's die Restsoftware unterstuetzt.

Gruss
WK

[Dergute W. (derguteweka)]

Moin,

Holger K. schrieb:
> Die frage ist nun genau die gleiche wie bei dem Herrn oder der Dame von
> Ti. Warum...

Beim Vladimir faellt ds RX_EN aber ohne "flubbern", nur anscheinend 
schon vor der Uebertragung der FCS. Bei dir flubberts auch noch. Dann 
vertief' dich mal in die Datenblaetter des PHYs, vielleicht gibts 
irgendeine Einstellung fuer das RX_EN Signal, die noch nicht passt.

Gruss
WK

[Holger K. (holgerkraehe)]

Dergute W. schrieb:
> Beim Vladimir faellt ds RX_EN aber ohne "flubbern", nur anscheinend
> schon vor der Uebertragung der FCS. Bei dir flubberts auch noch. Dann
> vertief' dich mal in die Datenblaetter des PHYs, vielleicht gibts
> irgendeine Einstellung fuer das RX_EN Signal, die noch nicht passt.
>
> Gruss
> WK

Danke, hab ich bereits gemacht.
Leider gibt es keinerlei Einstellmöglichkeitn für etwaige Delays oder 
sonstige Modalitäten. Das Datenblatt des KSZ8041 ist glücklicherweise 
sehr überschaubar gehalten :)

Evtl. ist es langsam an der Zeit, den PHY mal zu ersetzen.
Einfach um mal auf Nummer sicher zu gehen...

[Matt (Gast)]

Faszinierend dem Thread zu folgen! Um so blöder komme ich mir vor, aber 
was ist denn mit den üblichen Verdächtigen? Braucht RX_EN noch 
zusätzlich einen pull-up oder pull-down? Hat der Chip selbst ausreichen 
Pufferkondensatoren nach genug an den Stromzuleitungen? Manchmal sind es 
die trivialen Dinge...

[Holger K. (holgerkraehe)]

Matt schrieb:
> Faszinierend dem Thread zu folgen! Um so blöder komme ich mir vor,
> aber
> was ist denn mit den üblichen Verdächtigen? Braucht RX_EN noch
> zusätzlich einen pull-up oder pull-down? Hat der Chip selbst ausreichen
> Pufferkondensatoren nach genug an den Stromzuleitungen? Manchmal sind es
> die trivialen Dinge...

Vielen Dank für deinen Beitrag.
Warum denn blöder?

Freut mich, dass dir der Thread gefällt.
Liest sich vermutlich wie ein Krimi und jeder sucht den Bösewicht :)

Der Chip sitzt direkt neben den 3.3V. Hat inzwischen ca. 15uF Kapazität 
direkt an seinen Eingängen. Hab diese auch mal erhöht.

Ich glaube inzwischen, dass sich der Verdacht mit dem defekten Chip 
erhärtet.
Ich muss mich Mental mal darauf vorbereiten, zig Tage mit einem defekten 
Chip verbracht zu haben...

Positive dinge: ich kenne inzwischen den U-Boot SourceCode relativ gut.
Ich habe eine sehr genaue Vorstellung, wie U-Boot booten möchte, was da 
genau abläuft und verstehe die Einträge im Device-Tree. (mit ausnahme 
der Nummer 118 beim Interrupt im DTSI file)
Zudem konnte ich gestern sogar mit Eclipse durch den Code debuggen.

Ich ersetze den Chip KSZ8041 nun durch einen KSZ8081 welcher von einem 
Board kommt, von dem ich weiss, dass es funktioniert.

Die Chips sind glücklicherweise Pin-Kompatibel.
Auch das Strapin ist identisch.

[Holger K. (holgerkraehe)]

Ok. We're back in the Game...

MDIO geht wieder. Erkennt nun einen KSZ8081...

Aber... Empfangen von Paketen geht nach wie vor nicht.
Genau das gleiche Verhalten wie zuvor schon mit dem KSZ8041.

Von dem jetzt verbauten Chip bin ich mir aber sicher, dass er keinen 
Defekt hat.

Anbei ein MII Dump.
Loopback ist auch deaktiviert. Wie sich dies gehört.

Also nochmals alles zurück an den Anfang...


EDIT während dem Schreiben:

Oscilloskop an RX_EN gehalten... Dauernd high.
Lötstelle begutachtet: evtl mal nachlöten.

Und.... DHCP erfolgreich...

Meine lieben Freunde des Wahnsinns... Nach Tagen des Suchens nun endlich 
die Erlösung.

Ethernet läuft :)


Ich Danke allen, welche mich in diesem Prozess der Erkentnis begleitet 
haben. Ohne Euch hätte ich nicht durchgehalten...

[Matt (Gast)]

Juhuu. Also war der Mörder doch der Gärtner.

Danke für den schönen Krimi ;-D

[Holger K. (holgerkraehe)]

Matt schrieb:
> Juhuu. Also war der Mörder doch der Gärtner.
>
> Danke für den schönen Krimi ;-D

So siehts aus :)

Gerngeschehen... Mal sehen, wer als nächstes hinter der Hecke lauert ^^
Ein Herr Linus äh Linux ^^

[Holger K. (holgerkraehe)]

Letztes Update...

Ich hab mich noch um den Gärtner gekümmert...

[nfet (Gast)]

Manche verdienen es nicht anders. Kannst dir ja nochmal eine ganze Rolle 
bestellen und in Sittenhaft nehmen. Freut mich, dass du es geschafft 
hast. Auch mir hat der Thread Freude bereitet beim Lesen.

[Dergute W. (derguteweka)]

Moin,

Massl ghabd! Jetzt sollt' das mit einem Kernel mit im initramfs 
angeflanschter busybox auch nicht mehr voellig unmoeglich sein ;-)

Gruss
WK

[Holger K. (Gast)]

nfet schrieb:
> icht anders. Kannst dir ja nochmal eine ganze Rolle
> bestellen und in Sittenhaft nehmen. Freut mich, dass du es geschafft
> hast. Auch mir hat der Thread Freude bereitet beim Lesen.

Freut mich, dass du auch Freude hattest :)

Dergute W. schrieb:
> Moin,
>
> Massl ghabd! Jetzt sollt' das mit einem Kernel mit im initramfs
> angeflanschter busybox auch nicht mehr voellig unmoeglich sein ;-)
>
> Gruss
> WK

Das ist auf jedenfall das Ziel.
Hab mir mal Buildroot geklont und mit make menuconfig mal ein bisschen 
gespielt.

Aber ich glube dass ich zuerst noch mein Board dem Linux-Kernel bekannt 
machen muss. Folglich also Patches erstellen und diese dann buildroot 
mitteilen.

Ich habe so das gefühl, das gibt nochmals ein paar Tage arbeit.

Übrigens:
tftp funktioniert auch tadellos. Hab bisher nur noch nichts sinnvolles 
zum laden :)

[S. R. (svenska)]

Holger K. schrieb:
> Nun, ich habe nicht aktiv einen Interrupt gesetzt. Aber im DTSI File
> wird folgendes vorgegeben:
>       fec1: ethernet@02188000 {
>         compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
>         reg = <0x02188000 0x4000>;
>         interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
>                <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
>         ...
>       };
>
> Positive dinge: ich kenne inzwischen den U-Boot SourceCode relativ gut.
> Ich habe eine sehr genaue Vorstellung, wie U-Boot booten möchte, was da
> genau abläuft und verstehe die Einträge im Device-Tree. (mit ausnahme
> der Nummer 118 beim Interrupt im DTSI file)

Das ist die Interrupt- bzw. Pin-Nummer. :-)

> Muss ich den Interrupt evntuell noch manuell,
> selbst in meinem C-File aktivieren?

Nein. Wie gesagt, wenn der Devicetree ordentlich funktioniert, brauchst 
du eigentlich kein C-File. :-)

Holger K. schrieb:
> Lötstelle begutachtet: evtl mal nachlöten.
>
> Und.... DHCP erfolgreich...
> Ethernet läuft :)

Gratuliere. :-)

Also war es doch eines dieser blöden Dinge.

Ab jetzt wird's leichter. Devicetrees kennst du, und wenn du den 
U-Boot-Source kennst, wird's mit dem Kernel-Source auch nicht viel 
schwerer. :-D

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Kaum is man maln Tag weg gehts ;)
Das Flattern des DV ist erlaubt.
Denn das Signal ist ein "CRS_DV".
Also Carriersense und RX DataValid gemultiplext.
Es ist ja bekannt, dass bei RMII ein Nibble auf 2 Takte aufgeteilt wird, 
also kann man DV+CRS multiplexen um noch nen Pin zu sparen.

Wenn der PHY aber zur falschen Zeit kein carrier mehr erkennt ist da was 
kaputt.
Villeicht Irgendwo einen der Analog VCC Kerkos vergessen oder das Ferrit 
ist zu hochohmig?
Der 81 ist vllt nur etwas gutmütiger und irgendwann gibts dann wieder 
Aussetzer.

[Holger K. (Gast)]

Danke für deine Antwort.

Nach dem ich den 8041 runter hatte habe ich gesehen, dass dessen Pads 
arg korrodiert waren. Ich glaube das war einfach schlechte Ware...

Ich glaube ich benötige nun doch noch etwas Unterstützung beim Kernel...
Dazu mache ich aber einen neuen Thread auf.

[Holger K. (holgerkraehe)]

Um den Kreis zu schliessen... Und auch für die Nachwelt.
Hier der Link: Beitrag "Eigenes i.MX6 Board - U-Boot läuft. Wie weiter mit dem Kernel"