eFuses beim i.MX6 brennen

[Holger K. (holgerkraehe)]

Hallo zusammen

Einige haben es bestimmt bereits bemerkt.
Ich bastle an einem imx6 board.


Aktuell möchte ich gerne, dass das Board von der Speicherkarten an SD1 
bootet.

Da ich kein Straping der Bootconfig gemacht habe, habe ich nun die eFuse 
geschrieben. Aktuell nur BT_CFG1_6

Nun würde ich nach einem Reset eigentlich einen Takt bei der SD-Karte 
erwarten. Leider sehe ich dort allerdings keine Signale.

BOOT0 und BOOT1 sint beide über 10k gegen GND geschaltet.

Hat jemand schonmal ähnliches gehabt?

=> fuse prog 0 5 0x00000040
Programming bank 0 word 0x00000005 to 0x00000040...
Warning: Programming fuses is an irreversible operation!
         This may brick your system.
         Use this command only if you are sure of what you are doing!

Really perform this fuse programming? <y/N>
y
....
=> fuse sense 0 5
Sensing bank 0:

Word 0x00000005: 00000040

Danke

[Dirk M. (dirkm)]

Moin,

du brauchst zusätzlich
fuse prog -y 0 6 0x00000010

damit von den Fuse Einstellungen gebootet wird.

Gruß
Dirk

[Holger K. (Gast)]

Danke für die Antwort

Ist dann ein Zugriff mittels JTAG nachwievor möglich nehme ich mal an?

[Dirk M. (dirkm)]

Ja JTAG geht weiterhin. Ohne das BT_FUSE_
SEL Bit werden die Bootstrap Widerstände gelesen und Fuses ignoriert.

[Sven B. (scummos)]

JTAG sollte immer gehen außer du machst es per fuse aus. Trotzdem, wenn 
du mit den Fuses bastelst, solltest du ein, zwei Reserve-Boards haben ;)

[Holger K. (holgerkraehe)]

Hat funktioniert!

Danke

[Dirk M. (dirkm)]

Jetzt u-boot mit passender image.cfg / DCD bauen und mit Offset 0x400 
mit DD auf die SD Karte schreiben und schon sollte Booten klappen :)

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Jetzt u-boot mit passender image.cfg / DCD bauen und mit Offset
> 0x400
> mit DD auf die SD Karte schreiben und schon sollte Booten klappen :)

Danke für die Antwort.

imximage.cfg bzw. plugin.S hab ich bearbeitet.
bei imximage.cfg steht nun:

IMAGE_VERSION 2
BOOT_FROM  sd
PLUGIN  board/holger/eval/plugin.bin 0x00907000
DCD werte....

Die DCD Werte entsprechen jenen, welche ich immer mit dem JLINK geladen 
habe.
Sollten also korrekt sein. Ich hab diese ebenfalls im plugin.s zu dem 
Assemblerbefehlen hinzugefügt. Wobei ich mich gefragt habe, warum dies 
doppelt vorhanden ist.

Leider kriege ich u-boot nicht dazu, ein .imx zu erzeugen.

./tools/mkimage -n ./board/holger/eval/imximage.cfg -T imximage -e 0x00907000  -d u-boot.bin u-boot.imx

Gibt mir immer

Error: ./board/holger/eval/imximage.cfg[1] - Invalid command(/*)

Auch mit cfgs von anderen Boards.

Heisst dies nun, dass ich mit dem imx keinen SPL für u-boot brauche?
Konfiguriert der interne Bootloader das RAM anhand der DCD-Werte 
automatisch und lädt dann den gesamten U-Boot ins RAM?

[Dirk M. (dirkm)]

Genau mit DCD kannst du dir SPL sparen :) Mach ich immer so...

Der ROM Loader schaut zuerst nach einem Magic Byte im DCD Header, dann 
übernimmt der alle Werte in die Register und initialisiert damit den 
Ram. Danach läd er den Rest/U-Boot in den DRAM.

Meine Image.cfg sieht so aus:

#define __ASSEMBLY__
#include <config.h>

/* image version */

IMAGE_VERSION 2

/*
 * Boot Device : one of
 * spi/sd/nand/onenand, qspi/nor
 */

BOOT_FROM  sd

/*
 * Device Configuration Data (DCD)
 *
 * Each entry must have the format:
 * Addr-type           Address        Value
 *
 * where:
 *  Addr-type register length (1,2 or 4 bytes)
 *  Address    absolute address of the register
 *  value    value to be stored in the register
 */

DATA 4 0x020c4068 0xffffffff
......

[Dirk M. (dirkm)]

Achja nehm SPL aus deinem arch/arm/mach-imx/mx6/Kconfig Eintrag und der 
Board defconfig. Dann sollte U-Boot eigentlich automatisch eine .imx mit 
DCD bauen.

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Achja nehm SPL aus deinem arch/arm/mach-imx/mx6/Kconfig Eintrag
> und der
> Board defconfig. Dann sollte U-Boot eigentlich automatisch eine .imx mit
> DCD bauen.

Hab da in der Kconfig nichts von SPL drinnen.

config TARGET_EVAL1A
  bool "holgers eval"
  select BOARD_LATE_INIT
  select MX6ULL

Hab nun auch in meiner defconfig alle SPL relevanten Dinge entfernt.
Aber eine .imx Datei bekomme ich trozdem nicht...

Die andere Codezeile hab ich von hier:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/README.imximage?h=imx_v2017.03_4.9.88_2.0.0_ga

[Dirk M. (dirkm)]

Baust du mit buildroot oder u-boot seperat?

Hast du mal

make clean
make holger..._config
make

gemacht?

[Dirk M. (dirkm)]

Und hast du in einer Defconfig den Eintrag?

CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/holger/eval/imximage.cfg"

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Und hast du in einer Defconfig den
> Eintrag?CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/holger/eval/imximage. cfg"

Genau das wars... Danke.


Habs soeben auch rausgefunden :)
Nun hats mir ein imx file gegeben...

Also ab damit an Adresse 0x0400 der SD und hoffen, dass sich die Konsole 
meldet...

Kann ich eigentlich mit dd unter ubuntu ein windows taugliches 
"full-image" erstellen, wo dann u-boot und kernel sowie rootfs bereits 
an den richtigen positionen sin?

[Dirk M. (dirkm)]

Kann Buildroot das nicht? Verwende Yocto und das lässt sich so 
konfigurien dass am Ende ein fertiges All in one Image rauskommt :)

[Holger K. (holgerkraehe)]

Dirk M. schrieb:
> Kann Buildroot das nicht? Verwende Yocto und das lässt sich so
> konfigurien dass am Ende ein fertiges All in one Image rauskommt :)

Doch, vermutlich kann es das auch.
Habe eben bisher u-boot unabhängig von buildroot verwendet...

[DPA (Gast)]

Holger K. schrieb:
> Kann ich eigentlich mit dd unter ubuntu ein windows taugliches
> "full-image" erstellen, wo dann u-boot und kernel sowie rootfs bereits
> an den richtigen positionen sin?

Klar, es gibt viele möglichkeiten, das zu tun. Ich mache sowas bei den 
Librem 5 devkits (ist dort aber iMX8). Und ich verwende dazu ein paar 
eigene Tools, um kein Root zu benötigen (sind alle auf meinem 
github/gitlab profil). Eventuell hilft dir mein Script ja weiter:
https://github.com/Daniel-Abrecht/librem5-image-builder/blob/master/script/assemble_image.sh#L23
https://github.com/Daniel-Abrecht/librem5-image-builder

Wenn der gebrauch von root auch OK ist, kann man auch rein nur standard 
tools verwenden. (statt fuseloop losetup, statt writeTar2Ext mount und 
tar xf). Der ablauf wäre also ungefähr (ungetestet):

IMAGE=image.img

# Leeres/sparse image file anlegen
truncate -s 2GiB "$IMAGE"

# Partitionieren (muss vermutlich für iMX6 erst angepasst werden.)
sfdisk "$IMAGE" <<EOF
label: dos
unit: sectors
# Protective partition for Cortex M4 firmware and ARM trusted platform + uboot bootloader
start=4, size=2044, type=da
# /boot/ partition
start=2048, size=256MiB, type=83, name=boot, bootable
# / partition, use remaining space
type=83, name=root
EOF

# Loop devices anlegen
lodev="$(losetup -Pfr --show "$IMAGE")"
echo "$lodev"

# Uboot kopieren (muss eventuel erst noch für an iMX6 angepasst werden. Hier ist der absolute offset=1024*31+4*512=33792 (4*512 ist offset partition 0))
dd conv=notrunc,sync if=uboot.imx of="$bootloaderdev" bs=1024 seek=31

# Dateisystem anlegen
mkfs.ext2 "$lodev"p2
mkfs.ext4 "$lodev"p3

# mounten
mkdir rootfs
mount "$lodev"p2 rootfs
mkdir rootfs/boot
mount "$lodev"p3 rootfs/boot

# / und /boot  dateien anlegen
(
  cd rootfs
  # hier "tar xf rootfs.tar.gz" oder ein debootstrap oder was auch immer.
)

# Alles umounten und aufräumen
umount rootfs/boot
umount rootfs
rmdir rootfs
losetup -D "$lodev"

Bei mehreren Partitionen ist noch zu beachten, dass windows damit bei 
Wechseldatenträgern nicht klar kommt.

[DPA (Gast)]

Edit: "$bootloaderdev" sollte "$lodev"p1 sein

[Holger K. (holgerkraehe)]

Vielen Dank für die Antworten und auch für den Link auf dein Skript.
Sieht sehr vielversprechend aus.

Ich habe nun das image mittels cfimager-imx aus dem imx6 SDK auf eine 
Speicherkarte geschrieben.

cfimager-imx -a -offset 0x400 -f u-boot.imx -d D

vendor = Generic-
product = SD/MemoryStick
removable = yes
device block size = 512 bytes
device block count = 0xece000

firmware size = 0x6502c bytes (0x329 blocks)
extra blocks = 1238
Writing firmware...
writeFirmware from 400 or sector 2
Writing FAT partition...
Writing MBR...
setPartitionEntry m_blockCount = e9c000, m_startBlock = 32000, deviceBlockCount = ece000
done!

Der erste Versuch ging schief, da die Karte defekt war...

Karte eingelegt und die CLK Leitung beobachtet. Es clockt... Daten 
scheinen gelesen zu werden. Aber im UART-Terminal tut sich nichts...

Meine Vermutete Fehlerquelle:

- Adresskonfiguration irgendwo falsch?

Aktuell hab ich nach wie vor für u-boot in der defconfig:

CONFIG_SYS_TEXT_BASE=0x87800000

Dies ist die DRAM Adresse.

In der imximage.cfg steht

PLUGIN  board/holger/eval/plugin.bin 0x00907000

Dies ist die CGRAM Adresse.
Wenn ich das richtig verstanden habe, dann wird der assembler code 
dorthin kopiert, für die Initialisierung des Memorys.

Weitere Adressen hab ich nicht.

Bei den eFUSES hab ich die Busbreite aktuell noch auf 1-Bit.
Meine Karte wäre aber 4-Bittig angebunden.
Ich vermute mal, dass dies das ganze einfach langsamer macht oder?

EDIT

Ganz verkehrt kanns nicht laufen, da laut ReferencManual die Karte mit 
347.22kHz eröffnet wird und dann auf 25MHz gewechselt wird.

Genau dies, kann ich mit dem Oscilloscope auch sehen.

[Holger K. (holgerkraehe)]

Ok ich bin nun etwas weiter.

Nachdem ich nun die Zeile:

PLUGIN  board/holger/eval/plugin.bin 0x00907000

Aus meiner cfg entfernt habe und u-boot neu erstellt habe, das 
u-boot.imx auf die karte geladen habe passiert etwas mehr.

Ich habe zu Testzwecken im U-Boot code eine LED auf dem Board 
eingeschaltet.
Und zwar bei der PHY Config.

Diese LED geht nun an, wenn ich die Karte einlege und das Board speise.
Aber die Konsole bleibt unberührt.

Mit dem elf file, welches zusammen mit dem uboot.imx erstellt wurde, 
funktioniert nach wie vor alles (herunterladen mittels jlink, gdb 
etc...)

Also u-boot selbst sollte funktionieren.
Da die LED aufleuchtet, muss ja auch der Code ausgeführt werden.

Die Rgesiter für DDR3 müssen auch stimmen. da ich den initialisierungs 
code mittels Copy Paste übernommen habe und auch nochmals geprüft habe.

Irgendwie schon auffällig wie viele Klippen zu umschiffen sind :)

Vielleicht hat ja jemand eine gute Idee.

Danke

[Holger K. (holgerkraehe)]

Ich verstehs nicht...

Ich hab mich nun mal mit der SD-Karte gebootet und dann den J-Link 
connected.
Hab nun jedes einzelne Register, welches ich zuvor manuell konfiguriert 
habe ausgelesen... Offenbar verändern sich einige davon nach der 
initialen konfiguration.

Nun nochmals resetten, elf-file und gdb gestartet. Hier funktioniert ja 
die Konsole. Nun nochmals jlink anhalten und jedes Register auslesen.

Nun auf unterschiede prüfen. Und. Es gibt keine!
Die Register sind absolut identisch. Diejenigen, welche sich verändert 
haben, haben sich auch identisch verändert.

Selbst das UART Control Register 2 hat plausible Werte drin...
Es sieht alles so aus, als müsste etwas ausgegeben werden....

Ich verstehs nicht...

[Holger K. (holgerkraehe)]

So...

Hab einen Workaround gefunden.

Ich schreibe nun einfach ein paar Mal direkt in das UART1 TX 
ausgaberegister:

volatile uint32_t *UART1_TXD = (volatile uint32_t *)0x2020040;
...
*UART1_TXD = 'A';

Dies führt dazu, dass die Ausgabe auf der Konsole erst mit der Ausgabe 
des ersten, von mir gesendeten Zeichen, beginnt.

 BCDMMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
ENet:   FEC Waiting for PHY auto negotiation to complete...... done
AFEC
Warning: FEC (eth0) using random MAC address - 3e:4b:9d:89:8c:b6

=>

Warum dies so ist, ist noch gegenstand der Untersuchungen ;)
Ideen sind natürlich willkommen!

So, nun muss ich noch das File-System und den Kernel auf die Karte 
packen.

Hab die freie Partition mit ext2 formatiert.
Dort nun das rootfs aus buildroot entpackt.
Kann ich nun das zImage und mein dtb direkt dort ins hauptverzeichnis 
kopieren und dies so dem U-Boot mitgeben?

Danke!

[S. R. (svenska)]

Holger K. schrieb:
> Kann ich nun das zImage und mein dtb direkt dort ins
> hauptverzeichnis kopieren und dies so dem U-Boot mitgeben?

Klassisch würde man sowas nach /boot legen. Oder auf eine FAT-Partition, 
wie die meisten SBCs. U-Boot kann mit fatload oder ext2load auch Dateien 
von FAT oder ext2/ext4 lesen.

Ich bin ja an sich ein großer Freund von squashfs, aber das dafür 
braucht man dann definitiv eine separate Boot-Partition.