Omninas KD20 om zeep geholpen door busybox te wissen

[Verwijderd]

Ik heb een Omninas KD20 die naar volle tevredenheid werkt(e). Bij een fout commando als root heb ik busybox gewist en nu doet geen van de normale functies het meer.

Via een TTL-USB converter heb ik vanaf mijn Linuxbox wel een toegang tot U-boot, maar heb eigenlijk geen idee hoe nou verder. Heeft iemand stap-voor-stap aanwijzingen hoe ik busybox weer geinstalleerd krijg?

Weggooien zou toch zonde zijn.

Paai

[Mijzelf]

Wat geeft 'printenv' en 'help' in de u-boot prompt?

Mogelijk kan hij een rootfs booten van een compatible filesysteem op een usb-stick. In dat geval zou het mogelijk moeten zijn om het interne filesysteem te mounten en er een versie busybox op te zetten.

[Verwijderd]

Hoi,
'help' geeft de lijst met shuttle-commandos, hieronder toegevoegd.
'printenv' heb ik ook toegevoegd.

dhcp werkt en ik kan met tftp bestanden downloaden. Vanaf dat punt zit ik vast: ik weet niet waar ik een nieuwe image moet vinden en dan zou ik niet weten hoe die te starten,

Bijvoorbeeld: ik heb ergens KD20.zip opgeduikeld en uitgepakt op mijn linuxbox. Geen idee wat dat voor bestanden zijn...


drwxrwxr-x 2 paai paai 4096 jul 3 11:35 .
drwxr-xr-x 9 paai paai 4096 jul 8 17:55 ..
-rw-rw-r-- 1 paai paai 0 jun 16 2014 firmware_upgrade_from_usb
-rw-rw-r-- 1 paai paai 2287309 jun 18 2014 rdimg.gz
-rw-rw-r-- 1 paai paai 31867318 jun 18 2014 root.bz2
-rw-rw-r-- 1 paai paai 51642368 jun 18 2014 rootfs.ubi
-rw-rw-r-- 1 paai paai 56000 jun 18 2014 stage1.wrapped-nand
-rw-rw-r-- 1 paai paai 1322208 jun 18 2014 u-boot.wrapped
-rw-rw-r-- 1 paai paai 1322208 jun 18 2014 u-boot.wrapped-nand
-rw-rw-r-- 1 paai paai 3066408 jun 18 2014 uImage


Shuttle>> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
beep - make beep sound
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bubt - Burn an image on the Boot Nand Flash.
clrenv - clear environment
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
dhcp - invoke DHCP client to obtain IP/boot params
diskboot- boot from IDE device
echo - echo args to console
exit - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
ide - IDE sub-system
iminfo - print header information for application image
led - LED Switch
ledfail - Extinguish (0) or light (1) failure LED
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
poweroff- Power-OFF
printenv- print environment variables
part - clear MBR
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version


Boot Menu
==============================================================================
0: Enter Command Line Interface 1: Reboot
2: Start the Kernel Code T: GPIO Test Function

=> Select:
Shuttle>> printenv
bootcmd=run beep select0 load loadr sysled boot || run errled select2 load3 loadr3 ramboot boot
bootdelay=2
baudrate=115200
ethaddr=00:25:b1:ff:ff:00
ipaddr=192.168.0.128
serverip=192.168.0.1
autoload=n
netmask=255.255.0.0
bootfile="uImage"
select0=nand info
select1=ide dev 0
select2=dhcp
loadr=nand read.e 0x62000000 240000 280000
loadr2=ide read 0x62000000 2122 1800
loadr3=tftp 0x62000000 rdimg.gz
load=nand read.e 0x60500000 840000 300000
load2=ide read 0x60500000 50a 1800
load3=tftp 0x60500000 uImage
sysled=led 1
errled=led r
beep=beep
ramboot=setenv bootargs root=/dev/ram0 console=ttyS0,115200 initrd=0x61000000 mem=256M mac_adr=0x00,0x25,0xb1,0xff,0xff,0x00
boot=bootm 60500000 62000000
ft=n
stdin=serial
stdout=serial
stderr=serial
bootargs=root=ubi0:rootfs ubi.mtd=5,512 rootfstype=ubifs initrd=0x61000000 console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x25,0xb1,0xff,0xff,0x00 mem=256M poweroutage=yes

Environment size: 920/8188 bytes

[Mijzelf]

Dat ziet er veelbelovend uit. Normaal gesproken voert u-boot het commando bootcmd uit.

 bootcmd=run beep select0 load loadr sysled boot || run errled select2 load3 loadr3 ramboot boot

Hierbij probeert hij eerst 'run beep select0 load loadr sysled boot ' en als dat mislukt 'run errled select2 load3 loadr3 ramboot boot'.
Als je die commando's opsplits, dan zie je dat de eerste load en loadr doet, die blokken uit nand naar het geheugen kopieert. Dat zijn de kernel en een initramfs, die met 'boot' worden gestart. Wat die initramfs hier precies doet is me niet duidelijk.
Als dat mislukt (en mislukken op een level dat u-boot er nog iets mee kan. Een ontbrekende busybox is véél te laat) voert hij load3 en loadr3 uit. Die halen via tftpt een uImage en rdimg.gz op, van een server met ip 192.168.0.1.
Die twee bestanden zitten in jouw KD20.zip.

Dus je zou eerst een tftp server kunnen optuigen met deze 2 bestanden, en dan

run errled select2 load3 loadr3 ramboot boot

uitvoeren. Kijken hoever je komt.
Met een beetje mazzel kom je in een prompt waar je de ubifs kunt mounten, om vervolgens de busybox uit de rdimg.gz (staat dan gewoon in /bin) erheen te kopiëren. Gezien de grootte van die image zou er wel eens dezelfde busybox op kunnen staan als in de ubifs.

[Verwijderd]

Dank voor je snelle antwoord. Nog een paar vragen voor ik e.e.a. ga uitproberen:

1. je praat over 192.168.0.1. Ik neem aan dat ik met dhcp en setenv serverip a.b.c.d gewoon binnen mijn eigen netwerk kan opereren. a.b.c.d is het ipnummer van de tftp server.

2. ik heb uImage en rdimg.gz op die server staan... hoe weet de Omninas dat? Of moet ik die eerst downloaden voor ik het commando 'run errled select2 load3 loadr3 ramboot boot' geef?

Paai

[Mijzelf]

1) Ja. Het is mogelijk dat je moet rebooten na het zetten van het ip. Dat is dan dus

setenv serverip a.b.c.d
saveenv
reset

2) Dat weet hij niet. Hij vraagt gewoon aan de tftpserver om het bestand uImage. Als die er niet is wordt er niet geboot.

[Verwijderd]

Probleem met serverip: als ik dat op 192.168.178.15 heb gezet, en ik doe dan saveenv en reset, dan geeft printenv na de reset braaf 192.168.178.15 terug. so far so good.

het commando 'run errled select2 load3 loadr3 ramboot boot' daarna zet het weer glashard op 192.168.178.1

[Mijzelf]

'Terug' op 192.168.178.1? De standaard waarde is 192.168.0.1. Dus blijkbaar haalt hij wel een tftp server uit dhcp. 192.168.178.1 is je router, neem ik aan?

Wat je kunt doen is zowel serverip als ipaddr een goede waarde geven, en dan

run errled load3 loadr3 ramboot boot

uitvoeren. De select2 is weggelaten, en daarmee is denk ik dhcp uitgezet.

[Verwijderd]

ja, dat geeft een hoop activiteit en dan doorlopend de melding /etc/nasd: line 1: inotifywait: not found

paar keer op ctrl-c en ctrl-d geduwd en nu krijg ik een login prompt. root en mijn eigen naam vragen om password (het oude password heb ik uiteraard, maar dat werkt niet) en 'admin' heeft per default geen password op de omninas, maar dat geeft:

nas.mydomain.com login> admin
login: can't chdir to home directory '/share/atonnas'
login: cannot run /sbin/nologin: No such file or directory

[Mijzelf]

Oh? Vreemd. Je zou verwachten dat die rdimg.gz een compleet systeem is. Maar blijkbaar bevat hij een script die probeert een niet-meegeleverde inotifywait uit te voeren.

De standaard truuk om op een systeem te komen waarvan je het root wachtwoord niet weet is een shell starten in plaats van init. Normaal start de kernel als hij zover is en het rootfs is gemount /sbin/init op, en deze executable start de rest van het systeem. (Daarom doet je NAS het ook niet meer, /sbin/init is waarschijnlijk ook een incarnatie van busybox.)
In de commandline kun je dat overrulen.
Dus voeg een environment variable toe:

setenv hackboot setenv bootargs root=/dev/ram0 init=/bin/sh console=ttyS0,115200 initrd=0x61000000 mem=256M
saveenv

Ik heb dus de variabele ramboot gekopieerd, die de commandline zet voor de kernel, en daar init=/bin/sh aan toegevoegd.
Nu kun je de NAS starten met

run errled load3 loadr3 hackboot boot

Als het goed is zou je in een shell moeten belanden.

[Verwijderd]

Er is leven na de dood!

Ik zit nu in een root shell. En /bin/busybox bestaat. Nu zou ik dus ubifs moeten mounten, maar ik zie geen ubifs in /dev, aangenomen dan dat ik daar zou moeten kijken.

[Mijzelf]

Ik denk niet dat /dev 'autopopulerend' is. Er draait helemaal niets, behalve de shell.
Kijk eens of je iets ziet met

mount -t proc proc /proc
cat /proc/partitions

[Verwijderd]

autopopulerend... die houden we er in :-)


/ # cat /proc/partitions
major minor #blocks name

31 0 131072 mtdblock0
31 1 256 mtdblock1
31 2 2048 mtdblock2
31 3 6144 mtdblock3
31 4 7936 mtdblock4
31 5 114688 mtdblock5


vanaf nu moet ik mijn vrouw een paar uur assisteren met gasblazen. Met dit weer voor een smeltoven van 1150 graden...

[Mijzelf]

Sterkte.

Ik moet eerlijk toegeven dat ubi een beetje voodoo voor mij is. 'Vroeger' mountte je gewoon een mtdblock, maar met ubi gaat dat niet.
Het is duidelijk dat mtdblock5 het gewenste ubifs bevat, maar er moet ook een ubiblock zijn.
Ik heb hier even op een apparaat met een ubifs gekeken (mijn router), en die zegt dit:

code:

~# cat /proc/partitions 
major minor  #blocks  name

  31        0        256 mtdblock0
  31        1        128 mtdblock1
  31        2       2048 mtdblock2
  31        3     128640 mtdblock3
 254        0       3780 ubiblock0_0

Die ubiblock0_0 moet zich fysiek in mtdblock3 bevinden. De size slaat nergens op, het ding is 110684 blocks.

code:

~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 3840      3840         0 100% /rom
tmpfs                    60968       116     60852   0% /tmp
/dev/ubi0_1             110684      9432     96416   9% /overlay
overlayfs:/overlay      110684      9432     96416   9% /
tmpfs                      512         0       512   0% /dev

En het gemounte device heeft een major:minor die afwijkt van wat 'cat /proc/partitions' zegt:

code:

~# grep ubi /proc/mounts
/dev/ubi0_1 /overlay ubifs rw,noatime 0 0
~# ls -l /dev/ubi0_1
crw-------    1 root     root      251,   2 Jan  1  1970 /dev/ubi0_1

Nou ja, eerst maar eens zien dat je een ubiblock in /proc/partitions krijgt. De default commandline voor die nas is

code:

bootargs=root=ubi0:rootfs ubi.mtd=5,512 rootfstype=ubifs initrd=0x61000000 console=ttyS0,115200

Ik denk dat die ubi.mtd=5,512 de kernel vertelt op welke mtdblock een ubi zit, en die 512 zal wel iets zeggen over erase size of zo.
Dus ik stel voor dat je ubi.mtd=5,512 aan je commandline toevoegd:

setenv hackboot setenv bootargs root=/dev/ram0 init=/bin/sh ubi.mtd=5,512 console=ttyS0,115200 initrd=0x61000000 mem=256M
saveenv

[Verwijderd]

Ik heb je aanwijzingen opgevolgd. ik ben een redelijk ervaren Linuxgebruiker (vanaf 1992) en applicatieprogrammeur, maar dit is allemaal russisch voor mij. Ik heb hetzelfde gevoel als wanneer ik naar een Android filesysteem kijk: waarom zo ingewikkeld?

Ennieweej. Ik stel je hulp zeer op prijs.

cat /proc/partitions geeft dezelfde partities als voorheen.

Ik zou dus een ubifs moeten mounten om bij het oorspronkelijke filesysteem te kunnen komen en er een nieuwe busybox heen te copieeren, maar waar?

(en wat is eigenlijk die NAND waar iedereen het over heeft? Een pointer naar wat inleesliteratuur zou ik fijn vinden).

In de bootmessages kwamen een aantal regels met 'UBI' voorbij:

[ 3.420000] Creating 5 MTD partitions on "NAND 128MiB 3,3V 8-bit":
[ 3.420000] 0x000000000000-0x000000040000 : "Stage-1"
[ 3.430000] 0x000000040000-0x000000240000 : "U-Boot"
[ 3.440000] 0x000000240000-0x000000840000 : "INITRD"
[ 3.440000] 0x000000840000-0x000001000000 : "Kernel"
[ 3.450000] 0x000001000000-0x000008000000 : "Root"
[ 3.460000] UBI: attaching mtd5 to ubi0
[ 3.460000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 3.470000] UBI: logical eraseblock size: 129024 bytes
[ 3.470000] UBI: smallest flash I/O unit: 2048
[ 3.480000] UBI: sub-page size: 512
[ 3.480000] UBI: VID header offset: 512 (aligned 512)
[ 3.490000] UBI: data offset: 2048
[ 3.870000] UBI: attached mtd5 to ubi0
[ 3.880000] UBI: MTD device name: "Root"
[ 3.880000] UBI: MTD device size: 112 MiB
[ 3.890000] UBI: number of good PEBs: 895
[ 3.890000] UBI: number of bad PEBs: 1
[ 3.900000] UBI: max. allowed volumes: 128
[ 3.900000] UBI: wear-leveling threshold: 4096
[ 3.910000] UBI: number of internal volumes: 1
[ 3.910000] UBI: number of user volumes: 1
[ 3.910000] UBI: available PEBs: 0
[ 3.920000] UBI: total number of reserved PEBs: 895
[ 3.920000] UBI: number of PEBs reserved for bad PEB handling: 8
[ 3.930000] UBI: max/mean erase counter: 8/4
[ 3.930000] UBI: image sequence number: 0
[ 3.940000] UBI: background thread "ubi_bgt0d" started, PID 315

[Mijzelf]

NAND is een vorm van flashgeheugen. Bij mijn weten altijd serieel aangestuurd, en kan niet zomaar beschreven worden. Je kunt alleen van een 0 een 1 maken, maar niet omgekeerd. Als je terug wilt, moet je een heel blok van typisch iets van 64k wissen, en dat laatste kan maar een beperkt aantal keren gebeuren. (orde honderden of duizenden per blok).
Klassieke filesystemen zouden heel snel door de maximale erase cycli heen zijn (denk aan de dirty bit van FAT, ofzo) en dus zijn er allerlei speciale filesystemen voor rauwe flash ontwikkeld (yaffs,jffs,logfs) die ingebouwde wear leveling hebben. Ubifs is de nieuwste, bij mijn weten, die draait op een ubi, wat een abstraction layer is die voor wear leveling zorgt. Ofzo.


Anyway, volgens je bootlog is de UBI geinitialiseerd (was daar die command line parameter voor nodig?). Als ik het wel heb kun je nu

mount -t sysfs sysfs /sys
ls -l /sys/class/ubi

wat het ubiblock en de partities daarop laat zien. Als je meer dan 1 partitie hebt kun je met

cat /sys/class/ubi/ubi0_*/data_bytes

de groottes zien. En, belangrijk, met

cat /sys/class/ubi/ubi0_*/dev

kun je de major en minor zien.
Vervolgens maak je een device node

mknod /dev/ubi0_0 c major minor

(ja, het is een character device) en kun je het hopelijk mounten

mkdir /tmp/mountpoint
mount -t ubifs /dev/ubi0_0 /tmp/mountpoint

[Verwijderd]

mountpoint /sys bestond niet, heb het aangemaakt.

Een irritant secundair probleem is dat de communicatieparameters schijnen te veranderen, in ieder geval krijg ik na een tijdje steeds meer onzin op het scherm tot het onleesbaar wordt. En dan moet ik weer terug en rebooten enzo... rommelen met baudrates van screen of minicom helpt niet. heb je daar een snelle suggestie voor?

Ik /denk/ dat ik er bijna ben.

[Thralas]

Mijzelf schreef op zondag 22 juli 2018 @ 07:47:
Anyway, volgens je bootlog is de UBI geinitialiseerd (was daar die command line parameter voor nodig?).

De parameter ubi.mtd doet inderdaad een attach van de gespecificeerde MTD device. Kan ook vanuit userspace met ubiattach.

Dat levert de 'UBI: attaching..'-riedel op. Hierna kun je zaken mounten.

Als ik het wel heb kun je nu

mount -t sysfs sysfs /sys
ls -l /sys/class/ubi

wat het ubiblock en de partities daarop laat zien. Als je meer dan 1 partitie hebt kun je met

cat /sys/class/ubi/ubi0_*/data_bytes

de groottes zien. En, belangrijk, met

cat /sys/class/ubi/ubi0_*/dev

kun je de major en minor zien.

Alles wat je nodig hebt vertelt UBI je ook bij de attach in de kernel log. En als je een redelijke set ubi utils hebt dan is ubinfo ook wel handig..

Vervolgens maak je een device node

mknod /dev/ubi0_0 c major minor

(ja, het is een character device) en kun je het hopelijk mounten

mkdir /tmp/mountpoint
mount -t ubifs /dev/ubi0_0 /tmp/mountpoint

Als je die chardev niet vanzelf krijgt omdat je geen werkende udev hebt kun je ook als volgt het ubi device (ubi0) en volume (0) specificeren:

mount -t ubifs ubi0_0 /tmp/mountpoint

Het is duidelijk dat mtdblock5 het gewenste ubifs bevat, maar er moet ook een ubiblock zijn.

Let op dat UBI twee verschillende volume types kent. Enerzijds geemuleerde block devices (ubiblock), maar ook het eigen filesystem (ubifs). Je kunt ze naast elkaar gebruiken.

Hier is maar een volume, en dat is een ubifs (zie rootfstype). Van ubiblock is dus geen sprake.

Dit moet genoeg zijn om het rootfs te mounten en de boel te repareren (als je tenminste de busybox executable nog hebt, degene die in de initrd zit identiek is, of anders eentje uit die firmware image).

---

Als dat alles niet wil dan zou ik vanuit uboot je NAND backuppen, en vervolgens de rootfs uit de firmware (en/of kernel en ramdisk) wegschrijven.

Zolang je qua addressering tussen 0x000000240000-0x000008000000 blijft heb je altijd een u-boot shell om op terug te vallen. En hopelijk een backup van het hele NAND voor je besluit zaken te overschrijven

[Verwijderd]

Op dit ogenblik is de seriele connectie mijn grootste probleem, zowel met 'screen', minicom en de serial window van de Arduino IDE. Uiteraard allerlei baudrates en stopbits geprobeerd...

[Mijzelf]

Verwijderd schreef op zondag 22 juli 2018 @ 09:47:
Een irritant secundair probleem is dat de communicatieparameters schijnen te veranderen, in ieder geval krijg ik na een tijdje steeds meer onzin op het scherm tot het onleesbaar wordt. En dan moet ik weer terug en rebooten enzo... rommelen met baudrates van screen of minicom helpt niet. heb je daar een snelle suggestie voor?

Klinkt als een zwevende aarde, of zo. Je hebt 3 draden aangesloten, en die zitten goed?

[Verwijderd]

ground, TX en RX... maar hij doet het voorlopig weer. Ik heb het idee dat het chassis van de Omninas even aanraken helpt.


Ik zit nu bij

/ # mount -t ubifs /dev/ubi0_0 /tmp/mountpoint

maar dat werkt niet, hoewel /dev/ubi0_0 bestaat.


[ 135.950000] UBIFS error (pid 337): ubifs_get_sb: cannot open "/dev/ubi0_0", error -22
mount: mounting /dev/ubi0_0 on /tmp/mountpoint failed: Invalid argument


/ # ls -la /dev/ub*
crw-r--r-- 1 root root 253, 1 Jan 2 00:01 /dev/ubi0_0
/ #

[Mijzelf]

Bij mij heeft ubi0_0 een major van 251

[Verwijderd]

Aangenomen dat het commando


/ # cat /sys/class/ubi/ubi0_*/dev

correct is. Het geeft het

253:1

terug.

[Mijzelf]

~# cat /sys/class/ubi/ubi0_0/dev
251:1

Misschien is die manier om aan de major:minor te komen niet bulletproof. Het kan geen kwaad 251 te proberen, lijkt me.
Of je probeert het voorstel van @Thralas , en geeft gewoon ubi0_0, alsof je neus bloedt.

[Verwijderd]

...mijn neus bloedt...

En de ellende begon indertijd met een vergissing in het dynamic linken van more naar busybox. En wat zie ik: een bestand 'more' in /tmp/mountpoint/bin dat even groot is als de busybox in /bin.

Met kloppend hart ga ik de Ominas weer booten. Ik houd jullie op de hoogte.


De Omninas boot een heel eind, maar blijft nog hangen op een eindeloze reeks

Sending select for 192.168.178.152...
Received DHCP NAK
Sending discover...

[ Voor 59% gewijzigd door Verwijderd op 22-07-2018 20:22 ]

[Mijzelf]

Hangt hij wel aan de DHCP server?

[Verwijderd]

Ik ben eruit geloof ik. Of liever gezegd: ik ben erin.

Nadat ik de twee harde disks erin had gezet is hij helemaal doorgeboot en kan ik gewoon inloggen. Wel lijk ik de inhoud van de twee disks kwijt te zijn. Maar dat is van later zorg, al houd ik me aanbevolen voor goede raad.

Ik wil jullie van harte bedanken voor de goede raad en het geduld. Een hoop bijgeleerd.

Een korte samenvatting voor de volgende idioot die z'n busybox vernaggelt:

1. soldeer pinnetjes op gaatje 2,3 en 4 van de rij van vijf lege gaatjes op het moederbord. Verbind die met een TTL-USB convertor en start screen of minicom.

2. installeer tftp en plaats de inhoud van bestand KD20.zip in /srv/tftp.

3. start de omninas en drup op een toets als de eerste meldingen komen. Kies '0' voor de shuttle-commandline.

4. haal met dhcp een IP nummer voor de omninas en plaats het IP nummer van de tftp server (a.b.c.d) in de environment:

setenv serverip a.b.c.d
saveenv
reset

5. zet de volgende gegevens in de environment:

setenv hackboot setenv bootargs root=/dev/ram0 init=/bin/sh ubi.mtd=5,512 console=ttyS0,115200 initrd=0x61000000 mem=256M
saveenv

6. boot vanaf de ftpserver

run errled load3 loadr3 hackboot boot


Een hoop activiteit en dan krijg je een shell.


7. maak een mountpoint voor sys en mount sysfs.

mount -t proc proc /proc

mkdir /sys
mount -t sysfs sysfs /sys

8. haal de minor en major van het ubi filesysteem

cat /sys/class/ubi/ubi0_*/dev
mknod /dev/ubi0_0 c 253 1

9. Hier lopen de meningen uiteen. Voor mij werkte:

mkdir /tmp/mountpoint
mount -t ubifs ubi0_0 /tmp/mountpoint


10. Inspecteer je oorspronkelijke filesysteem en zet een nieuwe busybox erop.

[Mijzelf]

Verwijderd schreef op zondag 22 juli 2018 @ 20:49:
Wel lijk ik de inhoud van de twee disks kwijt te zijn.

Zaten de schijven erin toen je rdimg.gz bootte? Ik zou me kunnen voorstellen dat de functie van de scripts daarin is om een maagdelijke nas te maken. Namelijk haal op de één of andere manier de andere files uit KD20.zip op, en flash ze. En formatteer de schijven, als je toch bezig bent.

Als de schijven er niet inzaten, zie ik geen direct verband met het wissen van busybox. Het enige is een mogelijke kleine filesystem error, omdat netjes afsluiten er niet meer bij was, natuurlijk.

[Verwijderd]

Nah, de schijvel (b)leken leeg te zijn. Met de webinterface een nieuwe JBOD aangemaakt en geformatteerd. Leek goed gegaan te zijn. Maar bij het terugcopieeren van de backup ging er iets mis en nu boot hij weer in een eindeloze reeks

Sending select for 192.168.178.152...
Received DHCP NAK
Sending discover...

dat zie ik op de TTL, want normaal inloggen gaat weer niet.

Op dit ogenblik zitten er twee HD's in van type Linux (83) maar zonder filesysteem. Als het aan mij ligt blijven het twee aparte ext2 disks, in plaats van een grote JBOD.

[ Voor 18% gewijzigd door Verwijderd op 23-07-2018 18:13 ]

[Mijzelf]

De loop die je geeft heeft de verkeerde volgorde, denk ik. Het is

Sending discover...
Sending select for 192.168.178.152...
Received DHCP NAK

Hij doet een broadcast naar een DHCP server, die antwoord met 'ja, ik ben DHCP server, en biedt je een IP adres aan, daarop zend de NAS een bericht met 'ik accepteer het IP adres', en de server zegt dan 'oh nee. toch niet'.

Ik zou niet weten wat deze loop veroorzaakt. Als je erop googled vind je dat het vaker gebeurt. De broncode van busybox suggereert dat het een timeout zou kunnen zijn. (regel 1497).

Heb jij de busybox uit initrd.gz gebruikt, of die 'move' terug gerenamed? Het zouden verschillende versies kunnen zijn, die verschillend omgaan met dit probleem.

Ik vraag me af of er een verband is met je seriële poort probleem. Als de seriële communicatie verminkt raakt door electrische ladingen, zou dat natuurlijk voor netwerk communicatie ook kunnen gelden. Heb je een aardedraad losgehaald, of heb je een aardlus gemaakt?

[Verwijderd]

Ik heb de oude 'more' teruggecopieerd, dus dat zou het niet kunnen zijn. Het probleem met de TTL was toch weer een stukje soldeer dat niet pakte en dat is nu definitief opgelost.

De oorspronkelijke configuratie van de Omninas was dat ik een static IP nummer had toegekend. Toen het twee dagen geleden opeens prima liep had hij niet alleen mijn passwords onthouden, maar ook dat IP nummer.

Daarna heb ik de harde disks via de webinterface opnieuw als JBOD geconfigureerd en geformat. Dat leek gelukt en de JBOD liet zich ook beschrijven. Er was een cifs drive '/Omninas' op een PC gemount die naar de JBOD op de Omninas wees en ik gaf het commando 'cp /Backup /Omninas. Toen ik wat later ging kijken hing dat proces en de Omninas wilde niet meer vanzelf booten en bleef hangen in die dhcp request.

in /tmp/mountpoint/etc/network/interfaces heb ik de static informatie gezet. Haalt niet uit.

Wat ik nu dus nodig zou hebben is een manier om de Omninas te dwingen static Ip adres aan te nemen in plaats van rond te gaan rennen en om een dhcp adres te roepen.


BTW: de ellende begon toen ik 'more' wilde toevoegen, maar nu zie ik dat deze busybox helemaal geen more heeft!

UPDATE: het plaatsen van KD20.zip op een fat32 stick en daarmee booten werkt ook niet. De usb wordt klaarblijkelijk niet gelezen voordat de foute busybox is gestart.

Nieuwe vraag is dus: hoe kan ik de firmware uit KD20.zip (op de tftp server) over de oorspronkelijke heen schrijven zonder de usb?

[ Voor 23% gewijzigd door Verwijderd op 25-07-2018 13:06 ]

[Verwijderd]

Ik ben nu rond.

Nadat de busybox niet meer wilde functioneren heb ik zoals boven beschreven het KD20 systeem via tftp gemount en daarna de Omninas onder /tmp/mountpoint.

Vervolgens de /usr, /bin, /sbin, /lib en /etc directories met 'cp -dr ' van het KD20 systeem naar /tmp/mountpoint gecopieerd.

Nu gedroeg de Omninas zich na rebooten normaal. Alleen de website wilde niet functioneren. De php-files zitten in /usr/htdocs, maar er was ergens iets mis, want hij bleef maar de JBOD setup checken.

Handmatig http://192.168.178.150/admin.php aangestuurd. Die vroeg om het password en ziedaar, alles was weer in orde en ik kon via de website een static adres maken.

Box weer in elkaar gezet. Wel de TTL stekkertjes eruit laten bungelen, je kennie weete...


Nu ben ik weer zo ver als twee maanden geleden: een naar tevredenheid werkende NAS met root access. MAAR NOG STEEDS GEEN 'more'.


Iedereen nog bedankt voor de hulp en als iemand een truc weet om toch nog een 'more' te kunnen gebruiken, dan graag!

[ Voor 4% gewijzigd door Verwijderd op 02-08-2018 17:24 ]

[Thralas]

Verwijderd schreef op donderdag 2 augustus 2018 @ 17:23:
Iedereen nog bedankt voor de hulp en als iemand een truc weet om toch nog een 'more' te kunnen gebruiken, dan graag!

Waarom is more zo heilig? Is er ook geen less beschikbaar?

Anyhow, gewoon een kwestie van een extra busybox neerplempen, en daarbij de oude vooral niet overschrijven. Noem 'm busbox2, en symlink dan more ernaartoe.

[Verwijderd]

Ook geen less, dat had ik al gecheckt. Maar ik zie nu dat er een awk in zit, dus dat probleem is ook opgelost.

Overigens, waar zou ik zo'n nieuwere busybox vandaan moeten halen?

[Mijzelf]

Bijvoorbeeld hier.

[Thralas]

Of bij de mensen van busybox zelf: https://busybox.net/downl...-multiarch/busybox-armv5l

[lnxuser]

Ik heb ook mijn KD20 om zeep geholpen omdat ik er Debian op wilde zetten.
Daarbij heb zonder te weten een U-boot er opgezet van een PogoPro (ook oxnas chip), maar die bleek helemaal niet geschikt te zijn voor een KD20. Bij het maken van de backup van de originele mtd0 device met nanddump --noecc --omitoob -f mtd0 /dev/mtd0
stond ik nog in /tmp en die backup is er dus niet meer . Ik kan via een speciale sata disk met eigen u-boot opstarten, maar ik zoek dus een kopie van de (factory) mtd0 zodat ik die terug kan zetten.

Het lukt me ook wel met de hier eerder beschreven procedure in een shell te komen, maar voor zo ver ik kan nagaan (of begrijp zitten er in het kd20.zip archief niet de images om een vernaggelde NAND opnieuw in te richten met een werkende image.
Maar wie weet heb ik dat niet goed. Ik schat in dat het terugzetten van een mtd0 eenvoudiger is. Maar dan moet ik er wel een hebben
Kortom, wie helpt?

lnxuser

[Thralas]

lnxuser schreef op woensdag 1 juli 2020 @ 22:00:
maar voor zo ver ik kan nagaan (of begrijp zitten er in het kd20.zip archief niet de images om een vernaggelde NAND opnieuw in te richten met een werkende image.

Waarom niet?

NAND map:

code:

[ 3.420000] 0x000000000000-0x000000040000 : "Stage-1"
[ 3.430000] 0x000000040000-0x000000240000 : "U-Boot"
[ 3.440000] 0x000000240000-0x000000840000 : "INITRD"
[ 3.440000] 0x000000840000-0x000001000000 : "Kernel"
[ 3.450000] 0x000001000000-0x000008000000 : "Root"

stage1 en uboot zitten gewoon in kd20.zip, toch?

Verwijderd in "Omninas KD20 om zeep geholpen door busybox te wissen"

[lnxuser]

stage1 en uboot zitten gewoon in kd20.zip, toch?

Dat dacht ik ook, maar ik kan niets vinden wat er ook maar in de verte op lijkt.
De bestanden: stage1.wrapped-nand, u-boot.wrapped en u-boot.warpped-nand zijn alleen maar bitmaps bestaande uit patronen 0x55 en 0xAA (01010101 en 10101010) en de uImage bevat de originele kernel voor zo ver ik kan zien. Maar dus geen Stage-1, U-boot en Initrd....

Zie ook hier: Omninas KD20 bricked

Ik heb trouwens, heel eigenwijs, toch wel deze wrapped images te flashen omdat ik mijn NAND toch al verklooid had. Het leverde niets op.

Ik heb meer kapot gemaakt dan Paai destijds, die had alleen een stukje linux per ongeluk ¨weggeggooid¨. Dat kon hij weer terug halen uit die kernel. Maar ik heb per abuis een verkeerde U-boot geflashed.
Die start op en dan hangt ie meteen. Als ik er een sata bootable disk, die kun je zo prepareren dat ie de interne NAND niet gebruikt, in doe wordt wel de stage1 en de uboot van die disk ingelezen, maar er wordt geen disk gedetecteerd. Nogal raar, geen idee waarom, maar hij boot in ieder geval niet verder met de Debian versie op de disk.
Ik kan dan via de U-boot shell met ftp wel iets werkend krijgen, en dan gebruikt ie gewoon de Debian die op de disk staat, die niet herkend werd , maar dat is nogal omslachtig.
Als alternatief moet het mogelijk zijn autonoom van de sata disk te kunnen opstarten zonder omwegen, maar dat lukt tot dusver niet echt.

Dus eerst terug naar een werkende fabrieksinstelling zou ook al helpen.

Wellicht dat ik iets moet doen met de variabelen die in de environment staan, maar ik ben niet voldoende thuis in deze materie. Daar komt ook nog bij dat het me niet lukt de gedane aanpassingen die wel werken permanent te maken.

Het lukte me ook om een shell te krijgen met de methode die paai beschreef. Maar ook dan ben ik niet genoeg ingevoerd in embedded linux configuraties om daar iets terug te vinden dat ik naar /dev/mtd0 zou moeten of kunnen overzetten. Even los van het feit dat de tools on NAND te bewerken niet in deze linux kernel zitten.

Vandaar.....

[Thralas]

lnxuser schreef op donderdag 2 juli 2020 @ 23:06:
De bestanden: stage1.wrapped-nand, u-boot.wrapped en u-boot.warpped-nand zijn alleen maar bitmaps bestaande uit patronen 0x55 en 0xAA (01010101 en 10101010)

Klopt helemaal. Dat is hoe de images 'gewrapt' zijn. 0x55 is een '1', 0xaa een '0' in de originele image. Acht bytes voor iedere originele byte. Zal met resistentie tegen datacorruptie te maken hebben.

De bootrom verwacht stage1 exact zo op de NAND (op offset 0). Die gebruikt dezelfde encoding om u-boot te laden. Je kunt ze dus gewoon as-is wegschrijven.

[lnxuser]

Dat is info, die ik nog niet had.
Dus als ik het goed begrijp kan ik vanuit een Linux shell (dat lukt wel).
met:
/usr/sbin/flash_erase /dev/mtd0

en dan:
/usr/sbin/nandwrite -p /dev/mtd0 stage1.wrapped-nand

en

/usr/sbin/nandwrite -p /dev/mtd0 u-boot.wrapped-nand
Of wellicht is het dev/ubi ?

e.e.a. weer terugzetten?

Maar voor die u-boot moet er vast een extra offset of iets van dien aard meegegeven worden want anders wis ik de stage1 weer toch, tenzij het ubi is natuurlijk?

Klinkt goed! Nu alleen nog de details ....

[Thralas]

lnxuser schreef op vrijdag 3 juli 2020 @ 10:19:
Maar voor die u-boot moet er vast een extra offset of iets van dien aard meegegeven worden want anders wis ik de stage1 weer toch, tenzij het ubi is natuurlijk?

Daarom moet je even kijken welke partities je moet hebben. Zie /proc/mtd. Dan kun je ze gewoon naar de juiste partitie schrijven. Is ook handig met erasen, anders erase je namelijk ook al snel teveel.

De kernel output uit m'n eerdere posts suggereert dat er maar 5 partities zijn, maar als ik m'n notities erop nasla dan is mtd0 de hele nand en mtd1/mtd2 stage1 resp. u-boot. Even kijken wat /proc/mtd zegt dus.

[lnxuser]

Voor mij is nog steeds allemaal een flinke puzzle. Ik heb in het verleden gewerkt met microprocessor en schreef programma´s in assembler.
Dus ik kan wel volgen hoe je kan of moet jongleren met geheugen etc. Maar ik mis nu nog een begrijpelijk overzicht hoe e.e.a. in elkaar zit.

Ik begrijp dat NAND beschreven wordt op een bepaalde manier (serieel?). Maar dat wordt in de praktijk opgelost door de tools: nanddump, nandearase, nandwrite etc.
Dan wordt het voor mij weer min of meer ¨bekend¨ terrein...
Alleen is het dan wel handig om te weten welke gebieden van het NAND geheugen bedoeld zijn voor wat.

Ik snap ook nog niet wat dan precies wrapped is. Jouw uitleg dat het met robuustheid van doen heeft begrijp ik niet helemaal.
Wat ik er van weet is dat je altijd crc checks of hashes kunt genereren van blokken data. Los van hoe ze er in werkelijkheid uit zien.
Een ander punt wat ik dan niet snap is dat ik ook andere u-boot en stage1 images heb waarin je gewoon met hexedit kunt kijken en daar zie ik wel machinetaal staan en leesbare en herkenbare ASCII strings.
En het nandwrite commando kent voor zo ver ik weet geen opties om daar rekening mee te houden door dergelijk ¨gewrapte¨ images al dan niet te converteren.

Dus de puzzel is vast wel te leggen, maar ik mis nog best veel stukjes.

Wat ik zie in een linux prompt:
cat /etc/fw_env.config
# MTD device name Device offset Env. size Flash sector size Number of sectors
# pogoplug pro
/dev/mtd0 0x00100000 0x20000 0x20000

en

cat /proc/mtd
dev: size erasesize name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "ubi"

De inhoud van fw_env.config vertrouw ik eigenlijk gewoonweg niet want dat bestand dateerd van 2014. Terwijl de systeemtijd gewoon UTC is. Dus dat is alleen maar de weergave van aangeleverde info.
NB er staat ook pogoplug pro. Dat klopt want die maakt gebruik van dezelfde CPU, OXNAS 7820
Alleen voor de KD20 is er vrijwel geen kant en klaar materiaal of detail info beschikbaar.

De output van cat /proc/mtd vertrouw ik iets meer want tijdens het booten wordt dat gegenereerd:

[ 1.239761] Creating 2 MTD partitions on "41000000.nand":
[ 1.245173] 0x000000000000-0x000000e00000 : "boot"
[ 1.271055] 0x000000e00000-0x000008000000 : "ubi"

Ik zie alleen geen /mtd1 of hoger. Alleen maar ¨ubi¨, misschien is dat dan bedoeld voor de u-boot image.
Maar wellicht komt het ook deels voort uit wat er in fw_env.config staat en is niet in een formaat dat aansluit bij wat bij de KD20 gebruikelijk is.

En dan de getallen die er bij worden aangegeven:

Dat de stage1 moet beginnen op adres 0x00000 van de NAND is voor de hand liggend.
Wat ik nog even niet kan plaatsen is de getallen die worden aangegeven:
Ik veronderstel dat: [ 1.239761] Creating 2 MTD partitions on "41000000.nand":

aangeeft dat de NAND in het systeem fysiek begint op adres 0x41000000. Of dat correct is weet ik niet, maar voor wat ik wil kunnen doen, terugschrijven van een image naar de juiste plek, maakt dat niet zo veel uit denk ik.

Vervolgens wordt er door de kernel een ¨boot¨ gebied toegewezen van 0x000000000000-0x000000e00000 in de MTD maar dan welke MTD of MTD´s, waarschijnlijk mtd0, maar dat zie ik nergens als zodanig aangegeven.
En waar moet stage1 dan komen? Dat zou ik wel er voor verwachten.

Of moet ik het wat anders beschouwen:

Van 0x000000000000-0x000000e00000 is de ruimte bedoeld stage1 en daarna met een offset van 0x000000e00000 geteld vanaf 0x000000000000 wordt het gebied, met een omvang van eveneens 0x000000e00000 toegekend aan ¨boot¨?

Wat daar niet voor pleit is dat de ruimte gereserveerd voor ¨boot¨ (images?) en ¨stage1¨ dan hetzelfde zijn. Dat is in de praktijk voor zo ver ik weet vrijwel nooit zo. een stage1 image is meestal vele malen kleiner dan een u-boot image.

Alles bij elkaar zijn heb ik nog wel héél veel vragen waar ik geen antwoord voor heb.

Maar belangrijker nog: waarom heb ik ook stage1/uboot images die ¨herkenbaar zijn¨ en waarom zijn deze die ik heb ¨gecodeerd¨ (wrapped) en kan ik daar nergens iets over vinden?

Maar wel prettig om niet alles alleen uit te hoeven zoeken!
Bedankt voor je reacties en suggesties tot zover!

[Thralas]

lnxuser schreef op vrijdag 3 juli 2020 @ 14:17:
Ik begrijp dat NAND beschreven wordt op een bepaalde manier (serieel?).

Plain old NAND is parallel.

Maar dat wordt in de praktijk opgelost door de tools: nanddump, nandearase, nandwrite etc.
Dan wordt het voor mij weer min of meer ¨bekend¨ terrein...
Alleen is het dan wel handig om te weten welke gebieden van het NAND geheugen bedoeld zijn voor wat.

Klopt. En bij NAND is er meestal geen expliciete partitietabel: dat zit hardcoded in je bootloader, kernel, etc. - dus daar ben je van afhankelijk.

Ik snap ook nog niet wat dan precies wrapped is.
Jouw uitleg dat het met robuustheid van doen heeft begrijp ik niet helemaal.
Wat ik er van weet is dat je altijd crc checks of hashes kunt genereren van blokken data. Los van hoe ze er in werkelijkheid uit zien.

Maar met een checksum of hash kun je enkel fouten detecteren, niet corrigeren. Dat kan hiermee wel.

Ik ben niet héél erg thuis in de wijze waarop flash kan corrupten, maar aangezien het ook gangbaar is om ECC e.d. toe te passen kan ik niet anders concluderen dat single bit errors óók een risco zijn. Die kun je hiermee ondervangen.

Het is wel wat primitief (en inefficient gezien de achtvoudige grootte), maar het werkt wel.

Een ander punt wat ik dan niet snap is dat ik ook andere u-boot en stage1 images heb waarin je gewoon met hexedit kunt kijken en daar zie ik wel machinetaal staan en leesbare en herkenbare ASCII strings.
En het nandwrite commando kent voor zo ver ik weet geen opties om daar rekening mee te houden door dergelijk ¨gewrapte¨ images al dan niet te converteren.

Klopt. Dit is echt alleen iets van de bootrom in deze SoC (voor stage1) en stage1 (voor uboot).

Alles bij elkaar zijn heb ik nog wel héél veel vragen waar ik geen antwoord voor heb.

Ah, ik zie wel waar het vandaan komt: jij hebt nu een kernel voor een heel ander device (pogoplug) geboot. Dat werkt toevallig omdat de SoC hetzelfde is (maar vast niet alle randapparatuur), maar praktisch leidt dat tot het probleem dat je niet de juiste partitietabel hebt.

Als je de originele kernel boot dan krijg je de juiste partitietabel cadeau.

Doe je dat niet, dan zul je soms met offsets moeten werken om images op de juiste plaats te krijgen. Als een gedeelte van het NAND niet gemapt is heb je helemaal pech.

Maar belangrijker nog: waarom heb ik ook stage1/uboot images die ¨herkenbaar zijn¨ en waarom zijn deze die ik heb ¨gecodeerd¨ (wrapped) en kan ik daar nergens iets over vinden?

Begrijp ik goed dat je het ding via SATA hebt kunnen booten? Dan vermoed ik dat hij bij een SATA boot dat 0x55/0xaa-correctiealgoritme niet gebruikt. De images voor NAND zijn dus wrapped, die voor SATA niet.

Maar wel prettig om niet alles alleen uit te hoeven zoeken!

Ik heb ooit ook overwogen om zo'n ding te updaten naar iets recenters, maar aangezien ik er fysiek niet gemakkelijk bij kan (en dus ook geen serial heb) is dat wat lastig.

Gerelateerd daaraan: debian armel zou kunnen werken, maar dan heb je nog geen werkende kernel. De originele kernel is stokoud en onbruikbaar. De pogoplug-kernel gebruiken zoals je nu doet is ook niet handig: die heeft de verkeerde NAND mapping en mapt volgens mij ook niet het hele RAM (128M ipv. 256M).

De beste optie lijkt me OpenWRT. Die ondersteunt in theorie de KD20. Dat overwoog ik te flashen (op goed geluk), totdat ik wat verontrustende berichten las over bricks.

Dat laatste betekent enkel dat je hem niet via de originele webinterface kunt flashen, maar daar kon je toch al niet bij. Je kunt de factory zip uitpakken nadat je hem hebt gedecrypt:

openssl enc -des3 -d -a -k sohmuntitnlaes -in openwrt-19.07.3-oxnas-ox820-shuttle_kd20-factory.tar.gz -out openwrt.tar

Dan zit daar een uImage in die volgens mij initramfs als rootfs gebruikt - zou dus zo moeten werken. Boot die eens?

[lnxuser]

Tjee wat een boel extra info weer!
Wat je allemaal beschrijft verklaart wel een aantal dingen bedenk ik nu.
Zoals het ecc achtige mechanisme om fouten te kunnen herstellen waardoor de image alleen maar bitmaps lijken te zijn.

Als je de originele kernel boot dan krijg je de juiste partitietabel cadeau.

Ik kan via de door paai beschreven procedure in een, naar ik aanneem, originele kernel komen. Maar ik heb dan niets beschikbaar vrees ik om iets met NAND lezen of schrijven te doen.

Begrijp ik goed dat je het ding via SATA hebt kunnen booten? Dan vermoed ik dat hij bij een SATA boot dat 0x55/0xaa-correctiealgoritme niet gebruikt. De images voor NAND zijn dus wrapped, die voor SATA niet.

Dit kan ook een verklaring zijn waarom het zich voor mij zo vreemd gedraagt. De boot van SATA gebruikt wel een stage1 en een u-boot vanaf de disk, deze zijn, wordt aangegeven, wel aangepast voor de KD20, maar ik vraag me af of de aanpassingen wel voldoende volledig zijn. Er zat geen ouder kernel bij dus ik heb zelf een recente kernel gebruikt en daarvan de DTB info aan de kernel toegevoegd.
Een beetje krom eigenlijk:
Een /rootfs met daarop een debian strech met in /boot een uImage met de KD20 DTB appended.
Diezelfde uImage gebruik ik ook om via tftp te booten. En daarna draait e.e.a. wel netjes op die sata disk.

En daar gaat het kennelijk mis omdat zoals jij aangeeft de mapping van de NAND niet juist is. Dan kun je natuurlijk een hoop verkeerd doen Dat is dan ook wat ik vermoed dat er is gebeurd.

Het vreemde is namelijk dat de stage1 en u-boot van de sata disk zelf nog geen enkele indicatie geven een bruikbaar device te zien, juist het tegendeel:

Dit meldt stage1 van de sata disk:

Setup memory, testing Reading disk 00 Sector : 0x0000009A Hdr len: 0x00025978 Hdr CRC: 0x1CCE0DF0 OK Detecting SATA busses: Bus 0: No devices found Failed to read valid environment from disk, using built-in default

en dit is wat de u-boot roept, overigens wordt wel herkend dat de KD20 256M geheugen heeft en niet maar 128 van de pogoplug dus ik veronderstel dat e.e.a. wel enigszins is aangepast. Maar of dat voldoende is?

_ _ _ _ | | | | | | | | ___| |__ _ _| |_| |_| | ___ / __| '_ \| | | | __| __| |/ _ \ \__ \ | | | |_| | |_| |_| | __/ |___/_| |_|\__,_|\__|\__|_|\___| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| U-Boot 1.1.2 (Jan 24 2015 - 13:54:11) U-Boot code: 60D00000 -> 60D25978 BSS: -> 60D3A680 IRQ Stack: 60cddf7c FIQ Stack: 60cdcf7c RAM Configuration: Bank #0: 60000000 256 MB SRAM Configuration: 64KB at 0x50000000 NAND:128 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Setting Linux mem= boot arg value Hit any key to stop autoboot: 2 <0x08><0x08><0x08> 1 <0x08><0x08><0x08> 0 IDE device 0: not available enable_interrupts Reset IDE: Detecting SATA busses: Bus 0: No devices found disk is not present! enable_interrupts

Ik kan ook de uboot environment niet bijvend aanpassen, het is meen ik vanuit de debian kernel een heel andere dan welke de u-boot laat zien. Overigens is dat ook zo in de u-boot prompt. Ik kan met setenv de noodzakelijke aanpassingen doen zoals serverip en de juiste disk partitie aangeven. Daarna werkt tftpboot prima maar dat is dan ook alles. En dat kan natuurlijk wel kloppen als de mapping verkeerd is .

Ik heb ook als eens gekeken naar het openwrt verhaal, maar dat nog even laten liggen. Wie weet moet ik er uiteindelijk toch wat mee .

Het is me overigens inmiddels ook gelukt om zelf een u-boot en stage1 (SPL, dat wordt er toch mee bedoeld?) te compileren vanuit de source.. Ik moet nog testen of die ook echt werkt.

Dus er zijn nog mogelijkheden om te proberen genoeg. En ik heb wel een seriële poort, anders is het allemaal niet te doen.

Het kost een hoop tijd, maar is ook wel erg leerzaam!

[lnxuser]

Nou ja, leerzaam of niet, ik kom nog niet veel verder .
Allerlei experimenten leiden nog tot niets.

Maar wat een optie lijkt te zijn is:
Met de door paai beschreven procedure krijg ik een shell (busybox)
Als ik daar wat rondkijk wat voor commando´s er zijn dan zie ik o.a.:
nandwrite
en mtdinfo
Als ik mtdinfo /dev/mtd0 krijg ik een foutmelding.
Ook de -a optie

deze:

code:

mtdinfo
mtdinfo: error!: cannot get MTD information
         error 2 (No such file or directory)

Maar als ik dat doe nadat ik een /tmp/mountpoint heb aangemaakt volgens:

code:

mkdir /tmp/mountpoint
mount -t ubifs ubi0_0 /tmp/mountpoint

dan lijkt alles ineens anders!

code:

/ # mtdinfo /tmp/mountpoint/dev/mtd0      
mtd0
Name:                           NAND 128MiB 3,3V 8-bit
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          1024 (134217728 bytes, 128.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

Kortom, het lijkt er op dat ik nu met nandwrite images naar NAND kan schrijven:

code:

nandwrite
Usage: nandwrite [OPTION] MTD_DEVICE [INPUTFILE|-]
Writes to the specified MTD device.

  -a, --autoplace         Use auto oob layout
  -j, --jffs2             Force jffs2 oob layout (legacy support)
  -y, --yaffs             Force yaffs oob layout (legacy support)
  -f, --forcelegacy       Force legacy support on autoplacement-enabled mtd
                          device
  -m, --markbad           Mark blocks bad if write fails
  -n, --noecc             Write without ecc
  -o, --oob               Image contains oob data
  -s addr, --start=addr   Set start address (default is 0)
  -p, --pad               Pad to page size
  -b, --blockalign=1|2|4  Set multiple of eraseblocks to align to
  -q, --quiet             Don't display progress messages
      --help              Display this help and exit
      --version           Output version information and exit

Alleen nu: welke image naar welke adressen....
De stage1.wrapped vind ik nog steeds een vreemde image omdat ik alleen maar 0xAA en 0x55 zie. Dat soort hexdumps heb ik alleen maar gezien met het nand dump commando vanuit een u-boot prompt.
Hetzelfde geldt voor de u-boot.wrapped image
Ik heb alle files uit de KD20.zip beschikbaar op een disk die ik kan mounten vanuit deze shell. Kortom mij lijkt de enige ontbrekende schakel nu de juiste nandwrite commando´s om dat de benodigde images terug te zetten naar de verschillende MTDxx devices van de nand.

Wat ik bij het lezen al denk te hebben kunnen vinden is het de het volgende:

code:

-rw-r--r--    1 root     root    134217728 Jan  2 01:57 mtd0.img
-rw-r--r--    1 root     root       262144 Jan  2 01:58 mtd1.img
-rw-r--r--    1 root     root      2097152 Jan  2 01:58 mtd2.img
-rw-r--r--    1 root     root      6291456 Jan  2 01:59 mtd3.img
-rw-r--r--    1 root     root      8126464 Jan  2 01:59 mtd4.img
-rw-r--r--    1 root     root    117440512 Jan  2 02:00 mtd5.img

en de mtdinfo van de respectievelijke devices:

code:

mtd0
Name:                           NAND 128MiB 3,3V 8-bit
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          1024 (134217728 bytes, 128.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

-rw-r--r--    1 root     root       262144 Jan  2 01:58 mtd1.img
/ # mtdinfo /tmp/mountpoint/dev/mtd1
mtd1
Name:                           Stage-1
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true


-rw-r--r--    1 root     root      2097152 Jan  2 01:58 mtd2.img
/tmp # mtdinfo /tmp/mountpoint/dev/mtd2
mtd2
Name:                           U-Boot
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          16 (2097152 bytes, 2.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:4
Bad blocks are allowed:         true
Device is writable:             true


-rw-r--r--    1 root     root      6291456 Jan  2 01:59 mtd3.img
/ # mtdinfo /tmp/mountpoint/dev/mtd3
mtd3
Name:                           INITRD
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          48 (6291456 bytes, 6.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:6
Bad blocks are allowed:         true
Device is writable:             true

-rw-r--r--    1 root     root      8126464 Jan  2 01:59 mtd4.img

/ # mtdinfo /tmp/mountpoint/dev/mtd4
mtd4
Name:                           Kernel
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          62 (8126464 bytes, 7.8 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:8
Bad blocks are allowed:         true
Device is writable:             true

-rw-r--r--    1 root     root    117440512 Jan  2 02:00 mtd5.img

/ # mtdinfo /tmp/mountpoint/dev/mtd5
mtd5
Name:                           Root
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          896 (117440512 bytes, 112.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:10
Bad blocks are allowed:         true
Device is writable:             true

mtd0 is wellicht de hele NAND
en de volgende zijn netjes zoals de naam aangeeft de Stage1, Uboot Initrd enz.
Ik ben er waarschijnlijk al als ik alleen stage1 en uboot terug heb gezet.

Maar dan moet de gevonden stage1 (nu mtd1.img er wel vergelijkbaar uitzien qua inhoud als de stage1.wrapped van het KD20.zip archief.

Er begint een beetje logica in te komen
Het is me inmiddels gelukt om met een gemounte disk met daarop ook wat extra nand tools een image van alle mtd0 tm mtd5 te maken. Daarbij is mtd0 de gehele nand. en mtd1 tm mtd5 zijn respectievelijk:
stage1, U-boot, INITRD, Kernel en Root

Wat me opviel was dat stage1 (mtd1, ook wel spl genoemd) ook hier bestond uit een bitmap van alleen maar byes 0xAA en 0x55. Nu heb ik die er zelf per abuis in gezet. (dat was het begin van de ellende ) maar goed. Kennelijk werkt het dus prima als je zo´n onherkenbaar stuk code in een NAND zet.
Het vreemde is echter wel dat de code voor het u-boot blok wat er nu in zit (mtd2) wel gewoon herkenbare machinecode en stukken leesbare tekst bevat (ook die heb ik er zelf per abuis ingezet) maar dat de u-boot.wrapped file uit het KD20zip archief juist bestaat uit een bitmap van 0xAA en 0x55.

Nu komt bij mij de vraag naar boven: kan ik nu alleen die stage1.wrapped terugzetten en gaat deze dan ook verder met de onjuiste u-boot of moet ik de ¨sets¨ bij elkaar houden. Dus stage1 en uboot uit het kd20.zip archief en de andere stage1 (spl) en u-boot ook als bij elkaar behorende set beschouwen? Het zomaar flashen van iets waarvan ik niet weet hoe het uitpakt vind ik niet zo erg aanlokkelijk. Het zou ook zo kunnen zijn dat de nu aanwezige u-boot alleen maar niet werkt omdat de environment config helemaal verkeerd is. Kortom: de firmware doet het prima, maar de instellingen zijn gewoon niet juist. En dan brengt een nieuwe uboot ook geen oplossing.
Nog maar even wachten met flashen dus..............

Maar als iemand een tip heeft of gewoon weet hoe e.e.a. zou kunnen of moeten of hoe ik dat zonder risico om de boel nog verder te verknoeien kan uitproberen dan lees ik dat graag

[ Voor 56% gewijzigd door lnxuser op 08-07-2020 23:02 ]

[Thralas]

lnxuser schreef op dinsdag 7 juli 2020 @ 14:35:
Nu komt bij mij de vraag naar boven: kan ik nu alleen die stage1.wrapped terugzetten en gaat deze dan ook verder met de onjuiste u-boot of moet ik de ¨sets¨ bij elkaar houden.

Waarom zou je die terugzetten als je nu al een stage1 loader zegt te hebben? Welke versie heb je nu (er zit een builddate string in)?

Dus stage1 en uboot uit het kd20.zip archief en de andere stage1 (spl) en u-boot ook als bij elkaar behorende set beschouwen? Het zomaar flashen van iets waarvan ik niet weet hoe het uitpakt vind ik niet zo erg aanlokkelijk. Het zou ook zo kunnen zijn dat de nu aanwezige u-boot alleen maar niet werkt omdat de environment config helemaal verkeerd is

Ja, die moet je bij elkaar houden en nee, voor zover ik kan vaststellen boot de NAND stage1 (wrapped) enkel wrapped u-boot images. NAND loaders zijn wrapped (stage1/u-boot), enkel de versies die op een SATA disk staan niet.

Environment zou het probleem niet mogen zijn in de zin dat de originele firmware gewoon boot met lege environment: leidend is dus wat de default environment is, en ik kan me voorstellen dat die bij jouw pogoplug u-boot (?) er net even wat anders uitziet.

En zet je output tussen [code][/code], dat leest prettiger...

[Mijzelf]

Over dat 'wrapped' en mtd size, Door dat wrappen kun je effectief maar 1 bit per byte kwijt, dus je hebt een 8 maal zo grote mtd partitie nodig. U-boot heeft over het algemeen tussen de 128 en de 256 KiB nodig (en als je squeezed lukt het nog wel in 64KiB). Dus een partitiegrootte van 2MiB wijst er op dat er inderdaad een wrapped u-boot in moet.
De stage1 moet het doen met 128KiB, dat is 16KiB effectief, maar die hoeft alleen u-boot in het geheugen te lezen en uit te voeren. Dus dat moet wel passen.

[lnxuser]

Dit is wat ik nu heb:
Een KD20.zip file met daarin o.a. de volgende images:
stage1.wrapped-nand
u-boot.wrapped
u-boot.wrapped-nand
Ik neem aan dat dit de standaard fabrieks images zijn.

Deze 3 images zijn niet ¨leesbaar¨ of herkenbaar met hex tools, binwalk etc omdat het bitmaps zijn bestaande uit alleen de bytes 0xAA en 0x55. Ik veronderstel dat dit specifieke format aangeduid wordt met de wrapped, maar ik kan daar nergens iets over vinden en ook niet iedereen doet dat.

De images u-boot.wrapped en u-boot.wrapped-nand zijn beide even groot: 1322208 byte, maar qua inhoud verschillend.

Wat ik gedaan heb omdat ik dacht dat dit gewoon zou kunnen om daarna Debian te kunnen booten van USB of SATA is:
Een oxnas (Pogoplug) stage1 geflashed naar 0x00000. ( overigens bestond deze image ook uit een bitmap met alleen 0xaa en 0x55 bytes)

En een oxnas u-boot geflashed naar 0x40000. Deze U-boot image bestaat uit ¨leesbare¨ binaire code. Binwalk maakt weliswaar niet veel van, maar met een hexeditor kun je gewoon de versie u-boot en diverse strings lezen.

Deze combo werkt niet, maar waarom is me niet geheel duidelijk. De u-boot gebruikt een pogoplug configatie, er wordt maar 128MB RAM gemeld. Maar misschien zijn het ook alleen maar verkeerde environment variabelen. Of zoiets stoms dat ie een Netconsole opstart en domweg niet meer naar de seriële console schrijft.
Omdat ik nu niets kan aanpassen als dat laatste het geval is, wil ik terug naar factory instellingen.

Via de methode ¨paai¨ lukt het me om een shell te krijgen waarin ik ook een disk kan mounten en in staat ben NAND te dumpen en images naar NAND te schrijven.
(dit laatste neem ik aan, maar het nandwrite commando is standaard in die shell beschikbaar)

De vraag van Thralas:

Waarom zou je die terugzetten als je nu al een stage1 loader zegt te hebben? Welke versie heb je nu (er zit een builddate string in)?

De stage1 loader die nu in de NAND zit is niet bedoeld voor deze configuratie, maar wellicht doet stage1 helemaal niets met configuratie en is die dus prima bruikbaar.
Dat weet ik domweg niet.
Hij draagt wel het stokje netjes over naar de bootloader die op 0x40000 van de NAND geladen is.

Dit is de banner van de stage1 die nu in NAND zit op 0x00000:

code:

U-Boot SPL 2013.10-tld-4 (Sep 07 2014 - 14:10:12)
  Boot device: NAND
Attempting to set PLLA to 850 MHz ...
  plla_ctrl0 : 0000020a
  plla_ctrl1 : 0033000:0
  plla_ctrl2 : 0065008b
  plla_ctrl3 : 000000f1

PLLA Set

Een andere stage1, die van een bootable satadisk geeft overigens dit:

code:

  Stage-1 Bootloader 2015-01.21-21:48:56
Attempting to set PLLA to 800MHz ...
  plla_ctrl0 : 0x0000030A
  plla_ctrl1 : 0x00400000
  plla_ctrl2 : 0x007F0068
  plla_ctrl3 : 0x00000193
PLLA Set

Setup memory, testing
Reading disk 00
  Sector : 0x0000009A
  Hdr len: 0x00025978
  Hdr CRC: 0x1CCE0DF0
 OK
Detecting SATA busses:
Bus 0: No devices found
Failed to read valid environment from disk, using built-in default

Daarna start ie een bijbehorende u-boot (ook vanaf de sata disk) op met een shuttle banner enz.
Via deze route kan ik via ftp etc een shell krijgen maar ook een debian versie booten als ik wil.

Overigens was dit de output van de oorspronkelijke stage1 (wellicht die stage1.wrapped) die ik dus overschreven heb.

code:

Stage-1 Bootloader 2012-06.13-13:06:32
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing, Image 0
  Hdr len: 0x00028594
  Hdr CRC: 0x0BA1B9D0
 OK

Ik kan niet beoordelen of het nodig is om ook stage1 te vervangen, maar wat ze als output laten zien is anders en ik weet simpelweg niet wat er relevant is, dus ik ga liever terug naar een bekende werkende situatie.

Je geeft ook aan:

Ja, die moet je bij elkaar houden en nee, voor zover ik kan vaststellen boot de NAND stage1 (wrapped) enkel wrapped u-boot images.

Dit lijkt niet te kloppen, want de wrapped stage1 die er nu in NAND zit geeft het stokje prima over naar de niet wrapped u-boot die op 0x40000 in NAND staat.....

Maar het lijkt me handiger om gewoon setjes bij elkaar te houden totdat e.e.a. weer goed werkt

Die pogoplug environment is nogal anders dan die van de kd20. Maar ik kan hem toch niet aanpassen, dus moet iets anders.

Wat wil ik dan nog meer weten?

Ik veronderstel dat ik de stage1.wrapped uit het KD20.zip archief gewoon met nandwrite terug kan zetten naar 0x0.
Maar dan de u-boot, welke? de wrapped of de wrapped-nand versie, want ze zijn niet hetzelfde...
En waar moet ie neergezet worden: gewoon ook op 0x40000? Of kan het ook zijn dat ie op een ander adres moet worden weggeschreven?

Omdat het me tot dusver goed gelukt is om met elke stap meer te verknoeien dan te repareren ben ik super wantrouwig geworden om ook nog maar iets te doen voor dat ik min of meer snap wat de uitwerking daarvan is

[lnxuser]

Mijzelf schreef op woensdag 8 juli 2020 @ 15:02:
Over dat 'wrapped' en mtd size, Door dat wrappen kun je effectief maar 1 bit per byte kwijt, dus je hebt een 8 maal zo grote mtd partitie nodig. U-boot heeft over het algemeen tussen de 128 en de 256 KiB nodig (en als je squeezed lukt het nog wel in 64KiB). Dus een partitiegrootte van 2MiB wijst er op dat er inderdaad een wrapped u-boot in moet.
De stage1 moet het doen met 128KiB, dat is 16KiB effectief, maar die hoeft alleen u-boot in het geheugen te lezen en uit te voeren. Dus dat moet wel passen.

Die wrapped uboot images uit die KD20.zip zijn elk 1,3MB.
Ik heb nog ergens anders een Archief met ook een KD20 uboot, tenminste dat wordt aangegeven. die is slechts 103k en is met hexedit ¨leesbaar¨. Dat komt min of meer overeen met wat jij aangeeft lijkt me.

Wat het er niet duidelijker op maakt de file heet: u-boot.wrapped, er weliswaar geen versie of label string in te vinden maar voor de rest wel gewoon environment stringsen machinecode

Wat me gewoon dwars zit is dat ik niets kan vinden over conversie tools die wrapped of niet wrapped images maken. Of opties voor make of makeimage tools die dat doen en als dat al de juiste termen zijn en waarom een ¨wrapped¨ stage1 prima een non-wrapped uboot laadt en waarom ik 2 uboots heb waarvan 1 alleen wrapped en de ander wrapped-nand heet welke verschillend zijn qua inhoud.
En omdat deze wrapped images gewoon niet leesbaar zijn door tools of wat dan ook. Ik heb ook een Phyton script dat images van u-boot waar binwalk niets van maakt gewoon herkend. Maar dat script kan ook niks met die zg ´wrapped´ images.......

Ik kan best volgen dat je met ecc mechanismes grotere images nodig hebt of zo, maar niet waarom er over deze verschillen en dit NAND mechanisme niets of nauwelijks iets is te vinden. Het lijkt me toch een vrij essentieel iets. Maar misschien kan ik gewoon niet goed zoeken

[lnxuser]

Inderdaad beter zoeken
Maar niet googlen, maar gewoon spitten in de sourcecode van uboot.
Bij al het gepuzzel heb diverse uboot sources gevonden en ik denk nu eindelijk te hebben gevonden hoe het zit: vrij eenvoudig eigenlijk:
dit is de python code om vaneen ¨gewone¨ image een bitmap met 0xaa en 0x55 te maken.

code:

import sys


def encode (a, outfile):
        # print "a=",a
        b=ord(a)
        for i in range(8) :
                if b & 1 :
                        outfile.write (chr(0x55))
                else :
                        outfile.write (chr(0xAA))
                b >>=1

def main():
        print "number of arguments =" , len(sys.argv)
        if len(sys.argv) < 3 :
                print "usage: encode in_file out_file"
        else :
                infile = open (sys.argv[1],"rb")
                outfile = open (sys.argv[2],"wb")
        a=infile.read(1)
        while a :
                encode(a,outfile)
                a=infile.read(1)
import sys


def encode (a, outfile):
        # print "a=",a
        b=ord(a)
        for i in range(8) :
                if b & 1 :
                        outfile.write (chr(0x55))
                else :
                        outfile.write (chr(0xAA))
                b >>=1

def main():
        print "number of arguments =" , len(sys.argv)
        if len(sys.argv) < 3 :
                print "usage: encode in_file out_file"
        else :
                infile = open (sys.argv[1],"rb")
                outfile = open (sys.argv[2],"wb")
        a=infile.read(1)
        while a :import sys


def encode (a, outfile):
        # print "a=",a
        b=ord(a)
        for i in range(8) :
                if b & 1 :
                        outfile.write (chr(0x55))
                else :
                        outfile.write (chr(0xAA))
                b >>=1

def main():
        print "number of arguments =" , len(sys.argv)
        if len(sys.argv) < 3 :
                print "usage: encode in_file out_file"
        else :
                infile = open (sys.argv[1],"rb")
                outfile = open (sys.argv[2],"wb")
        a=infile.read(1)
        while a :
                encode(a,outfile)
                a=infile.read(1)

main()
                encode(a,outfile)
                a=infile.read(1)

main()
main()

Als ik het goed lees gewoon alle bitjes tellen en er dan 0xaa of 0x55 van maken.
Dat verklaart ook meteen waarom zo´n image 8x groter wordt zoals ¨Mijzelf¨ al aangaf.
Voor mij verklaard het overigens niet hoe weet een systeem of de processor nu of het zo´n encoded bitmap is of niet. Dat kan vast wel via een driver gedaan worden, of bij het schrijven of zo, maar dat zie ik nog niet in de puzzelstukjes van het verhaal.
Ik denk dat ik maar eens ga proberen een decode stukje software te maken, want zo ingewikkeld lijkt me dat nou ook weer niet.

[Mijzelf]

lnxuser schreef op woensdag 8 juli 2020 @ 23:25:

Wat me gewoon dwars zit is dat ik niets kan vinden over conversie tools die wrapped of niet wrapped images maken. Of opties voor make of makeimage tools die dat doen en als dat al de juiste termen zijn en waarom een ¨wrapped¨ stage1 prima een non-wrapped uboot laadt en waarom ik 2 uboots heb waarvan 1 alleen wrapped en de ander wrapped-nand heet welke verschillend zijn qua inhoud.
En omdat deze wrapped images gewoon niet leesbaar zijn door tools of wat dan ook. Ik heb ook een Phyton script dat images van u-boot waar binwalk niets van maakt gewoon herkend. Maar dat script kan ook niks met die zg ´wrapped´ images.......

Tja, waarom zou het erg goed gedocumenteerd moeten zijn? Dit zou best specifiek voor deze SoC kunnen zijn. De SoC kent een truuk om met onbetrouwbaar NAND geheugen te kunnen booten, en de stage1 bootloader (die zeker specifiek is voor deze SoC) kan hetzelfde truukje doen met u-boot. U-boot is goed gedocumenteerd, maar hoeft niets van deze truuk te weten. Hij wordt door de stage1 loader ge-unwrapped en in het geheugen geladen. De kernel en initramfs die door u-boot worden geladen zijn niet gewrapped. (Logisch, als je goedkope flash gebruikt is het wat contraproductief om 8 keer de grootte nodig te hebben)

[Thralas]

lnxuser schreef op woensdag 8 juli 2020 @ 22:56:
Deze combo werkt niet, maar waarom is me niet geheel duidelijk. De u-boot gebruikt een pogoplug configatie, er wordt maar 128MB RAM gemeld. Maar misschien zijn het ook alleen maar verkeerde environment variabelen.

Je flasht een set bootloaders van een ander device. Het is een wonder dat het nog enigszins boot. RAM zal niet een kwestie van environment zijn, dat soort parameters zijn doorgaans hardcoded.

Overigens was dit de output van de oorspronkelijke stage1 (wellicht die stage1.wrapped) die ik dus overschreven heb.

Hier de originele loaders. Zijn dumps van de block devices, dus zonder oob/ecc data (dat gebruiken de bootloaders niet vziw.).

code:

2012-06.13-13:06:32
U-Boot 1.1.2 (Jul  3 2012 - 17:37:46)

Dit lijkt niet te kloppen, want de wrapped stage1 die er nu in NAND zit geeft het stokje prima over naar de niet wrapped u-boot die op 0x40000 in NAND staat.....

Dat is dan ook een stage1 van een heel ander device. Geen garanties dat die hetzelfde gedrag heeft. Waarschijnlijk is de Pogoplug u-boot gewoon niet 'wrapped'.

Dat onderstreept tevens het belang van het flashen van bootloaders die bij elkaar horen. Ik zei het namelijk niet zomaar: ik weet namelijk zeker dat de originele kd20 stage1 enkel 'wrapped' files van nand leest.

[lnxuser]

Mijzelf schreef op donderdag 9 juli 2020 @ 18:46:
[...]


Tja, waarom zou het erg goed gedocumenteerd moeten zijn? Dit zou best specifiek voor deze SoC kunnen zijn. De SoC kent een truuk om met onbetrouwbaar NAND geheugen te kunnen booten, en de stage1 bootloader (die zeker specifiek is voor deze SoC) kan hetzelfde truukje doen met u-boot. U-boot is goed gedocumenteerd, maar hoeft niets van deze truuk te weten. Hij wordt door de stage1 loader ge-unwrapped en in het geheugen geladen. De kernel en initramfs die door u-boot worden geladen zijn niet gewrapped. (Logisch, als je goedkope flash gebruikt is het wat contraproductief om 8 keer de grootte nodig te hebben)

Dat klopt ook met wat ik gezien heb en natuurlijk is het logisch niet te veel duur geheugen nodig te hebben.

[lnxuser]

Thralas schreef op donderdag 9 juli 2020 @ 19:48:

Je flasht een set bootloaders van een ander device. Het is een wonder dat het nog enigszins boot. RAM zal niet een kwestie van environment zijn, dat soort parameters zijn doorgaans hardcoded.

Tja ik had hetzelfde kunstje uitgehaald met een Pogoplug. Daar draait zonder problemen Debian Buster op. Alleen vragen de recentere versies van toepassingen gewoon steeds meer geheugen. Probeer het maar eens : Owncloud 10 op een Pogoplug. Als remote file storage werkt het prima en gebruikt bijna niks aan stroom. Maar je moet dan wel de meeste owncloud features uitzetten, want dat vraagt te veel geheugen.
Omdat ik die KD20 ook nog had staan dacht ik het kunstje te kunnen herhalen. Dat liep dus nogal anders

Doordat er nogal wat mis ging en ook nu nog steeds niet alle details me duidelijk zijn ben ik flink terughoudend geworden om maar weer iets te flashen. En zeker niet zo´n vage image die alleen uit een onleesbare bitmap bestaat

Inmiddels is het me gelukt met mijn wat roestige programmeerkennis een python decoder in elkaar te knutselen en kan ik het onleesbare weer ´leesbaar´ maken. Niet dat ik die gedecodeerde exemplaren wil gebruiken, maar ik heb er nu iets meer vertrouwen dat dit toch wel de images zijn die teruggezet zouden moeten kunnen worden.
Ik ben nog steeds verbaasd dat er vrijwel niets van deze de op deze wijze gecodeerde images ergens een keer is op een begrijpelijke manier beschreven is op internet. Zo bijzonder is het principe nou ook weer niet.
Het kan natuurlijk zijn dat deze methode inmiddels niet meer zo gebruikelijk is, maar dan nog.
Gelukkig ben ik eigenwijs genoeg om dan maar diep door te graven tot op de bodem. Maar die heb ik nu dan ook wel zo´n beetje bereikt denk ik Zelf een decoder schrijven omdat er gewoon geen een te vinden is.

Thralas schreef op donderdag 9 juli 2020 @ 19:48:

Hier de originele loaders. Zijn dumps van de block devices, dus zonder oob/ecc data (dat gebruiken de bootloaders niet vziw.).

Hee dat is top zeg! Erg bedank!. Super om ook dat nog als alternatief achter de hand te hebben!

code:

2012-06.13-13:06:32
U-Boot 1.1.2 (Jul  3 2012 - 17:37:46)

Zoals al gezegd, ik kan inmiddels die die 0x55 0xAA images gewoon decoderen en in de u-boot.wrapped die ik heb zie ik dit bijvoorbeeld:

code:

U-Boot 1.1.2 (Oct 22 2012 - 10:55:50)

Thralas schreef op donderdag 9 juli 2020 @ 19:48:
Dat is dan ook een stage1 van een heel ander device. Geen garanties dat die hetzelfde gedrag heeft. Waarschijnlijk is de Pogoplug u-boot gewoon niet 'wrapped'.

Dat is ook waarom het mij niet slim leek om de stage1 van de pogoplug te laten zitten en alleen de u-boot van de kd20 te flashen. Misschien werkt het wel, maar als het toch niet werkt zit ik weer te knoeien.
Het klopt dat de Pogo u-boot niet wrapped is. Maar of het zo is dat de stage1 informatie heeft hoe en/of welk type u-boot hij aankan weet ik ook nu nog niet. Wie weet is dat gewoon een config item is kan het zelfs geprobed worden. Maar ik heb geen zin meer om ook dat nog uit te gaan zoeken .
Het heeft me meer dan genoeg tijd gekost.

Het zal nog wel even duren voordat ik de boel definitief terugzet. Maar ik heb nu wat meer vertrouwen dat het wel kan lukken.

Thralas schreef op donderdag 9 juli 2020 @ 19:48:
Dat onderstreept tevens het belang van het flashen van bootloaders die bij elkaar horen. Ik zei het namelijk niet zomaar: ik weet namelijk zeker dat de originele kd20 stage1 enkel 'wrapped' files van nand leest.

Tja, dat ben ik inmiddels ook wel in gaan zien. En ik maar naïef denken dat het gewoon modulaire dingen zijn die het ook prima doen met andere functioneel vergelijkbare codeblokken. Niet dus.

In ieder geval bedankt voor de assistentie, adviezen en het meedenken.

Ik heb hier een hoop van geleerd, en heb weer eens lekker ouderwets moeten hacken om iets uit te zoeken! En ik ben er achter gekomen dat ik het ook nog niet verleerd ben .

[lnxuser]

Eind goed al goed. De nand images, stage1.wrapped-nand en u-boot.wrapped-nand die ik al die tijd al had, heb ik terug kunnen schrijven naar de bijbehorende /dev/mtd1 en /dev/mtd2 met de standaard nandwrite die in de via de methode van paai beschikbaar gekregen kernel aanwezig was.

Het was wel weer even schrikken na de eerste poging: er was niks weggeschreven
Maar er was ook een waarschuwing dat de padding optie gebruikt zou moeten worden. (en ook een melding success , ik vraag me nog steeds af waarmee dan? )

Maar goed, na die optie te hebben toegevoegd werden de images netjes weggeschreven en had ik weer een als vanouds werkende KD20. Niet dat je daar nog veel aan hebt, want alle diensten vanuit shuttle zijn al jaren geleden gestopt. Maar er is vast wel iets te bedenken waardoor je ook gewoon de laatste versie van debian kan draaien en dat maakt dan weer van alles mogelijk .

[lnxuser]

Mijn oorspronkelijke bedoeling, een recente versie Debian draaien op de kd20 bleek vrij eenvoudig. Een paar aanpassingen van de u-boot environment en hij boot netjes Debian Stretch of Buster, net wat je wilt, van een SATA drive.
Wat je daarna doet heb je zelf in de hand. De rekenkracht is echter beperkt en niet alle hardware aansluitingen, met name de USB 3 interface en de hardware Raid, worden goed ondersteund. Tenminste zo heb ik begrepen. Ook de rekenkracht is wat mager omdat er geen hardware rekenunit in zit. Dus de performance blijft beperkt. Maar als je daar mee kunt leven kan hij vast nog jaren zijn ding doen.