WD mycloud mirror debricken

[bucovaina89]

Hoi,

Ik heb van iemand een WD My Cloud Mirror geërfd. Deze had onder een lek gestaan en bootte sindsdien niet meer. De data heb ik van de schijven gekregen en de rest mocht ik houden. Adhv het model nummer ben ik niet 100% welke gen het is: WDBZVM0060JWT-20

Ik zou deze graag terug werkend krijgen, bij voorkeur met een Linux/Debian. Ik heb al wat liggen rond kijken maar veel vind ik niet.

• De NAS start op maar met 2 vol rode LED's, waarschijnlijk omdat ik een image erop heb gezet die niet compatibel is
• Ik krijg wel een inlogscherm (zelfs als ik de NAS zonder schijven start) maar geraak niet ingelogd met de default credentials
• debricken is blijkbaar alleen gedocumenteerd voor My Cloud. Niet voor My Cloud Mirror, of mijn google skills zijn niet goed genoeg

Heeft iemand misschien een link naar een tutorial van iemand die er succesvol Linux op heeft gekregen? Hier vind ik wel wat, maar alleen firmware files, kernel, initramfs files. Als je naar de info.txt files gaat kijken, gaat die uit dat de web gui nog werkt. (dat doet hij maar ik geraak er niet op)

[silverball]

Ik denk dat dit wel vrij specifieke kennis van dit apparaat vereist. Heb je al eens in de WD community (oid) gekeken ?

[bucovaina89]

Ja ik heb er maar een topic geplaatst want is idd vrij specifiek.

[Mijzelf]

Volgens deze thread is dat de originele, dus niet de gen2. Volgens deze site heeft dat ding een Armada 385 SoC. Dat is goed, die heeft vanilla Linux support.

Je zou eens kunnen kijken of de instructies voor de WD My Cloud EX2100 op doozan.com een werkende Debian installatie opleveren.

[bucovaina89]

Ik dacht dat het een armada 370 was. Voor zover ik me nu kan bedenken is het gewoon de juiste dts gebruiken en dan komt het wel goed. Ik ben sowieso ook nog op zoek naar hoe ik de UART pins moet aansluiten. Dat gaat uitsluitsel geven welke SoC het is.

Maar iig interesant leesvoer! Daar ga ik wel wat van kunnen gebruiken om verder te geraken.

[ Voor 31% gewijzigd door bucovaina89 op 26-12-2021 10:16 ]

[Mijzelf]

bucovaina89 schreef op zondag 26 december 2021 @ 10:12:
Ik dacht dat het een armada 370 was.

Dat artikel lijkt zichzelf tegen te speken. Ze hebben het over een dualcore 370 voor de EX2 en de Mirror, maar een 370 is bij mijn weten altijd singlecore.

[bucovaina89]

Idd. Maar maakt op zich niet zoveel uit, ik ga eerst uitzoeken hoe ik de UART moet aansluiten, dan weet ik het zeker.

Iig thanks voor de link!

[bucovaina89]

Ondertussen ben ik wat verder geraakt.

Ik ben ge chroot met qemu in een Debian rootfs en ben zo ver geraakt om een kernel met dts image te maken. Nu nog de ramdisk. Ik snap ergens iets niet goed. Op een of andere manier moet ik al een ramdisk hebben om er eentje te kunnen maken lijkt het mij. Kan iemand misschien even op weg zetten wat ik moet doen? Die -d switch is verplicht denk ik en er moet en geldig cpio archief aangegeven worden. Maar, ... dat probeer ik toch net te maken?! (confused)

code:

root@htpc:/usr/src/linux-stable# mkimage -A arm64 -O linux -T ramdisk -C gzip initramfs.uImage
/usr/bin/mkimage: Can't open (null): Bad address
root@htpc:/usr/src/linux-stable# mkimage -A arm64 -O linux -T ramdisk -C gzip -d uRamdisk.empty initramfs.uImage
/usr/bin/mkimage: Can't read uRamdisk.empty: Invalid argument
root@htpc:/usr/src/linux-stable#

[Mijzelf]

Met mkimage voorzie je een bestaand bestand van een 64 bytes uImage header, die nodig is om te zorgen dat u-boot de functie (en laadadres in geval van een kernel) van het bestand weet. Dat bestaande bestand maak je in dit geval met cpio.

[bucovaina89]

@Mijzelf: Dan lijkt mij dit op het eerste zicht wat ik wil bereiken:

(dit draai ik in een chrooted qemu arm environment)

code:

wget --no-check-certificate https://busybox.net/downloads/busybox-1.35.0.tar.bz2
tar xvf busybox-1.35.0.tar.bz2 && cd busybox-1.35.0
make defconfig
make && make install && cd _install/ && chmod +s bin/busybox
find . | cpio -ov > initramfs.cpio
<code>
cd ~/Documents/linux-stable/
mkimage -A arm -O linux -T ramdisk -C none -d initramfs.cpio initramfs.uImage

Moet /lib/modules ook mee in de initramdisk worden gestoken? Voor zover ik weet hangt een initramdisk vast aan de versie van kernel die je boot. Toch zo met x86.

[ Voor 4% gewijzigd door bucovaina89 op 27-12-2021 11:38 ]

[Mijzelf]

bucovaina89 schreef op maandag 27 december 2021 @ 11:33:
Moet /lib/modules ook mee in de initramdisk worden gestoken? Voor zover ik weet hangt een initramdisk vast aan de versie van kernel die je boot. Toch zo met x86.

Dat hangt ervan af. De functie van het initramfs is om de uiteindelijke rootfs te kunnen assemblen/mounten/whateveren, en als daar modules voor nodig zijn moeten die mee worden verpakt. In jouw geval dus waarschijnlijk niet, ik neem tenminste aan dat de ondersteuning van je sata poort en het gebruikte filesysteem van je rootfs in de kernel zijn ingebouwd. (En dan heb je in feite ook geen initramfs nodig. Het juiste rootfs opgeven in de kernel commandline is dan voldoende)
Mocht je kiezen om het rootfs op een raidarray te maken, dan moet je misschien de raid modules meenemen. (Ik denk dat een standaard Debian kernel die niet ingebouwd heeft).

[bucovaina89]

Goed punt,

Om de originele setup te behouden van de WD My Cloud Mirror moet je volgende doen om de structuur van de disks "vanilla" te houden:
[code]
mklabel gpt
mkpart primary 528M 2576M # rootfs part 1 raid
mkpart primary 2576M 4624M # rootfs part 2 raid
mkpart primary 16M 528M # swap
mkpart primary 4828M 100% # Big data partition (usable space for end user)
mkpart primary 4624M 4724M # main kernel
mkpart primary 4724M 4824M # Backup kernel
mkpart primary 4824M 4826M # Boot config for bootloader (Barebox - Uboot v2.0)
mkpart primary 4826M 4828M # Backup of previous partition (boot config)
set 1 raid on
set 2 raid on
[code]

Ik vermoed dan dat ik me beter concentreer op in de kernel mdadm in te bouwen en ervoor zorg dat de boot command line naar het rootfs gaat verwijzen. Ik vermoed dat als ik dan de kernel 'dd' naar de partitie 4624M-4724M en/of 4724M 4824M dat het wel moet lukken om te booten.

Ik ben er nog niet helemaal uit waarom het rootfs in 2 delen is opgesplitst en wat de laatste 2 partities doen (boot config) maar ik denk dat ik de rootfs en kernel ga nodig hebben.

Ondertussen is de postbode langs geweest met mijn

[Mijzelf]

Die rootfs is waarschijnlijk dubbel uitgevoerd om updates minder riskant te maken. Als je bent geboot van rootfs1, dat schrijf je een update naar rootfs2, en alleen als dat helemaal gelukt is, verander je iets in de bootloader, zodat de volgende boot het nieuwe rootfs pakt.
Over die laatste 2 partities, het zou kunnen dat een printenv in de u-boot prompt veel duidelijk maakt.

[bucovaina89]

@Mijzelf :

Om nog even terug te komen op wat posts eerder, meten is weten . Of m.a.w., de UART heb ik in orde gekregen

code:

root@WDMyCloudMirror / # cat /proc/cpuinfo
Processor       : Marvell PJ4Bv7 Processor rev 1 (v7l)
BogoMIPS        : 1196.85
Features        : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls 
CPU implementer : 0x56
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0x581
CPU revision    : 1

Hardware        : Marvell Armada-370
Revision        : 0000
Serial          : 0000000000000000
root@WDMyCloudMirror / #

[Mijzelf]

OK, dus een single core? Jammer. Had iedereen het mis.

[bucovaina89]

@Mijzelf: bwa maakt niet zoveel uit, een gegeven paard en zo. Ik ga hem toch niet voor number crunching gebruiken, backup nas en/of speelgoed NAS of zo

Mijn volgende vraag al direct, ik kan autoboot niet onderbreken. Press any key zegt hij, maar het lijkt wel alsof hij het niet registreert. Zowel fysiek aan het toetsenbord met een screen als over SSH niet. Er gaat wel een LED-je branden op de seriële controller, dus hij registreert wel degelijk signalen op TX naar de NAS.

Hoe kan ik dit omzeilen?

[Mijzelf]

Je serieel is n81, neem ik aan? Een verkeerde parity kan dit effect hebben.
Je zou het zonder schijf kunnen proberen, dan kan hij in ieder geval niet booten, en zal terugvallen op de prompt.

[bucovaina89]

N81? Geen idee

Het rare is dat hij zonder schijf ook gewoon boot. Ik dacht dan van de NAND of zo?

Het lijkt wel alsof hij tijdens "early boot stages" geen keyboard driver heeft of zo. Tijdens een shutdown hebben mijn toetsaanslagen vanaf een bepaald moment geen effect meer. Hetzelfde tijdens het booten, in het begin doet geen enkele toets iets.

Kan dat ook door een parity komen? Als ik de WD-community forums mag geloven, is het gewoon voor de seriele connectie baud rate 115200, al de rest default.

[Thralas]

bucovaina89 schreef op maandag 27 december 2021 @ 17:52:
N81? Geen idee

8n1 - 8 data bits, no parity, 1 stop bit. De gouden standaard voor uarts.

Het rare is dat hij zonder schijf ook gewoon boot. Ik dacht dan van de NAND of zo?

Natuurlijk. Anders werkt hij niet als je er twee lege schijven in duwt.

Het lijkt wel alsof hij tijdens "early boot stages" geen keyboard driver heeft of zo.

Voor de goede orde: je apparaat heeft geen weet van een 'keyboard'. Je hebt een uart, en that's it. De output krijg je bij gratie van iets dat je uart uitleest en besluit input te echoen.

(Eerder schreef je het eea. over SSH dat ik ook niet helemaal kon plaatsen).

Kan dat ook door een parity komen? Als ik de WD-community forums mag geloven, is het gewoon voor de seriele connectie baud rate 115200, al de rest default.

Als je uart onder Linux werkt, dan werkt je tx-lijntje blijkbaar. Als je uart output geeft onder u-boot dan klopt de baud rate ook. Ik denk dat het hardwarematig allemaal werkt.

Welke output krijg je van u-boot? Als het meezit print hij namelijk ook of z'n stdin/stdout inderdaad aan serial hangen (die laatste sowieso, anders zou je 'm niet zien).

Waar ik me meer zorgen om maak: niet te zuinig zijn met input geven - gewoon een toets (enter, spatie) ingedrukt houden.

[bucovaina89]

Tijdens het booten moet je alterneren tussen 1 en [spatie] drukken en dan krijg ik een Marvell>> U-boot prompt.

Logisch toch? /s

[bucovaina89]

Vooreerst iedereen al dank aan wie me mee op weg heeft gezet!

Ondertussen ben ik zo ver geraakt om hem met een RAID te laten booten. Dat was nog even zoeken want de raid-md-auto-discover van de NAS werkte tijdens het booten niet met de linux RAID op die schijven (aangemaakt in mijn x86 computer) dus de kernel kon het rootfs niet mounten en weer kernel panic. Uiteindelijk erop gekomen dat de U-boot geen nieuwere RAID kent dan v0.9 dus het moet echt een v0.9 zijn en niet de default v.1.20 die met mdadm in Debian 11 wordt aangemaakt. Verder werkt het hele OS nu zoals je zou kunnen verwachten.

Wat nog op de to-do staat:

• Uitzoeken hoe ik de bootargs en bootcmd nog permanent kan maken, dat ik niet telkens hoef in te grijpen tijdens het booten.
• Mijn documentatie verder bijschaven zodat ik niet nog eens een week nodig heb om hem te herinstalleren mocht dat ooit nodig zijn. Naar't schijnt ben ik ook nog papa in bijberoep en mijn vrouw vindt het stilaan ook niet heel leuk meer dat ik nog altijd met de NAS bezig ben .
• U-boot zelf eens een update geven (Als ik wat meer durf heb, misschien ) . Het zou fijn zijn mocht die wel een v1.20 Linux RAID natively willen booten, maar goed, nice to have plus het een risico dat ik hem grondiger brick mocht het mis gaan dus dat ga ik nog bezien.
• Ik bedacht me dat die seriële kabel wel de opportuniteit geeft om mijn backup opstelling een pak veiliger te maken. Nu zou ik haast alles van buitenaf kunnen blokkeren met de firewall, ik kan er toch gemakkelijk met de seriële kabel op. Misschien zodanig instellen dat de NAS een backup neemt als hij geboot is. Als de backup klaar is een mailtje uitsturen en dan terug poweroff.

Maar goed ik sta al ver vind ik, voor de moment staat hij al een full backup te nemen. Het is ondertussen wel duidelijk dat de CPU geen snelheidsmonster is. Er draait niets anders dan een rsync file transfer nu aan ~15MB/s. Dat gaat een dikke 4 dagen duren

[Mijzelf]

bucovaina89 schreef op dinsdag 28 december 2021 @ 21:24:
Ondertussen ben ik zo ver geraakt om hem met een RAID te laten booten. Dat was nog even zoeken want de raid-md-auto-discover van de NAS werkte tijdens het booten niet met de linux RAID op die schijven (aangemaakt in mijn x86 computer) dus de kernel kon het rootfs niet mounten en weer kernel panic. Uiteindelijk erop gekomen dat de U-boot geen nieuwere RAID kent dan v0.9 dus het moet echt een v0.9 zijn en niet de default v.1.20 die met mdadm in Debian 11 wordt aangemaakt.

Het ligt wat subtieler, denk ik. u-boot ondersteund helemaal geen raid, maar bij een 0.9 array staat de header achteraan in de partitie, en kun je een losse partitie van een raid1 array dus gewoon mounten, zonder extra overhead. De kernel zelf ondersteund inderdaad autoassembly van v0.9 arrays (sinds 2.6.9) Daar is al heel lang niets meer aan veranderd, misschien omdat het met het populair worden van een initramfs overbodig werd.
De gebruikelijke manier is tegenwoordig om een simpele kleine partitie te hebben met daarop de kernel en het initramfs, die door de bootloader gelezen kan worden. De initramfs assembleert vervolgens het rootfs, doet een switch_root, en uiteindelijk wordt die bootpartitie gemount op /boot (per conventie. Voor het geboote systeem is die directory overbodig, maar voor kernel updates is het handig). Aangezien je die initramfs zowiezo nodig hebt om bijvoorbeeld een encrypted rootfs te kunnen mounten, waarom zou je dan extra bloat aan de kernel toevoegen om allerlei vormen van rootfs te kunnen assembleren/mounten/...

Maar goed ik sta al ver vind ik, voor de moment staat hij al een full backup te nemen. Het is ondertussen wel duidelijk dat de CPU geen snelheidsmonster is. Er draait niets anders dan een rsync file transfer nu aan ~15MB/s.

Wat verbuikt al die tijd dan? Ik heb hier een Armada 370 in een Netgear RN104 zitten. en die zit bij 15MB/sec niet op 70% system time. Bij een remote backup over SSH is SSH de beperkende factor, maar dat is usertime, en bij een 'plat' netwerk zit hij heel wat hoger dan 15MB/sec.

Uitzoeken hoe ik de bootargs en bootcmd nog permanent kan maken, dat ik niet telkens hoef in te grijpen tijdens het booten.

Werkt saveenv niet?

[bucovaina89]

Mijzelf schreef op woensdag 29 december 2021 @ 10:55:

Wat verbuikt al die tijd dan?

Werkt saveenv niet?

1) rsync. Niets anders. Dat wordt "aangestuurd" vanaf de Synology NAS. Ik heb met Hyper Backup een remote rsync-compatibel backup target ingesteld.

2) saveenv: waarschijnlijk wel, maar ik durf niet goed. Ik ben wat dieper aan het graven en ga proberen de NAND te overschrijven maar loop vast omdat de kernel de NAND niet kan vinden.

code:

root@mcm:/sys/devices# dmesg | grep -i nand
[    2.694272] marvell-nfc soc:internal-regs:nand@d0000: invalid resource
[    2.699538] marvell-nfc: probe of soc:internal-regs:nand@d0000 failed with error -22

Er is blijkbaar vanaf 4.16.1 een nieuwere driver geïntroduceerd die deze bug kan veroorzaken. Dus ik ben nu een linux-4.14.260 aan het compileren en zien of ik dan wel aan de NAND kan. Indien ja ga ik daar wat mee morrelen want ik heb vanmorgen een SMS van de vorige eigenaar gehad of ik met de NAS aan het spelen was, hij kreeg constant berichten dat er een stroompanne was op zijn WD NAS. Dat ding phonet dus vanaf de NAND al home... . Let's change that

[Morzzz]

Ik hou van dit soort embedded Linux projectjes.

Does it run Doom?

[bucovaina89]

YAY!!!

code:

root@mcm:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"
root@mcm:~# uname -r                                     
4.14.260
root@mcm:~#

Het werkte dus met de LTS 4.14.260 kernel en dus niet met 5.16rc7 (of alles nieuwer dan 4.16.1). Exact dezelfde config buiten dan de onderste lijn. Die is vanaf 4.16.1 vervangen door CONFIG_MTD_NAND_MARVELL omdat CONFIG_MTD_NAND_PXA3xx eruit gezwierd is. Helaas werkt CONFIG_MTD_NAND_MARVELL om een of andere reden niet deftig.

code:

CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_PXA3xx=y

Het volgende op de to do lijst:

• Backup maken van de huidige NAND
• Uitzoeken hoe ik die backup terug kan zetten if bricked
• Uitzoeken hoe ik de uImage er mooi op krijg
• Uitzoeken hoe ik een uRamdisk kan maken en die erop krijgen

Dus hoe back ik de nand up? Volgens deze link hangt het er vanaf hoe de NAND gebruikt wordt. Staat er een filesystem op? (Ik zag toch iets van UBIFS passeren bij eerdere boots van de NAND, dus ik denk van wel). Of met nanddump of met dd als het NOR flash is.

Maar goed, hoe kan ik weten welke van de 3 het is buiten gokken?

EDIT:

code:

root@htpc:/# for i in $(ls); do file $i; done
mtd0-pxa3xx_nand-0.dmp: data
mtd1-u-Boot.dmp: data
mtd2-uImage.dmp: u-boot legacy uImage, Linux-3.2.40, Linux/ARM, OS Kernel Image (Not compressed), 3115296 bytes, Fri Nov 16 04:28:51 2018, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0xF19C9979, Data CRC: 0xEB3D3986
mtd3-ramdisk.dmp: u-boot legacy uImage, Ramdisk, Linux/ARM, RAMDisk Image (gzip), 2104783 bytes, Thu Dec 20 07:27:48 2018, Load Address: 0x00E00000, Entry Point: 0x00E00000, Header CRC: 0x7A5DCD6A, Data CRC: 0x627ACF8E
mtd4-image.cfs.dmp: data
mtd5-rescue-firmware.dmp: data
mtd6-config.dmp: UBI image, version 1
mtd7-reserve.dmp: UBI image, version 1
nanddump-all-partitions-wd-mcm-gen1.bz2: XZ compressed data
root@htpc:/mnt/ruimteschip/Zandbak/nanddump-backups-wd-mcm-gen1#

Vangnet getest en goedgekeurd. Ik kan de WD mcm booten vanaf de seriële kabel als ik hem de image geef die ik van /dev/mtd2 (U-boot) af haalde

code:

kwboot -t -B 115200 /dev/ttyUSB0 -b mtd2-uImage.dmp -p

Nu kan ik dus beginnen nadenken hoe ik een nieuwere U-boot ga compileren.

[ Voor 26% gewijzigd door bucovaina89 op 29-12-2021 22:52 ]

[Mijzelf]

bucovaina89 schreef op woensdag 29 december 2021 @ 20:08:
Vangnet getest en goedgekeurd. Ik kan de WD mcm booten vanaf de seriële kabel als ik hem de image geef die ik van /dev/mtd2 (U-boot) af haalde

code:

kwboot -t -B 115200 /dev/ttyUSB0 -b mtd2-uImage.dmp -p

Nu kan ik dus beginnen nadenken hoe ik een nieuwere U-boot ga compileren.

Hier klopt iets niet. Kwboot haakt aan op een lowlevel protocol in een Marvel SoC, die een communicatie kanaal opent vóór de nand wordt geïnitialiseerd/gelezen. Die kun je dus gebruiken om bijvoorbeeld een bootloader te uploaden als die in je nand beschadigd is. Je upload een file, die in het geheugen wordt geladen, en als de upload stopt doet de SoC een jump naar het start adres.
Maar. Gezien de naamgeving heb jij een uImage geupload. Daar zou de SoC kant van kwboot niets mee moeten kunnen, aangezien het begint met een uImage header. En als je wel u-boot hebt geupload zou dat bij mijn weten ook niet werken, omdat hij door kwboot een ander geheugenadres is geladen dan door bootrom zou gebeuren.
Bij het booten zet u-boot wat tekst op het scherm. Die tekst kun je terugvinden in de nand-dump. Ik raad je aan om met een hex editor wat van die tekst aan te passen, zodat je kunt zien of hij de kwboot geuploade u-boot start, of toch de versie in nand.

[bucovaina89]

Goed gezien!

Bedankt voor jouw tijd om naar het topic te kijken!

Begrijp ik het goed?: In die image steekt inderdaad gewoon een Linux kernel. Ik geef dus een Linux kernel aan, de SoC verwacht een boot loader en kan dan ook niets met de blob die ik aanlever. Ik zie dat hij OK boot maar had niet door dat er eigenlijk eerst iets gefaald was wat "transparant" werd opgevangen door iets op het bordje dat terug gevallen is naar default boot.

Ondertussen heb ik een backup genomen van alle NAND partities en heb ik de uImage-4.14-nand die wel van TFTP boot over /dev/mtb2 geflasht. In principe zou die nu dus by default een 4.14 moeten booten maar hij blijft ondanks onderstaande toch liunux-3.2 booten en ik zie niet waaom. De syntax en addresseringen zijn me echt nog niet duidelijk.

Om de nieuwe geflashte kernel te booten type ik dit in u-boot:

code:

setenv bootargs 'root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect'
setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000'

Het oorspronkelijke (stock) bootcmd was dit, dat heb ik wat aangepast omdat ik geen uRamdisk gebruik. Goed mogelijk dat ik ergens een fout maakte want 100% snap ik het niet. Ik ga er maar vanuit dat na de ; de uRamdisk wordt ingelezen, dus dat heb ik er tussenuit gelaten.

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000'

En toch laadt hij de rescue firmware. Hoe kan dat? De uImage werkt gewoon met TFTP. Doe ik iets mis met de bootcmd? Of is iets met de flash procedure toch niet 100% gelopen?

code:

## Booting image at 02000000 ...
### Loading Rescure Firmware ###

NAND read: device 0 offset 0xdd00800, size 0xa00000
 10485760 bytes read: OK
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   Linux-3.2.40
   Created:      2014-07-29  10:09:53 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3102352 Bytes = 3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...
...
...
...
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)

Flash procedure, geen errors gezien:

code:

dd if=uImage-4.14-nand of=uImage-nand-enabled.kwb bs=5120k conv=sync # if=image die wel van TFTP boot.
root@mcm:~# ls -lah tftp/uImage-nand-enabled.kwb 
-rwxrwxrwx 1 1024 users 5.0M Dec 30 07:37 tftp/uImage-nand-enabled.kwb
flash_erase /dev/mtd2 0 0
nandwrite  /dev/mtd2 tftp/uImage-nand-enabled.kwb

of in combinatie met iets anders in de huidige env:

code:

CASset=min
MALLOC_len=5
autoload=no
baudrate=115200
bootargs=root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect
bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=dhcp; tftp 0x02000000 10.10.10.10:uImage-4.14-nand; bootm
bootdelay=1
cacheShare=no
console=console=ttyS0,115200
disL2Cache=yes
disaMvPnp=no
dnsip=10.10.10.10
eeeEnable=no
enaAutoRecovery=yes
enaClockGating=no
enaFPU=no
enaWrAllo=no
eth1addr=00:50:43:02:00:00
eth1mtu=1500
ethact=egiga1
ethaddr=00:50:43:02:02:00
ethmtu=1500
ethprime=egiga0
fileaddr=2000000
filesize=37CEB6
gatewayip=10.10.10.1
image_name=uImage
initrd_name=uInitrd
ipaddr=10.10.10.145
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:4m(boot),-(rootfs)
mvNetConfig=mv_net_config=1,(00:50:43:11:11:11,0:1:2:3:4),mtu=1500
mv_pon_addr=00:50:43:00:00:02
nandEcc=1bit
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=rc
pxe_files_load=:default.arm-armada370-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
rcvrip=169.254.100.100
rootpath=/srv/oneiric
sata_delay_reset=0
sata_dma_mode=yes
serverip=10.10.10.10
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usb1Mode=host
usb2Mode=device
usbActive=1
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Als ik dan exact dezelfde uImage wil booten van TFTP, gaat het zo wel:

code:

dhcp
setenv serverip 10.10.10.10
tftp ${loadaddr} uImage
setenv bootargs 'root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect'
set bootcmd "dhcp; tftp ${loadaddr} ${serverip}:uImage; bootm"

[Thralas]

bucovaina89 schreef op woensdag 29 december 2021 @ 15:38:
Ik ben wat dieper aan het graven en ga proberen de NAND te overschrijven maar loop vast omdat de kernel de NAND niet kan vinden.

code:

root@mcm:/sys/devices# dmesg | grep -i nand
[    2.694272] marvell-nfc soc:internal-regs:nand@d0000: invalid resource
[    2.699538] marvell-nfc: probe of soc:internal-regs:nand@d0000 failed with error -22

Er is blijkbaar vanaf 4.16.1 een nieuwere driver geïntroduceerd die deze bug kan veroorzaken.

Je hebt wat nutige info er hier mogelijk uitgegrept. Laat eens iets meer context zien, en de device tree (of tenminste de nand@d0000 node?

bucovaina89 schreef op woensdag 29 december 2021 @ 20:08:
Dus hoe back ik de nand up?

Er is maar één antwoord voor een volledige backup: nanddump.

• Controleer of het hele NAND gemapt is onder Linux. Dat hoeft niet zo te zijn namelijk. In jouw geval heb je een mtd0 met de naam van de NAND device: dat suggereert dat dit een device is dat de hele NAND beslaat. Merk op: de andere devices zijn individuele partities, maar die vallen dan dus binnen mtd0.
  
  Je kunt de size terugvinden in de kernel logs of u-boot logging. Kijk of dat klopt met de 256 MB van mtd0. Nog veel beter: datasheet opzoeken zodat je het helemaal zeker weet. Reken uit: (page_size + oob_size) * num_pages - dat is exact hoe groot je dump zou moeten zijn, geen byte minder.
• Daarna: gebruik nanddump voor een backup van mtd0. Lees goed de help, afhankelijk van of je de versie van mtd-utils of busybox hebt verschillen de defaults mbt. het dumpen van OOB data. Je wilt OOB data meenemen. Controleer of de size klopt met wat je eerder uitgerekend had.
• Als laatste kun je individuele partities dumpen (al dan niet zonder oob data) zodat je ze niet hoeft te extraheren uit de grote dump.

Waarom is het nuttig om altijd een volledige dump te maken? Dan vind je jezelf tenminste niet terug in de situatie waarin je dacht een backup te hebben, maar de bootloader ontbreekt, of de OOB bytes werden gebruikt voor een ECC scheme dat je zo 123 niet kan reproduceren..

---

En toch laadt hij de rescue firmware. Hoe kan dat? De uImage werkt gewoon met TFTP. Doe ik iets mis met de bootcmd?

Je laat niet zien hoe je boot. Laat eens de hele u-boot-sessie zien, en voer bootm eens handmatig uit zodat je zeker weet wat hij uiteindelijk boot.

Of is iets met de flash procedure toch niet 100% gelopen?

Zou zomaar kunnen. Eerst even handmatig booten volgens bovenstaande, maar als het dan nog niet werkt:

• Wat is de help van read.e? Dan lijkt me een Marvell'ism, maar logisch zou zijn een read met ECC check

Indien het inderdaad een ECC read is: dat is dus exact m'n punt hierboven omtrent OOB data; soms is is dat opeens heel relevant, bijvoorbeeld als er ECC data in staat.

In dat geval is het nandwrite commando as-is mogelijk niet genoeg: controleren of dat wel ECC wegschrijft. Default zou zo eens kunnen zijn dat 'ie dat niet doet.

Ter test: in u-boot readen zonder ECC kan vast ook wel.

[Mijzelf]

bucovaina89 schreef op donderdag 30 december 2021 @ 11:59:
Begrijp ik het goed?: In die image steekt inderdaad gewoon een Linux kernel. Ik geef dus een Linux kernel aan, de SoC verwacht een boot loader en kan dan ook niets met de blob die ik aanlever. Ik zie dat hij OK boot maar had niet door dat er eigenlijk eerst iets gefaald was wat "transparant" werd opgevangen door iets op het bordje dat terug gevallen is naar default boot.

Correct.

Als ik dan exact dezelfde uImage wil booten van TFTP, gaat het zo wel:

code:

dhcp
setenv serverip 10.10.10.10
tftp ${loadaddr} uImage
setenv bootargs 'root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect'
set bootcmd "dhcp; tftp ${loadaddr} ${serverip}:uImage; bootm"

Dit voer je iedere keer in als je van tftp boot? Wat krijg je dan als je

code:

nand read.e 0xa00000 0x500000 0x500000
bootm 0xa00000

doet? Achtergrond: Jij schrijft dat je 'setenv bootcmd '...' ' doet, maar niet of je daarna ook een saveenv doet. Zonder dat is de bootcmd alleen in ram aangepast en overleeft hij geen reboot.

[bucovaina89]

@Mijzelf : een savenv heb ik gedaan maar hij boot nog altijd niet netjes vanaf TFTP. Wel als ik manueel de commando's ingeef.

Dit werkt:

code:

nand read.e 0xa00000 0x500000 0x500000
bootm 0xa00000

Dit werkt niet:

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000'
boot 0xa00000

Ik denk dat ik de U-boot syntax/logica nog niet helemaal begrijp.

[bucovaina89]

@Thralas : thanks voor de input, dat moet ik ff 3x doorlezen

iig hier al iets meer context:

code:

[    2.711299] pxa3xx-nand f10d0000.nand: This platform can't do DMA on this device
[    2.718288] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xda
[    2.723365] nand: Hynix H27U2G8F2CTR-BC
[    2.725956] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    2.732257] pxa3xx-nand f10d0000.nand: ECC strength 16, ECC step size 2048
[    2.738298] Bad block table found at page 131008, version 0x01
[    2.743356] Bad block table found at page 130944, version 0x01
[    2.748196] nand_read_bbt: bad block at 0x000005a60000
[    2.752100] 7 ofpart partitions found on MTD device pxa3xx_nand-0
[    2.759334] ftl_cs: FTL header not found.
[    2.762558] Creating 7 MTD partitions on "pxa3xx_nand-0":
[    2.766721] 0x000000000000-0x000000500000 : "u-Boot"
[    2.772947] ftl_cs: FTL header not found.
[    2.776208] 0x000000500000-0x000000a00000 : "uImage"
[    2.782366] ftl_cs: FTL header not found.
[    2.785609] 0x000000a00000-0x000000f00000 : "ramdisk"
[    2.791941] ftl_cs: FTL header not found.
[    2.795128] 0x000000f00000-0x00000d800000 : "image.cfs"
[    2.802362] ftl_cs: FTL header not found.
[    2.805625] 0x00000dd00000-0x00000ec00000 : "rescue firmware"
[    2.812682] ftl_cs: FTL header not found.
[    2.815983] 0x00000ec00000-0x000010000000 : "config"
[    2.821703] random: fast init done
[    2.824145] ftl_cs: FTL header not found.
[    2.827457] 0x00000d800000-0x00000dd00000 : "reserve"
[    2.833720] ftl_cs: FTL header not found.

Zo heb ik de nand backup gedaan:

code:

root@mcm:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"
root@mcm:~# nanddump --file /root/nanddump-backups/mtd0-pxa3xx_nand-0.dmp /dev/mtd0
ECC failed: 0
ECC corrected: 7
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x10000000...
ECC: 1 corrected bitflip(s) at offset 0x03671800
ECC: 1 corrected bitflip(s) at offset 0x0dd8c800
root@mcm:~# nanddump --file /root/nanddump-backups/mtd1-u-Boot.dmp /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@mcm:~# nanddump --file /root/nanddump-backups/mtd2-uImage.dmp /dev/mtd2
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@mcm:~# nanddump --file /root/nanddump-backups/mtd3-ramdisk.dmp /dev/mtd3
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@mcm:~# nanddump --file /root/nanddump-backups/mtd4-image.cfs.dmp /dev/mtd4
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x0c900000...
ECC: 1 corrected bitflip(s) at offset 0x02771800
root@mcm:~# nanddump --file /root/nanddump-backups/mtd5-rescue-firmware.dmp /dev/mtd5 
ECC failed: 0
ECC corrected: 1
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00f00000...
ECC: 1 corrected bitflip(s) at offset 0x0008c800
root@mcm:~# nanddump --file /root/nanddump-backups/mtd6-config.dmp /dev/mtd6
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 8
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x01400000...
root@mcm:~# nanddump --file /root/nanddump-backups/mtd7-reserve.dmp /dev/mtd7
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
admin@admins-MacBook-Pro ~ %

[Mijzelf]

bucovaina89 schreef op donderdag 30 december 2021 @ 13:18:
Dit werkt:

code:

nand read.e 0xa00000 0x500000 0x500000
bootm 0xa00000

Dit werkt niet:

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000'
boot 0xa00000

Uit de manual:

The bootd (short: boot) executes the default boot command, i. e. what happens when you don't interrupt the initial countdown. This is a synonym for the run bootcmd command.

'boot' heeft geen parameter. Helpt het als je die weglaat? Voor zover ik kan zien zou

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000'
boot

moeten werken, gezien het voorbeeld bij 'run'.

[bucovaina89]

Dit werkt nu wel , ook na een reboot zonder tussenkomst:

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000'
saveenv
boot

[bucovaina89]

Wacht eens even ... ? Nu ik terug een werkende config, heb, mijn euro valt net dat ik geen werkende rescue firmware meer heb (zie onderstaande).

Kan ik nu niet een backup kernel en rootfs op mtd4 (busybox, ~200MB grote partitie) in nand maken zodat hij toch nog kan booten als het nodig is - desnoods zonder schijven.

Ik weet niet net hoe het werkt want de backup firmware partitie is 15MB groot, dus dat komt niet overeen met 5.00MB.

code:

root@mcm:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"
root@mcm:~#

code:

## Booting image at 02000000 ...
### Loading Rescure Firmware ###

NAND read: device 0 offset 0xdd00800, size 0xa00000
 10485760 bytes read: OK
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   Linux-3.2.40
   Created:      2014-07-29  10:09:53 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3102352 Bytes = 3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...
...
...
...
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)

code:

root@mcm:/mnt/ruimteschip/Documents/nanddump-backups-wd-mcm-gen1# ls -lah
total 730M
drwxrwxrwx 1 1024 users  360 Dec 29 20:54 .
drwxrwxrwx 1 root root   636 Dec 29 22:49 ..
-rw------- 1 1024 users 255M Dec 29 20:51 mtd0-pxa3xx_nand-0.dmp
-rw------- 1 1024 users 5.0M Dec 29 20:51 mtd1-u-Boot.dmp
-rw------- 1 1024 users 5.0M Dec 29 20:51 mtd2-uImage.dmp
-rw------- 1 1024 users 5.0M Dec 29 20:51 mtd3-ramdisk.dmp
-rw------- 1 1024 users 201M Dec 29 20:51 mtd4-image.cfs.dmp
-rw------- 1 1024 users  15M Dec 29 20:51 mtd5-rescue-firmware.dmp
-rw------- 1 1024 users  19M Dec 29 20:52 mtd6-config.dmp
-rw------- 1 1024 users 5.0M Dec 29 20:52 mtd7-reserve.dmp
-rwxrwxrwx 1 1024 users 220M Dec 29 20:55 nanddump-all-partitions-wd-mcm-gen1.bz2
root@mcm:/mnt/ruimteschip/Documents/nanddump-backups-wd-mcm-gen1#

[bucovaina89]

En begrijp ik dat goed:
lees de nand op 0x500000 voor 0x500000 bytes (5MB) en schrijf dat in RAM naar adres 0xa00000. Boot daarna van locatie 0xa00000 in RAM.

code:

nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000

En wacht, het wordt zowaar helder in mijn hoofd:

code:

setenv bootcmd 'nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000'

code:

root@mcm:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"
root@mcm:~#

Want 00500000 + 00500000 = 0xa00000 en laat dat toevallig net overeen komen met het adres van ramdisk". Dus het allerlaatste bootcmd gaat 2 images lezen van mtd2 en mtd3 en die booten.

Klopt wat ik zeg?

[ Voor 61% gewijzigd door bucovaina89 op 30-12-2021 15:20 ]

[Mijzelf]

bucovaina89 schreef op donderdag 30 december 2021 @ 14:30:
Want 00500000 + 00500000 = 0xa00000 en laat dat toevallig net overeen komen met het adres van ramdisk". Dus het allerlaatste bootcmd gaat 2 images lezen van mtd2 en mtd3 en die booten.

Klopt wat ik zeg?

Ja.

Ik *denk* dat de de rescue firmware stiekum gewoon de inhoud van de geconfigureerde schijven bevat(te), en dat de stock initramfs voldoende oemph heeft om die te installeren op een lege schijf.
Waarom en hoe u-boot meldt dat hij die gaat laden is me onduidelijk.
Je zou eens binwalk kunnen loslaten op die rescue firmware partitie. Hij zou zomaar een tarfile kunnen bevatten. Een binwalk op de initramfs kan natuurlijk ook geen kwaad.

[bucovaina89]

damn you're good :d

code:

root@mcm:/nanddump-backups-wd-mcm-gen1# binwalk mtd5-rescue-firmware.dmp 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
2048          0x800           uImage header, header size: 64 bytes, header CRC: 0x65699C4B, created: 2014-07-29 10:09:53, image size: 3102352 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0xE354357, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.2.40"
2112          0x840           Linux kernel ARM boot executable zImage (little-endian)
19047         0x4A67          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
3147776       0x300800        uImage header, header size: 64 bytes, header CRC: 0x39DE1E29, created: 2014-10-29 05:10:00, image size: 2059761 bytes, Data Address: 0xE00000, Entry Point: 0xE00000, data CRC: 0xEFAB01D1, OS: Linux, CPU: ARM, image type: RAMDisk Image, compression type: gzip, image name: "Ramdisk"
3147840       0x300840        gzip compressed data, has original file name: "aa", from Unix, last modified: 2014-10-29 05:09:59
5246976       0x501000        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3872256 bytes, 390 inodes, blocksize: 131072 bytes, created: 2014-10-29 09:47:20

root@mcm:/nanddump-backups-wd-mcm-gen1#

FF wel de /mnt/ubivolume-naam negeren. Het is een ext2 filesystem

code:

root@mcm:/nanddump-backups-wd-mcm-gen1# binwalk rescue-firmware-some.gzip

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

De andere doet wat moeilijker (zelfde naam, andere binfile die ik geëxtraheerd heb.

code:

root@mcm:/nanddump-backups-wd-mcm-gen1# binwalk rescue-firmware-some.gzip

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

root@mcm:/nanddump-backups-wd-mcm-gen1# gunzip rescue-firmware-some.gzip
gzip: rescue-firmware-some.gzip: unknown suffix -- ignored
root@mcm:/nanddump-backups-wd-mcm-gen1# unzip rescue-firmware-some.gzip 
Archive:  rescue-firmware-some.gzip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
note:  rescue-firmware-some.gzip may be a plain executable, not an archive
unzip:  cannot find zipfile directory in one of rescue-firmware-some.gzip or
        rescue-firmware-some.gzip.zip, and cannot find rescue-firmware-some.gzip.ZIP, period.
root@mcm:/nanddump-backups-wd-mcm-gen1# tar zxvf rescue-firmware-some.gzip 
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
root@mcm:/nanddump-backups-wd-mcm-gen1# tar Jxvf rescue-firmware-some.gzip 
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now
root@mcm:/nanddump-backups-wd-mcm-gen1# tar jxvf rescue-firmware-some.gzip 
bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Error is not recoverable: exiting now
root@mcm:/nanddump-backups-wd-mcm-gen1# tar xvf rescue-firmware-some.gzip 
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

[ Voor 50% gewijzigd door bucovaina89 op 30-12-2021 17:06 ]

[Mijzelf]

bucovaina89 schreef op donderdag 30 december 2021 @ 16:37:
damn you're good :d

Nou, dat valt tegen. Dit is totaal anders dan ik had verwacht. Dit ziet eruit als 2 uImages en een squashfs tegen elkaar geplakt. De adressen staan niet in de u-boot environment, voor zover ik kan zien. Blijkbaar hardcoded:

code:

## Booting image at 02000000 ...
### Loading Rescure Firmware ###

NAND read: device 0 offset 0xdd00800, size 0xa00000
 10485760 bytes read: OK
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   Linux-3.2.40

Het adres 0xdd00800 komt overeen met die kernel uImage op 0x0800 die binwalk vind. Vanaf dat adres wordt dus 10MiB ingeladen, wat volgens binwalk overeenkomt met de gehele payload van de partitie. Maar hoe die arme kernel de initramfs en de squashfs in het geheugen moet terugvinden is niet duidelijk. (En dat is de kernel ook niet duidelijk, gezien de kernel panic aan het einde).

Sommige dual flash systemen schakelen om op basis van een watchdog. Als zoveel seconden na het starten van de kernel de watchdog nog niet is gereset, reboot het systeem op een herkenbare manier, zodat u-boot de andere flash partitie actief kan zetten omdat de huidige blijkbaar niet bootable is. (Mislukte update of zo). Ik vraag me af of dit iets dergelijks is. Dat er een hardcoded actie gebeurd na een mislukte boot. Dat zou ook verklaren waarom jouw auto-boot acties onverklaarbaar mislukten, de vorige boot had een vlag gezet.

[Mijzelf]

bucovaina89 schreef op donderdag 30 december 2021 @ 16:37:
De andere doet wat moeilijker (zelfde naam, andere binfile die ik geëxtraheerd heb.

Probeer eens

code:

cat rescue-firmware-some.gzip | gunzip >rescue-firmware-some

[bucovaina89]

code:

root@mcm:/nanddump-backups-wd-mcm-gen1# file rescue-firmware-some.gzip
rescue-firmware-some.gzip: gzip compressed data, max compression, from Unix, original size modulo 2^32 4294967295
root@mcm:/nanddump-backups-wd-mcm-gen1# cat rescue-firmware-some.gzip | gunzip >rescue-firmware-some

gzip: stdin: decompression OK, trailing garbage ignored
root@mcm:/nanddump-backups-wd-mcm-gen1# binwalk rescue-firmware-some

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
180088        0x2BF78         SHA256 hash constants, little endian
2056333       0x1F608D        Certificate in DER format (x509 v3), header length: 4, sequence length: 4784
2662557       0x28A09D        Certificate in DER format (x509 v3), header length: 4, sequence length: 1284
2662685       0x28A11D        Certificate in DER format (x509 v3), header length: 4, sequence length: 1288
2954565       0x2D1545        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
4351181       0x4264CD        Certificate in DER format (x509 v3), header length: 4, sequence length: 1292
4351185       0x4264D1        Certificate in DER format (x509 v3), header length: 4, sequence length: 1316
4351189       0x4264D5        Certificate in DER format (x509 v3), header length: 4, sequence length: 1320
4620444       0x46809C        Linux kernel version 3.2.40
4723368       0x4812A8        DES SP2, little endian
4724136       0x4815A8        DES SP1, little endian
4768364       0x48C26C        CRC32 polynomial table, little endian
4894522       0x4AAF3A        Unix path: /var/run/rpcbind.sock
5555382       0x54C4B6        Copyright string: "copyright (C) 1996 [e-mail])."
5638732       0x560A4C        xz compressed data
5693039       0x56DE6F        Unix path: /var/target/pr/aptpl_%s
5697611       0x56F04B        Unix path: /var/target/alua/tpgs_%s/%s
5697692       0x56F09C        Unix path: /var/target/alua/%s/%s/lun_%u
6052353       0x5C5A01        Certificate in DER format (x509 v3), header length: 4, sequence length: 13660
6147960       0x5DCF78        ASCII cpio archive (SVR4 with no CRC), file name: "dev", file name length: "0x00000004", file size: "0x00000000"
6148076       0x5DCFEC        ASCII cpio archive (SVR4 with no CRC), file name: "dev/console", file name length: "0x0000000C", file size: "0x00000000"
6148200       0x5DD068        ASCII cpio archive (SVR4 with no CRC), file name: "root", file name length: "0x00000005", file size: "0x00000000"
6148316       0x5DD0DC        ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
6217728       0x5EE000        AES S-Box
6217984       0x5EE100        AES Inverse S-Box

root@mcm:nanddump-backups-wd-mcm-gen1#

[Thralas]

bucovaina89 schreef op donderdag 30 december 2021 @ 13:27:
iig hier al iets meer context:

Ik bedoelde eigenlijk de niet-werkende kernel..

Zo heb ik de nand backup gedaan:

mtd0 is inderdaad het hele nand, want 2048 (bytes) *64 (pages) *2048 (blocks) = 268435456 = 0x10000000 = ~256 MiB

Betekent wel dat je de oob bytes mist, want dan was de dump: (2048+64)*64*2048=276824064 = ~264 MiB. Hier waarschijnlijk geen probleem, omdat de output van je nanddump suggereert dat alle bytes ECC zijn en ze bij het dumpen zijn gebruikt/geverifieerd.

Betekent wel dat je bij het schrijven naar NAND de ECC moet laten berekenen, maar dat gaat vanzelf als je nandwrite van mtd-utils gebruikt (zo te zien is dat het geval).

---

Wat wel handig is voor de problemen waar je nu tegenaanloopt; de partitietabel met offsets uit je kernel logs:

code:

[    2.762558] Creating 7 MTD partitions on "pxa3xx_nand-0":
[    2.766721] 0x000000000000-0x000000500000 : "u-Boot"
[    2.776208] 0x000000500000-0x000000a00000 : "uImage"
[    2.785609] 0x000000a00000-0x000000f00000 : "ramdisk"
[    2.795128] 0x000000f00000-0x00000d800000 : "image.cfs"
[    2.805625] 0x00000dd00000-0x00000ec00000 : "rescue firmware"
[    2.815983] 0x00000ec00000-0x000010000000 : "config"
[    2.827457] 0x00000d800000-0x00000dd00000 : "reserve"

root@mcm:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"

Als je goed kijkt dan zie je daar waarom je de rescue ramdisk op offset 0x800 vond: de partitietabel van de kernel komt niet helemaal overeen met de (kennelijk hardcoded) rescue boot in je u-boot.

Maar ik zou je vooral niet te blind staren op een stokoude rescue image waar je toch niet zoveel aan hebt. Op GitHub kun je een vergelijkbare u-boot vinden die de checksums van de kernel/initrd valideert en de rescue boot als ze niet kloppen.

Dan is het probleem dat je checksums niet kloppen (waarschijnlijk omdat je je images op de verkeerde offsets schrijft), niet het feit dat hij een rescue image probeert te booten.

[bucovaina89]

@Thralas : Ik lees jouw post voor de 15e keer maar het licht gaat nog niet aan hier . Ik zie idd dat er een verschil zit tussen beide onderstaande adressen. Ik snap dat 1 van beide niet juist is ( ik vermoed 0x00000dd00000) maar snap niet waarom dit gebeurt en wat de implicaties ervan zijn.

code:

root@mcm:/# dmesg | grep rescue
[    2.805867] 0x00000dd00000-0x00000ec00000 : "rescue firmware"
root@mcm:/# grep rescue /proc/mtd 
mtd5: 00f00000 00020000 "rescue firmware"
root@mcm:/#

En idd, ik ben vooral geinteresseerd in hoe het werkt. Als ik ooit zover geraak, vervang ik graag de U-boot en alles wat daarop staat door nieuwere versies. Maar ik wil het eerst beter begrijpen.

[ Voor 16% gewijzigd door bucovaina89 op 30-12-2021 18:50 ]

[Thralas]

0xdd00000 is de fysieke offset op NAND. Je dump van mtd5 begint dus ook daar. Terwijl u-boot van 0xdd00800 leest. Dus vind je die plek op offset 0xdd00800 - 0xdd00000 = 0x800 van je dump van mtd5.

De entries in /proc/mtd heb je minder aan, dat geeft alleen groottes aan, geen offsets.

[Mijzelf]

@Thralas Volgens mij praat je onzin. Het stock bootcommando was

code:

nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000

wat precies overeenkomt met de start en grootte van de uImage en ramdisk partitie. Dat een adres die niet eens in de environment is terug te vinden niet overeenkomt met de start van een partitie zegt mij niet zoveel. De inhoud van die partitie is sowieso vreemd. Hij is 15MiB groot, maar volgens binwalk bevat hij iets minder dan 10MiB payload, (te weten 2 uImages en een squashfs samengepakt) en die 10MiB is ook precies wat u-boot inlaad. Dus hij skipt 2048 bytes aan het begin, en bijna 5MiB aan het einde.
Als blijkt dat die eerste 2048 bytes duidelijk bij de voorgaande partitie image.cfs horen, dan heb je een punt.

[bucovaina89]

Als ik zelf een U-boot met buildroot wil compileren. Hoe begin ik daar dan aan? Ik heb deze pdf gevolgd. Maar lang niet alles is me duidelijk.

Ik heb zelf maar een directory board/western-digital/ met daar de dts file in.
Daarnaast heb ik zelf een boot.cmd file aangemaakt met deze inhoud:

code:

setenv bootargs=root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect
setenv bootcmd=nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000
setenv bootdelay=5
setenv loadaddr=0x02000000
setenv mtdids=nand0=armada-nand
setenv mtdparts=mtdparts=armada-nand:4m(boot),-(rootfs)
setenv nandEcc=1bit
setenv stdin=serial
setenv stdout=serial

Daar zou dan een .img uit moeten komen en die kan ik dan eens proberen up te loaden via de UART en zien wat het geeft. Ik geef het iig weinig kans op slagen want vele dingen heb ik maar gegokt ik vermoed dat dit allemaal wel juist moet zijn.

Of als ik ergens een defconfig kan vinden van mijn bordje, dat zou me al superver leiden denk ik.

[ Voor 4% gewijzigd door bucovaina89 op 30-12-2021 20:13 ]

[Thralas]

Mijzelf schreef op donderdag 30 december 2021 @ 19:58:
@Thralas Volgens mij praat je onzin.

Nou, nou, nou..

wat precies overeenkomt met de start en grootte van de uImage en ramdisk partitie.

Daar gaat mijn post ook helemaal niet over? Het gaat over die recovery die geboot wordt. Die staat op 0xdd00000 (volgens de kernel althans, terwijl u-boot van +0x800 laadt).

Hij is 15MiB groot, maar volgens binwalk bevat hij iets minder dan 10MiB payload, (te weten 2 uImages en een squashfs samengepakt) en die 10MiB is ook precies wat u-boot inlaad. Dus hij skipt 2048 bytes aan het begin, en bijna 5MiB aan het einde.

Dat is juist waarom de mapping zoals de kernel hem geeft blijkbaar niet klopt, toch.

Als blijkt dat die eerste 2048 bytes duidelijk bij de voorgaande partitie image.cfs horen, dan heb je een punt.

Ze hoeven natuurlijk nergens bij te horen. Net als dat de laatste 5 MB ongebruikt lijkt - of in ieder geval door de bootloader zoals 'ie er nu staat.

---

bucovaina89 schreef op donderdag 30 december 2021 @ 20:08:
Als ik zelf een U-boot met buildroot wil compileren. Hoe begin ik daar dan aan?

Buildroot of u-boot?

Want voor u-boot is 't simpel: niet aan beginnen, @Mijzelf heeft al uitgelegd waarom het niet nodig is. Bovendien: als je het vervangt door iets dat niet werkt loop je het risico dat je het ding echt brickt.

Nu heeft het ding natuurlijk een bootrom loader, maar dan moet je er wel zeker van zijn dat die werkt.

Ik heb deze pdf gevolgd. Maar lang niet alles is me duidelijk.

Over buildroot: daar is niet zoveel mis mee, als je daar een kernel en ramdisk mee wilt bouwen tenminste.

Daarnaast heb ik zelf een boot.cmd file aangemaakt met deze inhoud:

Niet relevant, want u-boot.

Of als ik ergens een defconfig kan vinden van mijn bordje, dat zou me al superver leiden denk ik.

Je had toch al een werkende kernel? Je kunt Buildroot ook gebruiken om enkel een initrd te bouwen. Dat is simpeler.

Dat is relatief simpel: daarvoor heb je geen device trees of defconfigs nodig hebt: architectuur (ARMv7) juist invullen, kernelversie zo goed mogelijk matchen en het output format (uImage) goedzetten.

Met de rest op defaults komt daar wel een initrd uitrollen die het zou moeten doen op jouw hardware in combinatie met de kernel die je al hebt.

[ Voor 3% gewijzigd door Thralas op 30-12-2021 21:39 ]

[bucovaina89]

@Thralas : Oei, dan heb ik misschien gemist waarom U-boot zelf compileren niet nodig is. 't is maar een bootloader inderdaad maar los daarvan nog iets? Als het niet té complex is, wil ik het wel proberen, al was het maar dat ik wat meer leer over hoe het hele systeem in elkaar zit.

buildroot kan je toch gebruiken om U-boot te compileren? Of zie ik het fout?

En ik zou die eerst via x-modem file transfer te testen. Als die werkt, dan is't goed. Werkt die niet, dan reset ik het bordje gewoon en boot hij weer van NAND flash.

[Thralas]

bucovaina89 schreef op donderdag 30 december 2021 @ 21:52:
@Thralas : Oei, dan heb ik misschien gemist waarom U-boot zelf compileren niet nodig is. 't is maar een bootloader inderdaad maar los daarvan nog iets?

Precies dat. Het levert geen voordeel op. Het moet een kernel met ramdisk booten, that's it.

Als het niet té complex is, wil ik het wel proberen, al was het maar dat ik wat meer leer over hoe het hele systeem in elkaar zit.

Maar dat is het wel, want u-boot mainline kent jouw bordje niet. Dáár zul je wel een board definition moeten aanleveren/schrijven (in C), met allerlei details (ram timings) die je niet 123 paraat hebt.

Zorg eerst maar eens dat je een werkende kernel (liefst up-to-date) en ramdisk/os hebt dat betrouwbaar van flash boot.

buildroot kan je toch gebruiken om U-boot te compileren? Of zie ik het fout?

Natuurlijk, maar Buildroot is vooral bedoeld om een customized root image te bouwen.

Kernels en bootloader kan het voor je bouwen omdat dat handig is als je zaken wilt integreren, maar daar moet je niet aan beginnen voordat je die ook zelfstandig weet te bouwen. Het integreert alleen zaken, het produceert niet magischerwijs een werkende u-boot voor een stokoude Armada 370.

En ik zou die eerst via x-modem file transfer te testen. Als die werkt, dan is't goed. Werkt die niet, dan reset ik het bordje gewoon en boot hij weer van NAND flash.

Fair, als je zeker weet dat je daarmee tegen de bootrom praat (daar lijkt het wel op).

[bucovaina89]

Thralas schreef op donderdag 30 december 2021 @ 22:15:
Maar dat is het wel, want u-boot mainline kent jouw bordje niet. Dáár zul je wel een board definition moeten aanleveren/schrijven (in C), met allerlei details (ram timings) die je niet 123 paraat hebt.

OK, dat is een show stopper want dat kan ik niet.

Thralas schreef op donderdag 30 december 2021 @ 22:15:
Zorg eerst maar eens dat je een werkende kernel (liefst up-to-date) en ramdisk/os hebt dat betrouwbaar van flash boot.

Die heb ik ondertussen. De kernel is up-to-date. OK een 4.14.290 van gisteren, maar dat is wegens een bug. Een 5.16 kernel image heb ik maar te flashen en klaar.

Een uRamdisk heb ik nog niet gemaakt.

Wat ik wel nog wil kunnen is de boot aanpassen zodat als het bordje zonder schijven/zonder rootfs zit wel boot in een busybox omgeving terug valt die ik dan ergens op NAND zou zetten. Ik vermoed dat dan de enige manier (omdat U-boot moeilijk aan te passen valt), de kernel en/of initramfs op HDD's te zetten dat de watchdog timer kan opvangen wanneer het bord niet deftig geboot raakt? En dan een kernel uImage op 0xdd00000 en een initramfs ook ergens op een adres op die partitie (geen idee waar).

[Mijzelf]

Thralas schreef op donderdag 30 december 2021 @ 21:37:
[...]


Daar gaat mijn post ook helemaal niet over? Het gaat over die recovery die geboot wordt. Die staat op 0xdd00000 (volgens de kernel althans, terwijl u-boot van +0x800 laadt).

Dan begrijpen we elkaar verkeerd. Ik meende dat jij het over een cumulatieve fout had door niet meegenomen oob geheugen of zo, die bij de recovery partitie inmiddels 0x800 is. Daartegenover zette ik de uImage en ramdiskpartitie die precies staan waar ze moeten staan, wat aangeeft dat er niets cumulatiefs is.

Overigens blijf ik erbij dat dat adres 0xdd00800 niet zoveel zegt, omdat de manier waarop u-boot dit laadt gewoon raar is, en buiten de normale boot flow valt. Misschien zit er een 'recovery script' in die eerste 2k, die wordt geladen en uitgevoerd.

bucovaina89 schreef op donderdag 30 december 2021 @ 22:40:
Wat ik wel nog wil kunnen is de boot aanpassen zodat als het bordje zonder schijven/zonder rootfs zit wel boot in een busybox omgeving terug valt die ik dan ergens op NAND zou zetten.

Je zou eens naar OpenWrt kunnen kijken. Die biedt een mogelijkheid om een 'initramfs-kernel' te bouwen, dat is een kernel met een ingebouwde initramfs, met daarin een 'volledig' commandline systeem. Wat je precies in die initramfs wilt hebben is modulair, en zelf te kiezen. Ik denk dat als je jouw dts zou kunnen injecteren, je 'gewoon' een initramfs firmware voor een andere Armada kunt bouwen.

de kernel en/of initramfs op HDD's te zetten

Dat is iets wat je zou moeten proberen. Zoals zoveel dingen is u-boot modulair. U-boot kan booten van SATA, maar of een u-boot van een commercieel bordje dat ook kan is afwachten. Mijn Netgear kan dat niet. Overigens staat daar standaard Debian op, met een extra 'post install' script. Als er een nieuwe kernel + initramfs in de /boot partitie is geïnstalleerd, maakt dat script er uImages van en flasht ze in de juiste partities. Bijna net zo goed als booten van SATA.

Je zou je 'emergency boot' trouwens ook andersom kunnen doen. Het is in u-boot mogelijk om bootmethoden na elkaar te proberen. De eerste die lukt stopt de keten (logisch, daarna is u-boot weg). Je zou eerst kunnen proberen te booten van tftp (met bijvoorbeeld een OpenWrt initramfs-kernel), en daarna van nand. Om in je emergency kernel te komen hoef je dan alleen je tftp server aan te zetten, of te zorgen dat de juiste uImage beschikbaar is.

[bucovaina89]

@Mijzelf : Dat klinkt interessant, of zoiets:

1. TFTP
2. USB
3. NAND
4. /dev/mdX
5. Emergency firmware

Ik ben wat aan het googlen geweest maar dat lijkt precies toch niet zo goed bekend hoe je dat moet doen. Ik vind er niet echt iets over. Wat is de terminologie? Of heb je misschien een link naar een plek in de reference manual die het uitlegt?

[Mijzelf]

USB is ook weer zo'n dingetje. Misschien ondersteund u-boot het, misschien niet. (Dat zou overigens een reden kunnen zijn om u-boot te vervangen. Aan de andere kant, waarom zit het niet in stock u-boot? Misschien omdat de benodigde drivers nooit voor u-boot zijn geschreven. Voor de stock functie is tftp en nand ruim voldoende) /dev/mdX is 'gewoon' booten van harddisk.
Ik denk dat NAND altijd de laatste moet zijn, omdat dat niet kan mislukken vanuit u-boot oogpunt gezien. De chaining werkt op basis van het wel of niet kunnen laden van een bootable uImage. Vanuit NAND kan dat niet mislukken (tenzij je verwacht dat het in flash corrupt raakt). Het zou kunnen dat het rootfs niet gevonden kan worden, gevolgd door een kernel panic of zo, maar het is Linux die dat constateert, en u-boot zit dan al niet meer in het geheugen.

De terminologie is denk ik 'conditional booting', en er zijn twee versies, afhankelijk of je u-boot 'if then' ondersteund of niet.
Hier vind je een voorbeeld van de 'oude' manier, en hier wordt de nieuwe manier uitgelegd.

[bucovaina89]

Interessant. Ik heb ondertussen een volgens mij OK uRamdisk aangemaakt. Maar hoe verander ik nu mijn rootfs zodat ik in de ramdisk blijf?

uRamdisk maken:

code:

mkdir -p version1/ && cd version1/
mkdir -p bin dev etc lib mnt proc sbin sys tmp var

wget https://www.busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-armv7r -O bin/busybox
chmod +x bin/busybox

cat >> ./init << EOF
#!/bin/busybox sh

mount -t devtmpfs  devtmpfs  /dev
mount -t proc      proc      /proc
mount -t sysfs     sysfs     /sys
mount -t tmpfs     tmpfs     /tmp

sh
EOF

find . | cpio -ov --format=newc >../initramfs

mkimage -A arm -O linux -T ramdisk -C gzip -d /path/to/tftp/uRamdisk

Zo boot ik Linux (kan volgens mij nog wel wat code weg maar goed, dat doe ik later wel). Met deze commando's hij boot gewoon verder zoals je zou verwachten in normale situaties. Natuurlijk want rootfs=/dev/md0. Hoe maak ik dan dat hij in een busybox omgeving blijft hangen?

code:

dhcp
setenv serverip 10.10.10.10
tftp ${loadaddr} uImage
setenv bootcmd "dhcp; tftp ${loadaddr} ${serverip}:uImage; tftp 0xf00000 ${serverip}:uRamdisk"
bootm ${loadaddr} 0xf00000

[Mijzelf]

De kernel zal (tenzij anders gespecificeerd in de command line) /sbin/init uitvoeren vanaf het initramfs. Dat kan een symlink naar busybox zijn, in welk geval er een soort sysv achtige boot plaatsvind. Maar het kan ook een shellscript zijn, in welk geval het gewoon uitgevoerd wordt. /sbin/init wordt uitgevoerd als proces 1. Als proces 1 ooit beëindigd reboot het systeem.
Daarom eindigt een init script meestal in een switch_root, die het rootfs veranderd, en PID 1 doorgeeft aan init op het nieuwe rootfs.

Jij wilt hem laten 'hangen' in /sbin/init, dat kun je doen door een shell te starten. Dat lijk je ook te doen in een script /init, maar ik weet niet zeker of 'sh' hier werkt. Er is geen symlink 'sh' beschikbaar voor zover ik kan zien, dus '/bin/busybox sh' lijkt me correcter. Hetzelfde geld voor mount. Hoewel je misschien ook aan het begin van je script '/bin/busybox --install' kunt aanroepen om de symlinks aan te maken.
Verder moet je dus je script in /sbin/ zetten, en niet in / (tenzij je init=/init aan de commandline toevoegd) en het script moet executable zijn. (chmod a+x init)

[bucovaina89]

Hmm, om een of andere reden blijft het niet werken.

Als ik root=/dev/md0 mee geef als bootargument, dan boot hij gewoon volledig door naar de RAID zoals anders. Als ik root=/ dan is het kernel panic not syncing en als ik het hele argument achterwege laat ook. Hij blijft alsnog niet in busybox hangen.

code: u-boot

dhcp
setenv serverip 10.10.10.10
tftp ${loadaddr} uImage
setenv bootargs 'root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect'
setenv bootcmd "dhcp; tftp ${loadaddr} ${serverip}:uImage; tftp 0xf00000 ${serverip}:uRamdisk"
bootm ${loadaddr} 0xf00000

Bash: create-uRamdisk.sh

ramdiskversion="version2"
mkdir -p $ramdiskversion/ && cd $ramdiskversion/
mkdir -p bin dev etc lib mnt proc sbin sys tmp var

wget https://www.busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-armv7r -O bin/busybox
chmod +x bin/busybox

cat >> sbin/init << EOF
#!/bin/busybox sh

/bin/busybox --install #create all symlinks

mount -t devtmpfs  devtmpfs  /dev
mount -t proc      proc      /proc
mount -t sysfs     sysfs     /sys
mount -t tmpfs     tmpfs     /tmp

/bin/busybox sh
EOF

chmod a+x sbin/init

find . | cpio -ov --format=newc >../initramfs

mkimage -A arm -O linux -T ramdisk -C gzip -d /tftp/uRamdisk #naar de tftpserver

[ Voor 1% gewijzigd door bucovaina89 op 01-01-2022 07:06 . Reden: spelling en opmaak ]

[Mijzelf]

Kun je een volledige bootlog posten?

Een voorbeeld uit de manpage van mkimage:

code:

Create legacy image with compressed PowerPC Linux kernel:

mkimage -A powerpc -O linux -T kernel -C gzip -a 0 -e 0 -n Linux -d vmlinux.gz uImage

Gezien de extensie van vmlinux.gz is de kernel al gecomprimeerd, en is de '-C gzip' dus een vlag, en geen actie.
Dus probeer eens

code:

find . | cpio -ov --format=newc | gzip >../initramfs.gz

[bucovaina89]

Ah, ik denk dat ik heb heb gezien. Hij kan de initramfs gewoon niet lezen. Foute formaat vermoed ik dan. Ik probeer jouw code eens.

code:

...
...
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd
Freeing initrd memory: 4K
...
...

code: volledigebootlog

BootROM 1.08
Booting from NAND flash
High speed PHY - Version: 2.1.2 (COM-PHY-V20) 
Update PEX Device ID 0x67100
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 4.5.0 
DDR3 Training Sequence - Ended Successfully 
Status = MV_OK
BootROM: Image checksum verification PASSED

 ** LOADER **


U-Boot 2011.12 (Dec 24 2013 - 20:21:45) Marvell version: v2011.12 2013_Q1.2 (ALPHA U-BOOT : 1.0)

Board: RD-88F6710_ALpha_KingsCanyon
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU    @ 1200 [MHz]
       L2     @ 600 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 600 [MHz]
       DDR 16Bit Width, FastPath Memory Access
DRAM:  512 MiB

Map:   Code:        0x1fef5000:0x1ff9faac
       BSS:     0x1ffef784
       Stack:       0x1f9f4ef8
       Heap:        0x1f9f5000:0x1fef5000

NAND:  flash id : daad
256 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: Bad block at 0x000005a60000
PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
PEX 0.1(1): Detected No Link.
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Modules/Interfaces Detected:
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)
Not Marvell PHY id1 ffff id2 ffff
Enable HD1
Enable HD2
Net:   egiga1
Hit any key to stop autoboot:  0 
Marvell>> printenv       
CASset=min
MALLOC_len=5
autoload=no
baudrate=115200
bootargs=root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect
bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=nand read.e 0xa00000 0x500000 0x500000; bootm 0xa00000
bootdelay=1
cacheShare=no
console=console=ttyS0,115200
disL2Cache=yes
disaMvPnp=no
dnsip=10.10.10.10
eeeEnable=no
enaAutoRecovery=yes
enaClockGating=no
enaFPU=no
enaWrAllo=no
eth1addr=00:50:43:02:00:00
eth1mtu=1500
ethact=egiga1
ethaddr=00:50:43:02:00:00
ethmtu=1500
ethprime=egiga0
fileaddr=2000000
filesize=37CEB6
gatewayip=10.10.10.1
image_name=uImage
initrd_name=uInitrd
ipaddr=10.10.10.145
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:4m(boot),-(rootfs)
mvNetConfig=mv_net_config=1,(00:50:43:11:11:11,0:1:2:3:4),mtu=1500
mv_pon_addr=00:50:43:00:00:02
nandEcc=1bit
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=rc
pxe_files_load=:default.arm-armada370-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
rcvrip=169.254.100.100
rootpath=/srv/oneiric
sata_delay_reset=0
sata_dma_mode=yes
serverip=10.10.10.10
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usb1Mode=host
usb2Mode=device
usbActive=1
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Environment size: 1567/524284 bytes
Marvell>> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 119
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 119
DHCP client bound to address 10.10.10.219
Marvell>> setenv serverip 10.10.10.10
Marvell>> tftp ${loadaddr} uImage-4.14-nand
Using egiga1 device
TFTP from server 10.10.10.10; our IP address is 10.10.10.219
Filename 'uImage-4.14-nand'.
Load address: 0x2000000
Loading: #################################################################
     #################################################################
     #################################################################
     #######################################################
done
Bytes transferred = 3657398 (37ceb6 hex)
Marvell>> setenv bootargs 'console=ttyS0,115200 max_loop=32 raid=autodetect'       
Marvell>> tftp 0xf00000 uRamdisk
Using egiga1 device
TFTP from server 10.10.10.10; our IP address is 10.10.10.219
Filename 'uRamdisk'.
Load address: 0xf00000
Loading: #
done
Bytes transferred = 2112 (840 hex)
Marvell>> bootm ${loadaddr} 0xf00000
## Booting image at 02000000 ...
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   armada-370-wdmc-mirror-gen1
   Created:      2021-12-29  17:26:30 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3657334 Bytes = 3.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00f00000 ...
   Image Name:   
   Created:      2022-01-01   5:52:09 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2048 Bytes = 2 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.14.260 (root@htpc) (gcc version 10.2.1 20210110 (Debian 10.2.1-6)) #1 SMP Wed Dec 29 16:38:05 CET 2021
CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
OF: fdt: Machine model: WD MyCloud Mirror
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
Built 1 zonelists, mobility grouping on.  Total pages: 129920
Kernel command line: console=ttyS0,115200 max_loop=32 raid=autodetect
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 507328K/524288K available (7352K kernel code, 288K rwdata, 1768K rodata, 1024K init, 207K bss, 16960K reserved, 0K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc082e3b0   (8345 kB)
      .init : 0xc0b00000 - 0xc0c00000   (1024 kB)
      .data : 0xc0c00000 - 0xc0c483e0   ( 289 kB)
       .bss : 0xc0c4a000 - 0xc0c7dc90   ( 208 kB)
Hierarchical RCU implementation.
    RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
L2C: DT/platform modifies aux control register: 0x12086302 -> 0x1a086302
Aurora cache controller enabled, 4 ways, 256 kB
Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302
Switching to timer-based delay loop, resolution 53ns
sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114532461029ns
clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101933890472 ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 37.50 BogoMIPS (lpj=187500)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket -1, mpidr 0
Setting up static identity map for 0x100000 - 0x100060
mvebu-soc-id: MVEBU SoC ID=0x6710, Rev=0x1
mvebu-pmsu: Initializing Power Management Service Unit
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated (37.50 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x100/0x22c with crng_init=0
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: 2, 16384 bytes)
xor: measuring software checksum speed
   arm4regs  :  1104.000 MB/sec
   8regs     :   846.400 MB/sec
   32regs    :  1103.200 MB/sec
xor: using function: arm4regs (1104.000 MB/sec)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
raid6: int32x1  gen()   162 MB/s
raid6: int32x1  xor()   214 MB/s
raid6: int32x2  gen()   255 MB/s
raid6: int32x2  xor()   248 MB/s
raid6: int32x4  gen()   264 MB/s
raid6: int32x4  xor()   204 MB/s
raid6: int32x8  gen()   303 MB/s
raid6: int32x8  xor()   203 MB/s
raid6: using algorithm int32x8 gen() 303 MB/s
raid6: .... xor() 203 MB/s, rmw enabled
raid6: using intx1 recovery algorithm
reg-fixed-voltage regulators:regulator@1: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/xhci-pwr-pin, deferring probe
reg-fixed-voltage regulators:regulator@2: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/sata-1-pwr-pin, deferring probe
reg-fixed-voltage regulators:regulator@3: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/sata-2-pwr-pin, deferring probe
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[e-mail]>
PTP clock support registered
Bluetooth: Core ver 2.22
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
clocksource: Switched to clocksource armada_370_xp_clocksource
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
FS-Cache: Loaded
CacheFiles: Loaded
NET: Registered protocol family 2
IP idents hash table entries: 8192 (order: 4, 65536 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd
Freeing initrd memory: 4K
Initialise system trusted keyrings
workingset: timestamp_bits=14 max_order=17 bucket_order=3
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
Installing knfsd (copyright (C) 1996 [e-mail]).
FS-Cache: Netfs 'cifs' registered for caching
async_tx: api initialized (async)
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
io scheduler kyber registered
armada-370-pinctrl f1018000.pin-ctrl: registered pinctrl driver
mvebu-pcie soc:pcie@82000000: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
PCI: bus2: Fast back to back transfers enabled
pci 0000:00:01.0: BAR 8: assigned [mem 0xf8000000-0xf80fffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xf8000000-0xf8001fff 64bit]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xf8000000-0xf80fffff]
pci 0000:00:02.0: PCI bridge to [bus 02]
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 20, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 21, base_baud = 12500000) is a 16550A
brd: module loaded
loop: module loaded
sata_mv f10a0000.sata: slots 32 ports 2
scsi host0: sata_mv
scsi host1: sata_mv
ata1: SATA max UDMA/133 irq 29
ata2: SATA max UDMA/133 irq 29
pxa3xx-nand f10d0000.nand: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0xad, Chip ID: 0xda
nand: Hynix H27U2G8F2CTR-BC
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand f10d0000.nand: ECC strength 16, ECC step size 2048
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000005a60000
7 ofpart partitions found on MTD device pxa3xx_nand-0
ftl_cs: FTL header not found.
Creating 7 MTD partitions on "pxa3xx_nand-0":
0x000000000000-0x000000500000 : "u-Boot"
ftl_cs: FTL header not found.
0x000000500000-0x000000a00000 : "uImage"
ftl_cs: FTL header not found.
0x000000a00000-0x000000f00000 : "ramdisk"
ftl_cs: FTL header not found.
0x000000f00000-0x00000d800000 : "image.cfs"
ftl_cs: FTL header not found.
0x00000dd00000-0x00000ec00000 : "rescue firmware"
ftl_cs: FTL header not found.
0x00000ec00000-0x000010000000 : "config"
random: fast init done
ftl_cs: FTL header not found.
0x00000d800000-0x00000dd00000 : "reserve"
ftl_cs: FTL header not found.
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
libphy: Fixed MDIO Bus: probed
libphy: orion_mdio_bus: probed
mvneta f1074000.ethernet eth0: Using hardware mac address 00:50:43:02:00:00
usbcore: registered new interface driver lan78xx
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.usb: EHCI Host Controller
orion-ehci f1050000.usb: new USB bus registered, assigned bus number 1
orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.14.260 ehci_hcd
usb usb1: SerialNumber: f1050000.usb
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-9: WDC WD30EZRX-00DC0B0, 80.00A80, max UDMA/133
ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      WDC WD30EZRX-00D 0A80 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
rtc-mv f1010300.rtc: internal RTC not ticking
i2c /dev entries driver
(NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: [e-mail]
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ledtrig-cpu: registered to indicate activity on CPUs
marvell-cesa f1090000.crypto: CESA device successfully registered
hidraw: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Netfilter messages via NETLINK v0.30.
nfnl_acct: registering with nfnetlink.
nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
arp_tables: arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 10
ata2.00: ATA-9: WDC WD30EZRX-00DC0B0, 80.00A80, max UDMA/133
ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Bridge firewalling registered
8021q: 802.1Q VLAN Support v1.8
Key type dns_resolver registered
Registering SWP/SWPB emulation handler
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access     ATA      WDC WD30EZRX-00D 0A80 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 1:0:0:0: [sdb] 4096-byte physical blocks
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Loading compiled-in X.509 certificates
armada-370-pinctrl f1018000.pin-ctrl: unsupported function gpio on pin mpp54
pinctrl core: failed to register map default (0): invalid type given
reg-fixed-voltage: probe of regulators:regulator@2 failed with error -22
 sdb: sdb1
sd 1:0:0:0: [sdb] Attached SCSI disk
input: gpio-keys as /devices/platform/gpio-keys/input/input0
hctosys: unable to open rtc device (rtc0)
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: autorun ...
md: running: <sdb1><sda1>
md0: detected capacity change from 0 to 6001181851648
md: ... autorun DONE.
RAMDISK: Couldn't find valid RAM disk image starting at 0.
VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
0100            4096 ram0 
 (driver?)
0101            4096 ram1 
 (driver?)
0102            4096 ram2 
 (driver?)
0103            4096 ram3 
 (driver?)
0104            4096 ram4 
 (driver?)
0105            4096 ram5 
 (driver?)
0106            4096 ram6 
 (driver?)
0107            4096 ram7 
 (driver?)
1f00          262144 mtdblock0 
 (driver?)
1f01            5120 mtdblock1 
 (driver?)
1f02            5120 mtdblock2 
 (driver?)
1f03            5120 mtdblock3 
 (driver?)
1f04          205824 mtdblock4 
 (driver?)
1f05           15360 mtdblock5 
 (driver?)
1f06           20480 mtdblock6 
 (driver?)
1f07            5120 mtdblock7 
 (driver?)
0800      2930266584 sda 
 driver: sd
  0801      2930265088 sda1 ebefcd3d-56aa-4b57-8377-72b4c8547c16

0810      2930266584 sdb 
 driver: sd
  0811      2930265088 sdb1 2c325b59-8bfa-4be0-93f9-1e9da62c3b16

0900      5860529152 md0 
 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
root@htpc:~#

[ Voor 100% gewijzigd door bucovaina89 op 01-01-2022 13:44 ]

[bucovaina89]

Het is al anders maar nog niet 100% goed:

code:

RAMDISK: Couldn't find valid RAM disk image starting at 0.

Dit is helemaal hoe ik hem maak:

code:

root@htpc:/mnt/ruimteschip/Zandbak/initramfs# ramdiskversion="version4"
root@htpc:/mnt/ruimteschip/Zandbak/initramfs# mkdir -p $ramdiskversion/ && cd $ramdiskversion/
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# mkdir -p bin dev etc lib mnt proc sbin sys tmp var

## --no-certificate-check omdat de tijd niet juist staat op de host.
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# wget --no-check-certificate https://www.busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-armv7r -O bin/busybox
--2022-01-01 14:01:14--  https://www.busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-armv7r
Resolving www.busybox.net (www.busybox.net)... 140.211.167.122
Connecting to www.busybox.net (www.busybox.net)|140.211.167.122|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1152216 (1.1M)
Saving to: ‘bin/busybox’

bin/busybox                   100%[================================================>]   1.10M  1.06MB/s    in 1.0s    

2022-01-01 14:01:16 (1.06 MB/s) - ‘bin/busybox’ saved [1152216/1152216]

root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# chmod +x bin/busybox
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# cat >> sbin/init << EOF
> #!/bin/busybox sh
> 
> /bin/busybox --install #create all symlinks
> 
> mount -t devtmpfs  devtmpfs  /dev
> mount -t proc      proc      /proc
> mount -t sysfs     sysfs     /sys
> mount -t tmpfs     tmpfs     /tmp
> 
> /bin/busybox sh
> EOF
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# chmod a+x sbin/init
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# find . | cpio -ov --format=newc | gzip >../initramfs.gz
.
./bin
./bin/busybox
./dev
./etc
./lib
./mnt
./proc
./sbin
./sbin/init
./sys
./tmp
./var
2255 blocks
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4# mkimage -A arm -O linux -T ramdisk -C gzip -d ../initramfs.gz /mnt/ruimteschip/Zandbak/tftp/uRamdisk
Image Name:   
Created:      Sat Jan  1 14:01:44 2022
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    675228 Bytes = 659.40 KiB = 0.64 MiB
Load Address: 00000000
Entry Point:  00000000
root@htpc:/mnt/ruimteschip/Zandbak/initramfs/version4#

En dan booten met

code:

dhcp
setenv serverip 10.10.10.10
tftp ${loadaddr} uImage-4.14-nand
tftp 0xf00000 uRamdisk
bootm ${loadaddr} 0xf00000

Hij laadt beide files in (kernel en ramdisk, als het niet lukt zie je dat ook meteen). Volgens mij doe ik toch nog iets mis met het maken van de initramfs. Ergens niet juiste formaat of zo? Of ik zet hem op een RAM adres dat niet juist is? Of te ver naar achter zodat het er niet op past? (de ramdisk is maar dik 600kB).

[Mijzelf]

Ik moet toegeven dat ik nog nooit een initramfs op deze manier heb gemaakt. Alleen als 'full blown' op een distro, of embedded in de kernel.
Dat gezegd hebbende, zou er iets met je versiebeheer kunnen zijn?

code:

Filename 'uRamdisk'.
Load address: 0xf00000
Loading: #
done
Bytes transferred = 2112 (840 hex)

## Loading init Ramdisk from Legacy Image at 00f00000 ...
   Image Name:   
   Created:      2022-01-01   5:52:09 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2048 Bytes = 2 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

De hele file is maar 2112 bytes groot, dat is 2048 + 64 bytes header.

[bucovaina89]

code:

Marvell>> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 119
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 119
DHCP client bound to address 10.10.10.219
Marvell>> setenv serverip 10.10.10.10
Marvell>> tftp ${loadaddr} uImage-4.14-nand
Using egiga1 device
TFTP from server 10.10.10.10; our IP address is 10.10.10.219
Filename 'uImage-4.14-nand'.
Load address: 0x2000000
Loading: #################################################################
     #################################################################
     #################################################################
     #######################################################
done
Bytes transferred = 3657398 (37ceb6 hex)
Marvell>> tftp 0xf000000 uRamdisk
Using egiga1 device
TFTP from server 10.10.10.10; our IP address is 10.10.10.219
Filename 'uRamdisk'.
Load address: 0xf000000
Loading: ###############################################
done
Bytes transferred = 675292 (a4ddc hex)
Marvell>> setenv bootcmd "root=/c/Windows/system32 dhcp; tftp ${loadaddr} ${serverip}:uImage; tftp 0xf000000 ${serverip}:uRamdisk"
Marvell>> bootm ${loadaddr} 0xf000000
## Booting image at 02000000 ...
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   armada-370-wdmc-mirror-gen1
   Created:      2021-12-29  17:26:30 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3657334 Bytes = 3.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0f000000 ...
   Image Name:   
   Created:      2022-01-01  13:01:44 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    675228 Bytes = 659.4 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Dit lijkt me dan allemaal nog OK (merk dat ik een nu bij achter 0f00000 heb gezet.

code:

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.14.260 (root@htpc) (gcc version 10.2.1 20210110 (Debian 10.2.1-6)) #1 SMP Wed Dec 29 16:38:05 CET 2021
CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
OF: fdt: Machine model: WD MyCloud Mirror
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
Built 1 zonelists, mobility grouping on.  Total pages: 129920
Kernel command line: root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 506672K/524288K available (7352K kernel code, 288K rwdata, 1768K rodata, 1024K init, 207K bss, 17616K reserved, 0K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc082e3b0   (8345 kB)
      .init : 0xc0b00000 - 0xc0c00000   (1024 kB)
      .data : 0xc0c00000 - 0xc0c483e0   ( 289 kB)
       .bss : 0xc0c4a000 - 0xc0c7dc90   ( 208 kB)
Hierarchical RCU implementation.
    RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
L2C: DT/platform modifies aux control register: 0x12086302 -> 0x1a086302
Aurora cache controller enabled, 4 ways, 256 kB
Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302
Switching to timer-based delay loop, resolution 53ns
sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114532461029ns
clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101933890472 ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 37.50 BogoMIPS (lpj=187500)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket -1, mpidr 0
Setting up static identity map for 0x100000 - 0x100060
mvebu-soc-id: MVEBU SoC ID=0x6710, Rev=0x1
mvebu-pmsu: Initializing Power Management Service Unit
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated (37.50 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x100/0x22c with crng_init=0
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: 2, 16384 bytes)
xor: measuring software checksum speed
   arm4regs  :  1104.000 MB/sec
   8regs     :   846.400 MB/sec
   32regs    :  1103.200 MB/sec
xor: using function: arm4regs (1104.000 MB/sec)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
raid6: int32x1  gen()   162 MB/s
raid6: int32x1  xor()   214 MB/s
raid6: int32x2  gen()   255 MB/s
raid6: int32x2  xor()   248 MB/s
raid6: int32x4  gen()   264 MB/s
raid6: int32x4  xor()   204 MB/s
raid6: int32x8  gen()   303 MB/s
raid6: int32x8  xor()   203 MB/s
raid6: using algorithm int32x8 gen() 303 MB/s
raid6: .... xor() 203 MB/s, rmw enabled
raid6: using intx1 recovery algorithm
reg-fixed-voltage regulators:regulator@1: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/xhci-pwr-pin, deferring probe
reg-fixed-voltage regulators:regulator@2: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/sata-1-pwr-pin, deferring probe
reg-fixed-voltage regulators:regulator@3: could not find pctldev for node /soc/internal-regs/pin-ctrl@18000/sata-2-pwr-pin, deferring probe
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[e-mail]>
PTP clock support registered
Bluetooth: Core ver 2.22
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
clocksource: Switched to clocksource armada_370_xp_clocksource
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
FS-Cache: Loaded
CacheFiles: Loaded
NET: Registered protocol family 2
IP idents hash table entries: 8192 (order: 4, 65536 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.

Even onderbreken, niet zeker of dit nu goed dan wel slecht is:

code:

Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 660K

en we gaan weer verder met booten:

code:

Initialise system trusted keyrings
workingset: timestamp_bits=14 max_order=17 bucket_order=3
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
Installing knfsd (copyright (C) 1996 [e-mail]).
FS-Cache: Netfs 'cifs' registered for caching
async_tx: api initialized (async)
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
io scheduler kyber registered
armada-370-pinctrl f1018000.pin-ctrl: registered pinctrl driver
mvebu-pcie soc:pcie@82000000: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
PCI: bus2: Fast back to back transfers enabled
pci 0000:00:01.0: BAR 8: assigned [mem 0xf8000000-0xf80fffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xf8000000-0xf8001fff 64bit]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xf8000000-0xf80fffff]
pci 0000:00:02.0: PCI bridge to [bus 02]
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 20, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 21, base_baud = 12500000) is a 16550A
brd: module loaded
loop: module loaded
sata_mv f10a0000.sata: slots 32 ports 2
scsi host0: sata_mv
scsi host1: sata_mv
ata1: SATA max UDMA/133 irq 29
ata2: SATA max UDMA/133 irq 29
pxa3xx-nand f10d0000.nand: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0xad, Chip ID: 0xda
nand: Hynix H27U2G8F2CTR-BC
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand f10d0000.nand: ECC strength 16, ECC step size 2048
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000005a60000
7 ofpart partitions found on MTD device pxa3xx_nand-0
ftl_cs: FTL header not found.
Creating 7 MTD partitions on "pxa3xx_nand-0":
0x000000000000-0x000000500000 : "u-Boot"
ftl_cs: FTL header not found.
0x000000500000-0x000000a00000 : "uImage"
ftl_cs: FTL header not found.
0x000000a00000-0x000000f00000 : "ramdisk"
ftl_cs: FTL header not found.
0x000000f00000-0x00000d800000 : "image.cfs"
ftl_cs: FTL header not found.
0x00000dd00000-0x00000ec00000 : "rescue firmware"
ftl_cs: FTL header not found.
0x00000ec00000-0x000010000000 : "config"
random: fast init done
ftl_cs: FTL header not found.
0x00000d800000-0x00000dd00000 : "reserve"
ftl_cs: FTL header not found.
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
libphy: Fixed MDIO Bus: probed
libphy: orion_mdio_bus: probed
mvneta f1074000.ethernet eth0: Using hardware mac address 00:50:43:02:00:00
usbcore: registered new interface driver lan78xx
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.usb: EHCI Host Controller
orion-ehci f1050000.usb: new USB bus registered, assigned bus number 1
orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.14.260 ehci_hcd
usb usb1: SerialNumber: f1050000.usb
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-9: WDC WD30EZRX-00DC0B0, 80.00A80, max UDMA/133
ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      WDC WD30EZRX-00D 0A80 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
rtc-mv f1010300.rtc: internal RTC not ticking
i2c /dev entries driver
(NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: [e-mail]
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ledtrig-cpu: registered to indicate activity on CPUs
marvell-cesa f1090000.crypto: CESA device successfully registered
hidraw: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Netfilter messages via NETLINK v0.30.
nfnl_acct: registering with nfnetlink.
nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
arp_tables: arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 10
ata2.00: ATA-9: WDC WD30EZRX-00DC0B0, 80.00A80, max UDMA/133
ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Bridge firewalling registered
8021q: 802.1Q VLAN Support v1.8
Key type dns_resolver registered
Registering SWP/SWPB emulation handler
Loading compiled-in X.509 certificates
armada-370-pinctrl f1018000.pin-ctrl: unsupported function gpio on pin mpp54
pinctrl core: failed to register map default (0): invalid type given
reg-fixed-voltage: probe of regulators:regulator@2 failed with error -22
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access     ATA      WDC WD30EZRX-00D 0A80 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 1:0:0:0: [sdb] 4096-byte physical blocks
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb: sdb1
sd 1:0:0:0: [sdb] Attached SCSI disk
input: gpio-keys as /devices/platform/gpio-keys/input/input0
hctosys: unable to open rtc device (rtc0)
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: autorun ...
md: running: <sdb1><sda1>
md0: detected capacity change from 0 to 6001181851648
md: ... autorun DONE.
EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 9:0.
devtmpfs: mounted
Freeing unused kernel memory: 1024K
INIT: version 2.96 booting
Using makefile-style concurrent boot in runlevel S.
random: crng init done
Files under mount point '/run' will be hidden. ... (warning).
Starting hotplug events dispatcher: systemd-udevd.
Synthesizing the initial hotplug events (subsystems)...done.
Synthesizing the initial hotplug events (devices)...sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
done.
Waiting for /dev to be fully populated...done.
Setting hostname to 'mcm'...done.
Activating swap:.
EXT4-fs (md0): re-mounted. Opts: (null)
Will now check root file system:[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -y -C0 /dev/md0 
e2fsck 1.46.2 (28-Feb-2021)
/dev/md0: clean, 414266/183144448 files, 221525504/1465132288 blocks
.
EXT4-fs (md0): re-mounted. Opts: errors=remount-ro
Will now check all file systems.
Checking all file systems.
UUID=11b0ad4f-fe83-4644-a42b-59f24ec8c048 is mounted
Done checking file systems.
Log is being saved in /var/log/fsck/checkfs if that location is writable.
Cleaning up temporary files...Cleaning /tmp...done.
 /tmp.
Will now mount local filesystems:.
Will now activate swapfile swap, if any:done.
Checking minimum space in /tmp...done.
Cleaning up temporary files....
Starting Setting kernel variables: sysctl.
Initializing random number generator...done.
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Configuring network interfaces...Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:50:43:02:00:00
Sending on   LPF/eth0/00:50:43:02:00:00
Sending on   Socket/fallback
DHCPREQUEST for 10.10.10.219 on eth0 to 255.255.255.255 port 67
mvneta f1074000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
DHCPREQUEST for 10.10.10.219 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.10.10.219 from 10.10.10.10
bound to 10.10.10.219 -- renewal in 34441 seconds.
done.
Starting RPC port mapper daemon: rpcbind.
Starting NFS common utilities: statd idmapd.
Cleaning up temporary files....
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting busybox' syslogd implementation : syslogdStarting /sbin/syslogd...
2250 (syslogd)
.
Not starting NFS kernel daemon: no exports. ... (warning).
Starting automount....
Starting periodic command scheduler: cron.
Starting system message bus: dbus.
Starting MCU control daemon for fan and LEDs: mcm-daemon.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Starting NTP server: ntpd.
Starting busybox' klogd implementation : klogdStarting /sbin/klogd...
2280 (klogd)
.
Starting rsync daemon: rsync.
Starting OpenBSD Secure Shell server: sshd.
Starting S.M.A.R.T. daemon: smartd.
Running local boot scripts (/etc/rc.local)
Cannot read environment, using default
Cannot read default environment from file
<13>Jan  1 01:00:46 root[2437]: Cannot read u-boot env ethaddr
.

Debian GNU/Linux 11 mcm ttyS0

mcm login:

En weer komen we uit in /dev/md0. Ik had bij bootsargs (het is eraf gevallen) een onbestaand pad gegeven als rootfs zodat het duidelijk zou zijn als hij faalde. Maar toch komt /dev/md0 erdoor.

[bucovaina89]

Ja sorry de vorige post van een paar kilobyte was inderdaad fout. Ik had half jouw commando gebruikt met initramfs.gz en dan met mkimage gewoon initramfs als file gebruikt ipv initramfs.gz. Nu is hij ~600kb groot. Nog niet veel maar misschien niet raar met dat het enkel die binary is.

[Mijzelf]

bucovaina89 schreef op zaterdag 1 januari 2022 @ 16:37:
Even onderbreken, niet zeker of dit nu goed dan wel slecht is:

code:

Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 660K

Lijkt me goed. Van de kernel log van mijn server:

code:

[    1.427294] Trying to unpack rootfs image as initramfs...
[    2.434391] Freeing initrd memory: 13532K

Heb wat verder gekeken naar die server:

code:

file -L /boot/uInitrd
/boot/uInitrd: u-boot legacy uImage, uInitrd, Linux/ARM 64-bit, RAMDisk Image (gzip), 13860575 bytes, Sat Aug  7 09:24:29 2021, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0xB5201BF0, Data CRC: 0xDAE81244

code:

binwalk -e /boot/uInitrd
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xB5201BF0, created: 2021-08-07 09:24:29, image size: 13860575 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xDAE81244, OS: Linux, image type: RAMDisk Image, compression type: gzip, image name: "uInitrd"
64            0x40            gzip compressed data, from Unix, last modified: 2021-08-07 09:24:24

code:

file 40
40: ASCII cpio archive (SVR4 with no CRC)

En de meest verassende, ik heb de cpio uitgepakt, en hij bevat geen /sbin/init maar wel een /init. Dus misschien heb ik je iets op de mouw gespeld.

En weer komen we uit in /dev/md0. Ik had bij bootsargs (het is eraf gevallen) een onbestaand pad gegeven als rootfs zodat het duidelijk zou zijn als hij faalde. Maar toch komt /dev/md0 erdoor.

Daar heb je dan iets fout gedaan, want uit je bootlog:

code:

Kernel command line: root=/dev/md0 console=ttyS0,115200 max_loop=32 raid=autodetect

[Thralas]

Mijzelf schreef op zaterdag 1 januari 2022 @ 17:09:
En de meest verassende, ik heb de cpio uitgepakt, en hij bevat geen /sbin/init maar wel een /init. Dus misschien heb ik je iets op de mouw gespeld.

Valt wel mee, bijna alles mag, ook al is /init gangbaar.

TS moet vooral die bootargs weghalen (desnoods disks eruit), fallback naar een andere image is verwarrend.

[ Voor 3% gewijzigd door Thralas op 01-01-2022 17:53 ]

[bucovaina89]

Idd. Ik heb de bootargs nu weg gekregen en ik krijg nu eindelijk een kernel panic wat ik ook verwachtte. Dus niet meer rootfs=/dev/md0


Maar wat neem ik dan wél als rootfs als ik in het initramfs wil booten?

code:

Please append a correct "root=" boot option; here are the available partitions:

Of is het beter van dat idee los te laten en naar ubifs te kijken met de ~200MB partitie in NAND als rootfs?

[Thralas]

Ik heb je stappen even nagelopen.

bucovaina89 in "WD mycloud mirror debricken"

Wat je hier zegt werkt, met één wijziging: je init executable moet /init heten.

En anders, Buildroot:

⇒ Target options
Architecture ARM, Architecture Variant cortex-a9, Enable VFP
⇒ Toolchain ⇒ Kernel headers
Iets dat gelijk of ouder is dan de kernel die je gebruikt (4.14)?
⇒ Filesystem images
cpio the root filesystem, create u-boot image of the root filesystem

.. want handcrafted initrds zijn zonde van je tijd

[ Voor 47% gewijzigd door Thralas op 01-01-2022 22:17 ]

[bucovaina89]

Yay, ik heb van /sbin/init, /init gemaakt en ik krijg dit:

(de install is precies niet zo goed gelukt... )

code:

busybox: /usr/bin/shred: No such file or directory
busybox: /usr/bin/shuf: No such file or directory
busybox: /usr/bin/smemcap: No such file or directory
busybox: /usr/bin/softlimit: No such file or directory
busybox: /usr/bin/sort: No such file or directory
busybox: /usr/bin/split: No such file or directory
busybox: /usr/bin/ssl_client: No such file or directory
busybox: /usr/bin/strings: No such file or directory
busybox: /usr/bin/sum: No such file or directory
busybox: /usr/bin/sv: No such file or directory
busybox: /usr/bin/svc: No such file or directory
busybox: /usr/sbin/svlogd: No such file or directory
busybox: /usr/bin/svok: No such file or directory
busybox: /usr/bin/tac: No such file or directory
busybox: /usr/bin/tail: No such file or directory
busybox: /usr/bin/taskset: No such file or directory
busybox: /usr/bin/tcpsvd: No such file or directory
busybox: /usr/bin/tee: No such file or directory
busybox: /usr/bin/telnet: No such file or directory
busybox: /usr/sbin/telnetd: No such file or directory
busybox: /usr/bin/test: No such file or directory
busybox: /usr/bin/tftp: No such file or directory
busybox: /usr/sbin/tftpd: No such file or directory
busybox: /usr/bin/time: No such file or directory
busybox: /usr/bin/timeout: No such file or directory
busybox: /usr/bin/top: No such file or directory
busybox: /usr/bin/tr: No such file or directory
busybox: /usr/bin/traceroute: No such file or directory
busybox: /usr/bin/traceroute6: No such file or directory
busybox: /usr/bin/truncate: No such file or directory
busybox: /usr/bin/ts: No such file or directory
busybox: /usr/bin/tty: No such file or directory
busybox: /usr/bin/ttysize: No such file or directory
busybox: /usr/sbin/ubiattach: No such file or directory
busybox: /usr/sbin/ubidetach: No such file or directory
busybox: /usr/sbin/ubimkvol: No such file or directory
busybox: /usr/sbin/ubirename: No such file or directory
busybox: /usr/sbin/ubirmvol: No such file or directory
busybox: /usr/sbin/ubirsvol: No such file or directory
busybox: /usr/sbin/ubiupdatevol: No such file or directory
busybox: /usr/bin/udhcpc6: No such file or directory
busybox: /usr/sbin/udhcpd: No such file or directory
busybox: /usr/bin/udpsvd: No such file or directory
busybox: /usr/bin/unexpand: No such file or directory
busybox: /usr/bin/uniq: No such file or directory
busybox: /usr/bin/unix2dos: No such file or directory
busybox: /usr/bin/unlink: No such file or directory
busybox: /usr/bin/unlzma: No such file or directory
busybox: /usr/bin/unshare: No such file or directory
busybox: /usr/bin/unxz: No such file or directory
busybox: /usr/bin/unzip: No such file or directory
busybox: /usr/bin/uptime: No such file or directory
busybox: /usr/bin/users: No such file or directory
busybox: /usr/bin/uudecode: No such file or directory
busybox: /usr/bin/uuencode: No such file or directory
busybox: /usr/bin/vlock: No such file or directory
busybox: /usr/bin/volname: No such file or directory
busybox: /usr/bin/w: No such file or directory
busybox: /usr/bin/wall: No such file or directory
busybox: /usr/bin/wc: No such file or directory
busybox: /usr/bin/wget: No such file or directory
busybox: /usr/bin/which: No such file or directory
busybox: /usr/bin/who: No such file or directory
busybox: /usr/bin/whoami: No such file or directory
busybox: /usr/bin/whois: No such file or directory
busybox: /usr/bin/xargs: No such file or directory
busybox: /usr/bin/xxd: No such file or directory
busybox: /usr/bin/xz: No such file or directory
busybox: /usr/bin/xzcat: No such file or directory
busybox: /usr/bin/yes: No such file or directory
sh: can't access tty; job control turned off
/ #

[bucovaina89]

mkdir -p /usr/bin && mkdir -p /usr/sbin/ fixt bovenstaande

[ Voor 6% gewijzigd door bucovaina89 op 02-01-2022 08:01 ]

[bucovaina89]

@Thralas Kwestie van tijdbesparing: helemaal waar hoor. Maar dan had ik mezelf een tweedehands werkende Synology gekocht . Ik vind het gewoon ook interessant als learning/refresh experience.

[bucovaina89]

als ik in mijn initramfs een file /etc/mdadm/mdadm.conf zet die komt van:

code:

mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Zijn de /dev/mdX devices dan ook altijd fixed? Nu zit ik met het probleem dat mijn rootfs partitie soms /dev/md2 is en soms /dev/md122 en soms /dev/md121

Super irritant want constant kernel panics omdat hij natuurlijk zijn rootfs niet vindt als je het juiste device niet mee kan geven.

[Mijzelf]

bucovaina89 schreef op dinsdag 4 januari 2022 @ 12:27:
Zijn de /dev/mdX devices dan ook altijd fixed?

Blijkbaar niet. Maar kun je hem niet mounten met /dev/disk/by-id/md-<iets> ? En als die niet aanwezig is (ik weet niet hoe mature busybox mdev is, en of die eigenlijk wel wordt aangeroepen) kun je de device vinden met

code:

ROOTDEV=$( mdadm --detail --scan --config=partitions | grep <UUID> | cut -d ' ' -f 2 )

[bucovaina89]

Ik ben hier echt mee aan de knoei geweest afgelopen dagen. Ik heb het zonet opgelost gekregen de wdmcm staat nu te draaien geboot van /dev/md2.

Het was te wijten aan punt 1. Punt 2 heeft me op een dwaalspoor gezet dat lang heeft geduurd.

1. Ik had eerder al een andere array aangemaakt in die host met andere hdd's. Ik had /etc/mdadm/mdadm.conf al gewist maar op een of ander manier kwam er altijd een /dev/md127 tevoorschijn. Nadat ik onderstaande code block uitvoerde niet meer. Dat was de root cause. Ik stak er andere disks in en op een of andere manier dacht de host dat het nog altijd om de oude disks ging. Ik vermoed dat de superblock werd overschreven omdat er op die moment nog iets in [mono]/etc/mdadm/mdadm.conf[/code] stond van de oude arrays. Dit had ik eerder moeten doen om vervuiling van oude naar nieuw arrays te vermijden:
   
   code:
   

   for i in sdb sdc; do
      dd bs=512k if=/dev/zero of=/dev/$i count=10
      dd bs=512 if=/dev/zero of=/dev/$i count=2048 seek=$((`blockdev --getsz /dev/$i` - 2048))
   done
   rm -rf /etc/mdadm/mdadm.conf

2. De 2e disk van de RAID array was defect en vertraagde de boel ENORM. Modale operaties duurden een kwartier (tmux installeren of een gewoon het parted commando hieronder uitvoeren. Dat laatste resulteerde in de screenshot hieronder. Superveel wait states maar echt veel gebeurt er niet terwijl dat op de andere disk een kwestie van seconden was. Ik was niet erg bekend met mdadm en dat heeft me dus erg vertraagd omdat ik er vanuit ging dat die wait states iets waren omdat ik de array niet goed op zette of zo. Ik heb ook ff lopen denken dat het misschien aan de beperkte cpu capaciteit lag. Maar een standaard WD MCM doet dit gewoon ook met een mdadm raid dus dat kon haast niet.

code:

parted -a optimal --script /dev/sdb \
  mklabel gpt \
  mkpart primary 0% 1% \
  mkpart primary 1% 2% \
  mkpart primary 2% 10% \
  mkpart primary 10% 20% \
  mkpart primary 20% 25% \
  mkpart primary 25% 26% \
  mkpart primary 26% 100% \
  set 1 raid on \
  set 2 raid on \
  set 3 raid on \
  set 4 raid on \
  set 5 raid on \
  set 6 raid on \
  set 7 raid on 
mdadm --stop /dev/md*
yes | mdadm --create /dev/md0 -e 0.90 --level=1 --raid-devices=2 /dev/sdb1 missing # kernel
yes | mdadm --create /dev/md1 -e 0.90 --level=1 --raid-devices=2 /dev/sdb2 missing # initramfs
yes | mdadm --create /dev/md2 -e 0.90 --level=1 --raid-devices=2 /dev/sdb3 missing # rootfs
yes | mdadm --create /dev/md3 -e 0.90 --level=1 --raid-devices=2 /dev/sdb4 missing # /var
yes | mdadm --create /dev/md4 -e 0.90 --level=1 --raid-devices=2 /dev/sdb5 missing # /tmp
yes | mdadm --create /dev/md5 -e 0.90 --level=1 --raid-devices=2 /dev/sdb6 missing # swap
yes | mdadm --create /dev/md6 -e 0.90 --level=1 --raid-devices=2 /dev/sdb7 missing # home
mdadm --assemble --scan

[Mijzelf]

@bucovaina89 Jij bent wel dol op scripten, hè?

[bucovaina89]

haha bedoel je de for loop?

[Mijzelf]

Dat is wel een van de symptomen, ja.

[bucovaina89]

Hehe

Ik was ook aan't denken dat die wel wat overkill was maar goed. Verder ben ik helemaal geen scripter hoor

Ik ben er wel een dokuwiki pagina van aan't maken. Ik probeer het zodanig te maken dat ik later relatief eenvoudig kan copy-pasten, wil ik ooit een andere WD my cloud mirror installeren. Nu kost het me een paar weken om elk obstakel uit te zoeken. Ik wil heel deze procedure niet nog eens van 0 aan beginnen

[Mijzelf]

Waar had je de fdt file eigenlijk vandaan?

[bucovaina89]

https://fox-exe.ru/WDMyCloud/Other/Official_linux_kernel/

Die zit mee in mijn dokuwiki

[bucovaina89]

euh een FDT file heb ik btw niet, wel een dts.