Hallo,
Ich habe ein Sheevaplug gekauft, mit der Absicht damit etwas zu
experimentieren. Bis jetzt habe ich versucht, im u-boot über tftp einige
Kernel aus dem Netz ohne Erfolg zum Laufen zu bringen. Mein eigentliches
Ziel ist, einen Vanilla-Kernel selbst zu implemntieren. Dafür besitze
ich zu wenig Info über diesen Box.
Bis jetzt kenne ich.
Box hat ein " Marvell ® 88F6281 SoC" mit "Marvell Sheeva CPU core
ARMv5TE-compliant"
Aber ein "cat /proc/cpuinfo" sagt etwas anderes. Oder ist das selbe ?
root@debian:/# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 1 (v5l)
BogoMIPS : 1192.75
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 4
I line length : 32
I sets : 128
D size : 16384
D assoc : 4
D line length : 32
D sets : 128
Hardware : Feroceon-KW
Revision : 0000
Serial : 0000000000000000
root@debian:/#
Ausserdem die Adressbereiche irritiren mich etwas.
512MB - Flash: 0000 0000 .... 1FFF FFFF
512MB - RAM: 0000 0000 .... 1FFF FFFF
Wie ist es möglich, dass RAM und NAND gleiche Adressbereiche habe
Bei der Suche nach Partitionen finde ich u-boot nicht. wo kann das sein
root@debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00020000 "uImage"
mtd1: 1fb00000 00020000 "rootfs"
Also wie ihr seht. Viele Unklarheiten, Fragen. Wer hat Infomaterial über
diesen Sheevaplug und kann dies zur Verfügung stellen.
Ich habe noch eine console-Ausgabe für Bootvorgang hinzugefügt.
Danke für Hilfestellungen
Moin,
was denn, ist google kaputt ;-)?
> cat /proc/cpuinfo
Die Informationen passen schon, nur dass der Marvell ein SoC ist und
nicht nur den CPU-Core beinhaltet. cpuinfo liefert aber nur die
CPU-Informationen.
> Wie ist es möglich, dass RAM und NAND gleiche Adressbereiche habe
Wie kommst Du zu dieser Annahme? Die Parameter, die z.B bei nand_read
übergeben werden beziehen sich auf die Adresse im NAND (die erste
Speichertselle im NAND wird als Adresse 0x00000000 angenommen).
nand_read rechnet aber noch auf die physikalische Adresse aus CPU-Sicht
um. Ob die MMU hier noch mit reinspielt kann ich ad hoc nicht sagen,
vermutlich schon.
> Bei der Suche nach Partitionen finde ich u-boot nicht. wo kann das sein
Im Flash ;-). Allerdings werdem dem Kernel im UBoot einige Parameter
übergeben, damit er weiß wo er diese Partitionen findet. Das sagte
dieser auch klar und deutlich:
> 2 cmdlinepart partitions found on MTD device nand_mtd> Using command line partition definition
Bei Deiner Sheeva fehlen diese Einträge wohl. Schau mal im UBoot nach
was dort für den Kernelparameter 'mtdparts' festgelegt wird.
Ansonsten:
http://www.sheevaplug.de (kennst Du ja)
http://www.plugcomputer.org/ (-> Forum)
Auch sehr lohnenswert, aber das kennst Du ja auch:
http://www.cyrius.com/debian/kirkwood/sheevaplug/
Vielleicht sollten wir doch auf sheevaplug.de weiterdiskutieren....
timpi.
Hallo,
Zuerst, Danke für die Infos.
> was denn, ist google kaputt ;-)?
Sorry, meine Linuxkentnisse sind noch nicht gefestigt. Aber ich bin
dran, wie du festgestellt hast.
> cpuinfo liefert aber nur die CPU-Informationen
Also die CPU ist ein "ARM926EJ-S rev 1 (v5l)"
>> Wie ist es möglich, dass RAM und NAND gleiche Adressbereiche habe
In Bezug auf RAM+NAND Adressbereiche habe ich dieses pdf gefunden.
http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Auf der Seite 41: 2.13 Default Address Map stehen die Adressbereiche.
DDR SDRAM CS0 0 0x0E 256 MB 0000.0000–0FFF.FFFF
DDR SDRAM CS1 0 0x0D 256 MB 1000.0000-1FFF.FFFF
....
....
NAND Flash 1 0x2F 128 MB D800.0000–DFFF.FFFF
Reserved – E000.0000–E7FF.FFFF
Das würde für mein Box wie folgt heissen
512MB-RAM: 0000.0000 1FFF.FFFF
512MB-NAND: D800.0000 E7FF.FFFF
korrekt ?
> Allerdings werdem dem Kernel im UBoot einige Parameter übergeben
u-boot.printenv Ausgabe:
console=console=ttyS0,115200
mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
addr size
--------------------------------
uboot: 0 0xc0000
root: 0x100000 0x1ff00000
bootargs=console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
rw root=/dev/mtdblock1 rw
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
addr size
--------------------------------
uImage: 0x100000 0x400000
rootfs: 0x500000 0x1fb00000
Wieso hat hier rootfs eine andere Grösse wie oben ?
Und wenn der Kernel hoch fährt, meint er nur eine Partition zu haben ???
Kernel command line: console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),e
Der hat doch oben mit "bootargs" zwei übergeben bekommen.
Da ich mein sheeva bei ebay ersteigert habe, lag kein info-material
dabei, so kenne ich den nand-Inhalt nicht. wie ich schon erwähnte, habe
ich versucht hier: http://www.xilka.com/sheeva/ einen Kernel zum Laufen
zu bekommen. Bis jetzt keinen Erfolg. Im u-boot kann ich den nand-Inhalt
lesen aber nicht auf meinem PC ablegen (Backup). openocd konnte ich auch
nicht 100% zum Laufen bringen. So das sind meine Probleme.
> Vielleicht sollten wir doch auf sheevaplug.de weiterdiskutieren....
Würde mich sehr freuen, wenn du mir Hinweise bei den Problemen geben
könntest.
Gruss
Hallo Denis,
ich fang' mal von hinten an.
> Da ich mein sheeva bei ebay ersteigert habe, lag kein info-material> dabei
Schau hier: http://www.plugcomputer.org/downloads/plug-basic/
Dort findest Du neben den Dokumentationen auch die Original-Images für
die Sheeva. Du musst also nichts sichern, vielleich mal abgesehen von
der MAC-Adresse (ethaddr im UBoot-Environment).
> Also die CPU ist ein "ARM926EJ-S rev 1 (v5l)"
Ja.
>>>> Wie ist es möglich, dass RAM und NAND gleiche Adressbereiche habe> In Bezug auf RAM+NAND Adressbereiche habe ich dieses pdf gefunden.>> http://www.marvell.com/embedded-processors/kirkwoo...>
Das ist die Beschreibung des Prozessors bzw. des SoCs und nicht der
SheevaPlug. Wenn Du weiter liest findest Du auch noch einen Abschnitt
zum NAND-Flash-Controller. Aber eigentlich interessiert Dich das nur,
wenn Du einen eigenen Bootloader oder NAND-Treiber schreiben willst.
Wie die SheevaPlug bootet und wie deren Speicheraufteilung ist, das wird
in der unter dem obigen Link zu findenden Dokumentation des SheevePlug
DevKits zu finden.
> u-boot.printenv Ausgabe:> console=console=ttyS0,115200> mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
Hmmmm, die 'console'-Variable sollte keine nand_mtd-Einträge haben.
Scheint aber wirklich original so zu sein...
Wird in Deiner UBoot-Konfiguration aber sowieso nicht weiter beachtet.
> Und wenn der Kernel hoch fährt, meint er nur eine Partition zu haben ???>> Kernel command line: console=ttyS0,115200> mtdparts=nand_mtd:0x400000@0x100000(uImage),e>> Der hat doch oben mit "bootargs" zwei übergeben bekommen.
Richtig. Hier passt was nicht ;-).
Kann es sein, dass Dein Terminalprogramm den Rest dieser Zeile
abschneidet? Denn der Kernel sagt:
Hallo Stefan,
Heute habe ich wieder Zeit.
> .. auch die Original-Images für die Sheeva
Ich habe folgende Files downloaded
u-boot-3.4.27.zip, linux-2.6.22.18_ferocean_427KW.tar, rootfs.tar.bz2
Wegen
** MARVELL BOARD: SHEEVA PLUG LE
U-Boot 1.1.4 (Jul 14 2009 - 06:46:57) Marvell version: 3.4.16
....
....
Linux version 2.6.22.18 (dhaval@devbox) (gcc version 4.2.1) #1 Thu Mar
19 14:46:22 IST9
....
....
u-boot-3.4.27.zip ist aktueller als meins aber no Problem, denke ich
Ich werde versuchen, die zum Laufen zu bringen
> ... Wie die SheevaPlug bootet und wie deren Speicheraufteilung ist, das wird in
der unter dem obigen Link zu findenden Dokumentation des SheevePlug DevKits zu
finden
Wenn du dieses pdf meinst.
http://www.plugcomputer.org/405/us/plug-basic/documentation/Plug-DevKit-Reference-Design-Rev1.1.pdf
Darin habe ich die Speicheraufteilung nicht gefunden.
> ... Kann es sein, dass Dein Terminalprogramm den Rest dieser Zeile
abschneidet?
Stimmt, hier die ganze Zeile
Kernel command line: console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
rw root=/dev/mtdblock1 rw
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
OK, aber warum die rootfs-Grösse in uboot-env-var console und bootargs
unterschiedlich angegeben wird..??
> http://www.newit.co.uk/forum/
Danke, sehr informativ
Hallo,
Denis D. schrieb:> u-boot-3.4.27.zip, linux-2.6.22.18_ferocean_427KW.tar, rootfs.tar.bz2
Hmm, kommt drauf an was Du machen willst. Wenn Du einen aktuelleren
Kernel nehmen willst, dann schau mal auf
http://sheeva.with-linux.com/sheeva/ vorbei (Kernel-Binaries, Module,
Sourcen und Patches, auch aktuellerer Versionen).
> u-boot-3.4.27.zip ist aktueller als meins aber no Problem, denke ich> Ich werde versuchen, die zum Laufen zu bringen
Sollte passen. Aber warum dann nicht gleich eine aktuelle Version aus
dem git-Repository? Bei der GuruPlug gab es damit hier keine Probleme.
Wie die Unterstützung der Sheeva aussieht kann ich nicht sagen.
> http://www.plugcomputer.org/405/us/plug-basic/documentation/Plug-DevKit-Reference-Design-Rev1.1.pdf>> Darin habe ich die Speichceraufteilung nicht gefunden.
Aus den Scripts des sheevaplug-installers kann man auch eine Menge
herauslesen.
Wo letztendlich der Kernel und das rootfs liegen bleibt ja Dir
überlassen. Das UBoot muss im ersten Flashsektor liegen. Im
Auslieferungszustand
> Kernel command line: console=ttyS0,115200> mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)> rw root=/dev/mtdblock1 rw
Ja, das passt.
Manche erweitern das Ganze noch, um auf das UBoot-Image und das
UBoot-Environment zugreifen zu können
1
0xa0000@0(uboot),0x40000@0x0xa0000(uenv)
> OK, aber warum die rootfs-Grösse in uboot-env-var console und bootargs> unterschiedlich angegeben wird..??
Keine Ahnung, ist hier nicht so.
Du solltest übrigens zum Spielen das selbst gebaute UBoot erst einmal in
den RAM laden (aus dem installierten UBoot über USB-Stick oder tftp) und
dort starten.
timpi.
Hallo Stefan,
> Hmm, kommt drauf an was Du machen willst.
wollte zuerst genau den Stand haben, den ich auch momentan auf dem Box
habe.
> Wenn Du einen aktuelleren Kernel nehmen willst, dann schau mal aufhttp://www.xilka.com/sheeva/3/3.5/3.5.7/release/1/sheeva-3.5.7-uImage:
läuft nicht. Nach dem Entpacken bleibt es stehen. Ist der nicht für mein
Box ? Welche sollte ich nehmen ?
Marvell>> tftpboot 0x02000000 sheeva-3.5.7-uImage
Using egiga0 device
TFTP from server 192.168.178.20; our IP address is 192.168.178.26
Filename 'sheeva-3.5.7-uImage'.
Load address: 0x2000000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##########################################
done
Bytes transferred = 3206904 (30eef8 hex)
Marvell>> bootm 2000000
## Booting image at 02000000 ...
Image Name: Linux-3.5.7
Created: 2012-10-14 2:14:11 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3206840 Bytes = 3.1 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
http://www.plugcomputer.org/downloads/plug-basic/uImage.8.6plug: läuft
einwandfrei
> selbst gebaute UBoot erst einmal in den RAM laden
Hier wollte ich mit openocd arbeiten. Aber die habe ich nicht zum Laufen
gebracht.
Hier mein Versuch:
# openocd
Open On-Chip Debugger 0.6.0-rc2-dev-00001-g9fbfb61 (2012-09-01-16:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id
0x20a023d3 ..."
Warn : AUTO auto0.tap - use "... -irlen 4"
Warn : gdb services need one or more targets defined
Info : accepting 'telnet' connection from 4444
# netcat localhost 4444
��������Open On-Chip Debugger
>
# arm-linux-gdb u-boot
GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-unknown-linux-uclibcgnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from .../u-boot-2010.06-wut/u-boot...done.
(gdb) help
List of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands
Type "help" followed by a class name for a list of commands in that
class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) target remote localhost:3333
localhost:3333: Connection timed out. ?????????
(gdb)
Was kann da fehlen ?
Mein openocd.cfg File sieht so aus
interface ft2232
ft2232_layout sheevaplug
ft2232_vid_pid 0x9e88 0x9e8f
ft2232_device_desc "SheevaPlug JTAGKey FT2232D B"
adapter_khz 2000
N'Abend,
Denis D. schrieb:> http://www.xilka.com/sheeva/3/3.5/3.5.7/release/1/sheeva-3.5.7-uImage:> läuft nicht. Nach dem Entpacken bleibt es stehen. Ist der nicht für mein> Box ? Welche sollte ich nehmen ?
Doch, doch. das klappt schon.
>> Marvell>> tftpboot 0x02000000 sheeva-3.5.7-uImage
OK.
> Marvell>> bootm 2000000
Auch OK. Wichtig dabei ist, dass in der UBoot-Environmentvariable
'bootargs' zumindest der 'console=ttyS0,115200' steht, sonst siehst Du
nichts über die serielle Schnittstelle. Versuch's mal mit minimalen
Bootargumenten:
1
tftpboot 0x02000000 sheeva-3.5.7-uImage
2
setenv bootargs console=ttyS0,115200
3
bootm 2000000
Alternativ kannst Du von einem USB-Stick booten (FAT-Partition anlegen
und Kernel-Image darauf kopieren):
1
usb start
2
fatload usb 0:1 0x02000000 sheeva-3.5.7-uImage
3
setenv bootargs console=ttyS0,115200
4
bootm 2000000
>> selbst gebaute UBoot erst einmal in den RAM laden> Hier wollte ich mit openocd arbeiten. Aber die habe ich nicht zum Laufen> gebracht.>> Hier mein Versuch:>> # openocd
Da fehlt die Konfigurationsdatei:
1
openocd -f board/guruplug.cfg
Am stabilsten lief hier bei mir die von Marvell mitgelieferte
openocd-Version. Neuere Vesionsn melden Fehlern in den Scripten.
timpi.
Hallo Stefan,
> dass in der UBoot-Environmentvariable> 'bootargs' zumindest der 'console=ttyS0,115200' steht
Nachdem Kernel geladen ist, steht in bootargs folgendes.
..
..
bootargs=console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
rw root=/dev/mtdblock1 rw
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
..
..
Aber trotzdem habe ich "setenv bootargs console=ttyS0,115200"
ausgeführt.
Verhalten leider gleiche. Was kanns noch sein ??
> oops, ist natürlich 'sheevaplug.conf'.
Hier hatte ich 'sheevaplug.conf' genommen, in "openocd.cfg" umbenannt
und nach Verz. kopiert, wo ich openocd starte. Hier ist mein config
#
# Marvel SheevaPlug Development Kit
#
#
http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp
#
interface ft2232
ft2232_layout sheevaplug
ft2232_vid_pid 0x9e88 0x9e8f
ft2232_device_desc "SheevaPlug JTAGKey FT2232D B"
adapter_khz 2000
Auch hier leider keine Veränderung..
Gruss
Denis
erstmal: Juchuuuu endlich mal wen gefunden der auch gerade probiert das
neuste Xilka Linux zu installen :)
Ich häng mich einfach mal drann: So unbedarft und unwissend wie ich bin,
habe ich mir einfach hier:
http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html den
Installer (uInitrd) gezogen und dazu das aktuellste Kernel Image
http://www.xilka.com/sheeva/3/3.5/3.5.7/release/1/ mit auf die SD Karte
gepackt. Alles brav wie immer nach der Cyrius Anleitung gemacht und
siehe da...der Installer hat natürlich gemerkt, dass es sich um nen
andren Kernel handelt.
Mist! Außerdem fehlen laut installer die Kernel Module. Jetzt stellt
sich mir die Frage, ob ich "nur" eine passende uInitrd Datei brauche
oder ich die Kernel Module so iwie nachträglich reinschießen kann. Oder
gar beides?
Ich finde auch nirgendwo ne Anleitung wie ich das Xilka Linux
installieren kann. Irgendjemand ne Idee? Im plugcomputerforum find ich
auch iwie kein einziges HOW2. Oder ich bin zu blöd.
Hoffe mich kann jemand aufklärn.
Gruß
Tim
Hallo Tim,
>..der Installer hat natürlich gemerkt
Ich weiss nicht, was das ist. Aber ich habe lmde (linuxmint debian) in
virtualbox laufen. Ich hole mir zuerst die Images, lade sie per tftp in
den RAM und lass sie laufen. Dann kann ich den Kernel entweder in u-boot
oder über openocd (momentan läuft es noch nicht) ins flash schreiben.
Rootfs befindet sich ja schon im flash. Der neue Kernel muss es ja
wissen (hoffe ich).
Ich habe den Weg deswegen gewählt, da ich den Kernel selber modifizieren
will. Wenn ein Kernel läuft, nehme ich davon die sourcen, ändere und
bilde. Danach über tftp oder openocd laden und testen.
Gruss
Denis
Hi Dennis,
also ich mache nix über tftp was am Prinzip jedoch zumindest nach meinem
Verständnis nix ändert?
Entweder man zieht sich das uImage mit den Installer Dateien per USB,SD
oder eben TFTP. Das Debian Installer File, was ich verwende ist eben ein
interaktiver Installer. Sprich der Plug läd das uImage und ich kann
interaktiv schon mal per Menü Festplatten partitionieren, Passwörter
festlegen und Co. Mir ist der Sinn von der anderen Datei (uInitrd oder
nur Initrd) die man brauch nicht so wirklich klar. Warum willst du den
Kernel modifzieren?
Ich besitze den Plug schon länger und kann dir da ein bisschen zu
erzählen.
Es gibt z.b. einen Kernel Bug der den Betrieb über SD Karte extrem hart
ausbremst:
http://computingplugs.com/index.php/Fixing_SDHC_access_in_the_Orion/Mainline_kernel
Die Seite ist ab und zu mal down. Sollte bald wieder funktionieren.
Sobald man z.b. das neuste Debian auf SD karte installiert, wird das
ganze OS sehr sehr träge. Dazu bricht die Übertragungsrate von z.b.
Samba auf ca. 5MB/s zusammen. Ob der angebotene Patch hilft, hab ich
mangels Wissen nie testen können.
Gleiches Bild bietet sich einem wenn man dmcrypt auf ner HDD verwendet.
Wobei ich da die Hoffnung habe, dass das xilka Linux dem ganzen via
Hardware AES Support unter die Arme greift. Aber ich kriegs ja nichmals
hin das zu installen :D
Hast du da evt ne Idee wie man das hinkriegen könnte ?
achja mit interaktiven Menü mein ich natürlich das Ding was aufpoppt
nachdem man:
setenv bootargs console=ttyS0,115200n8
base-installer/initramfs-tools/driver-policy=most
und
bootm 0x00800000 0x01100000
eingegeben hat...das nenn ich einfach mal "Debian Installer"...
Hallo Tim,
>.. (uInitrd oder nur Initrd)..
dies ist ramdisk, in dem sich normalerweise rootfs befindet. Aber rootfs
ist ja schon im flash
> Warum willst du den Kernel modifzieren?
evtl. neue Funktionalitäten hinzufügen oder welche deinstallieren
>.. Hast du da evt ne Idee wie man das hinkriegen könnte ?
Wie gesagt, bei mir habe ich es noch nicht zum Laufen gebracht.
>..achja mit interaktiven Menü mein ich natürlich das Ding was aufpoppt
Also hier poppt da nichts auf. Das sind ja alle u-boot commandos und
werden in der u-boot commandozeile eingegeben oder wo gibst du die ein,
damit was aufpoppt. grübel ??
gruss
denis
Befehlen der Debian Installer in der Konsole auf.
Ich habe übrigens gerade noch diese Anleitung gefunden:
http://blog.posativ.org/2010/ubuntu-auf-s-sheevaplug/
Auf diese Art und Weise habe ich das Ganze nocht nicht probiert. Werde
aber gleich mal gucken wie weit ich damit komme.
Sooo habs mit Windows ebenfalls nicht hinbekommen (opencd Fehler...).
Irgendwie ist die Debian Anleitung von Cyrius über die serielle Konsole
die einzige, die bei mir zuverlässig funktioniert :D
Ich setz das Debian grad nochmal komplett neu auf SD Karte auf und schau
mal wie der (Crypto) Speed so ist.
HDD haut bei mir verschlüsselt via Samba im Schnitt 5MB/s raus. Mit
peaks von 7.5MB/s und Tälern von 2MB/s....das kanns einfach nicht sein.
Ich will mehr.
So ich bins nochmal :D
Also unverschlüsselt bringt das Debian auf SD Karte mit 2.6.32-5er
Kernel den vollen LAN Speed von einer Sandisk Extreme Class 10 Karte.
Verschlüsselt auch. Aaaaaaber nicht auf die Dauer wie der Screenie
zeigt. Wird da jemand schlau draus ? Es schwankt alle 10 Sekunden oder
so zwischen 200KB/s und 11MB/s.
Es wurde eine mehrere GB große Datei zum Test herangezogen. Die gleiche
wie beim unverschlüsselten Test. Heute oder morgen werde ich das noch
mal mit ner angeschlossenen HDD testen...
Update: Die Peaks nach oben sind bei Gigabit Netz viel höher. Da kann
man schon mal 20MB/s erreichen. Allerdings bricht auch dann die
Übertragungsrate wieder drastisch ein. Jedoch kommt mir der Transfer per
Ggigabit schneller vor. Das Diagramm sieht aber genau so zackig aus. Die
CPU ist laut webmin übrigens dabei zu 100% im IDLE. Wenn die krassen
Einbrüche nich wärn, wär ich ja schon zufrieden :D
Wär cool wenn mal andere ihre Erfahrung mit dm crypt und samba posten
könnten :)
Denis D. schrieb:> Aber trotzdem habe ich "setenv bootargs console=ttyS0,115200"> ausgeführt.> Verhalten leider gleiche. Was kanns noch sein ??
Vom UBoot her passt alles. Hast Du es schon mal mit eimen Kernelimage
versucht, das von einem USB-Stick geladen wurde? Nicht das beim
tftp-Download noch irgend etwas schief läuft.
> Hier hatte ich 'sheevaplug.conf' genommen, in "openocd.cfg" umbenannt
Solltest Du nicht machen. Nutze lieber die Kommandozeilenparameter von
openocd.
>> interface ft2232> ft2232_layout sheevaplug> ft2232_vid_pid 0x9e88 0x9e8f> ft2232_device_desc "SheevaPlug JTAGKey FT2232D B"> adapter_khz 2000>> Auch hier leider keine Veränderung..
Das ist die JTAG-Interface-Konfiguration der SheevaPlug, nicht die
Board-Konfiguration.
Die (Gesamt-)Konfiguration für openocd setzt sich aus mehreren Dateien
zusammen:
* board config: in Deinem Fall die Beschreibung der Sheevaplug
(config/board/sheevaplug.cfg)
* target config: die CPU-Beschreibung mit CPU-IDs und dem JTAG-Chain
(config/target/feroceon.cfg)
* interface config: die Beschreibung des Interfaces, das PC und Sheeva
miteinander verbindet (config/interface/sheevaplug.cfg)
Dabei reicht die Angabe der Board-Config, weil diese die beiden anderen
Dateien nachlädt.
Mach's Dir doch nicht so schwer. Nimm doch fürs Erste die von Marvell
gelieferte Konfiguration, die im Installer-Paket enthalten ist. Wie das
Ganze aufgerufen wird ist in der runme zu sehen.
Aus dem Verzeichnis sheevaplug-installer-v1.0/uboot/openocd:
Stefan L.
> Hast Du es schon mal mit eimen Kernelimage> versucht, das von einem USB-Stick geladen wurde?
Auf deine Empfehlung hin habe ich folgende images von usb geladen. Der
Effekt leider gleiche.
sheeva-2.6.39.4-uImage
sheeva-3.1.9-uImage
sheeva-3.4.7-uImage
sheeva-3.5.4-uImage
sheeva-3.5.7-uImage
xilka-Kernel kriege ich nicht zum Laufen. Ich bin mit meinem Latein am
Ende.
Der Kernel von plugcomputer
uImage.8.6plug
lief auf Anhieb.
Eigentlich brauche ich einen aktuellen Kernel mit Sourcen, der auf
meinem Box läuft. dann könnte ich damit etwas spielen. Es muss nicht
unbedingt xilka-Kernel sein.
> ..>..> ./openocd -f config/board/sheevaplug.cfg -s config/>..>..
Danke für eine Super-Beschreibung. Es läuft ganz gut bis auf die
Ausführung von einem step mit "s" oder "n"
lmde u-boot-2010.06 # arm-linux-gdb u-boot
..
..
(gdb) l
61 ldr pc, _hang
62 ldr pc, _hang
63 ldr pc, _hang
64 ldr pc, _hang
65
66 _hang:
67 .word do_hang
68 /* pad to 64 byte boundary */
69 .word 0x12345678
70 .word 0x12345678
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) s
Cannot find bounds of current function
(gdb)
Woran könnte dies liegen ??
Denis D. schrieb:> Stefan L.>> Hast Du es schon mal mit eimen Kernelimage>> versucht, das von einem USB-Stick geladen wurde?> Auf deine Empfehlung hin habe ich folgende images von usb geladen. Der> Effekt leider gleiche.>
Evtl. muss für diese Kernel in Kombination mit Deiner UBoot-Version noch
1
mainlineLinux=yes
2
arcNumber=2097
im UBoot-Environment gesetzt werden. Bin erst jetzt wieder drauf
gekommen, dass da mal was war mit dem Marvell-UBoot.
> (gdb) s> Cannot find bounds of current function> (gdb)>> Woran könnte dies liegen ??
Fehlende Debuginformationen. Frag mal Google, da solltest Du fündig
werden.
>Läuft "Installer-Paket" auch unter windows ?
Ja, Marvell liefert openocd sowohl als 32bit-Linux-Version als auch als
32bit-Windows-Version.
timpi.
> mainlineLinux=yes> arcNumber=2097
Wie oben gesetzt und wie unten Kernel geladen und gestartet
tftpboot 0x02000000 sheeva-3.5.7-uImage
bootm 2000000
Gleiches Verhalten
Dann habe ich diese Seite gefunden
http://wiki.amahi.org/index.php/Marvell_Plug_Computer_Booting
Und wie folgt vorgegangen
"bootargs" unverändert gelassen
--------------------------------
bootargs=console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
rw
root=/dev/mtdblock1 rw
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
Diese angepasst
---------------
setenv mainlineLinux yes
setenv arcNumber 2097
setenv bootcmd_usb 'usb start; fatload usb 0:1 0x6400000
sheeva-3.5.7-uImage'
setenv bootcmd 'run bootcmd_usb; bootm 0x6400000'
saveenv
reset
Mein Ziel war sheeva-3.5.7-uImage von usb zu starten und ihm rootfs im
flash zu übergeben.
Das habe ich wahrscheinlich nicht geschafft. Denn Kernel hat gestartet
aber am Ende meldete er sich mit Kernelpanic.
No filesystem could mount root, tried: ext3 ext2 ext4 cramfs vfat msdos
jfs
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,1)
[<c000d08c>] (unwind_backtrace+0x0/0xe0) from [<c0461584>]
(panic+0x74/0x1b4)
[<c0461584>] (panic+0x74/0x1b4) from [<c05deca4>]
(mount_block_root+0x1d4/0x218)
[<c05deca4>] (mount_block_root+0x1d4/0x218) from [<c05deecc>]
(mount_root+0xec/0x110)
[<c05deecc>] (mount_root+0xec/0x110) from [<c05df04c>]
(prepare_namespace+0x15c/0x1bc)
[<c05df04c>] (prepare_namespace+0x15c/0x1bc) from [<c05de90c>]
(kernel_init+0x168/0x1a)
[<c05de90c>] (kernel_init+0x168/0x1a4) from [<c00094e8>]
(kernel_thread_exit+0x0/0x8)
Was läuft da schief und warum läuft es überhaupt nicht, wenn ich den
Kernel mit "tftpboot 0x02000000 sheeva-3.5.7-uImage" übertrage
> ..> und warum läuft es überhaupt nicht, wenn ich den> Kernel mit "tftpboot 0x02000000 sheeva-3.5.7-uImage" übertrage
Sorry, es läuft auch, wenn ich den Kernel mit "tftpboot 0x02000000
sheeva-3.5.7-uImage" übertrage. Aber endet auch mit Kernel-Panic
elvis61 schrieb:> Diese angepasst> ---------------> setenv mainlineLinux yes> setenv arcNumber 2097> setenv bootcmd_usb 'usb start; fatload usb 0:1 0x6400000> sheeva-3.5.7-uImage'> setenv bootcmd 'run bootcmd_usb; bootm 0x6400000'> saveenv> reset>> Mein Ziel war sheeva-3.5.7-uImage von usb zu starten und ihm rootfs im> flash zu übergeben.>> Das habe ich wahrscheinlich nicht geschafft. Denn Kernel hat gestartet> aber am Ende meldete er sich mit Kernelpanic.
Naja ist doch schon einen Schritt weiter.
Und wenn Du genauer hinschaust, dann sagt er auch warum:
> No filesystem could mount root, tried: ext3 ext2 ext4 cramfs vfat msdos> jfs> Kernel panic - not syncing: VFS: Unable to mount root fs on> unknown-block(31,1)> Was läuft da schief
Schau Dir mal die Bootmeldungen weiter oben an. Der findet die entweder
NAND-Flash-Partitionen nicht (1) oder unter '/dev/mtdblock1' ist kein
valides Filesystem (2). (2) ist aber unwarscheinlich, es sei denn, Du
hast schon was im Flash gelöscht.
Bei (1): ersetzte mal das 'nand_mtd' in den Bootargs durch 'orion_nand'.
In den neueren Kerneln wurde das umbenannt und der Name in den bootargs
muss exakt mit dem im Kerneltreiber übereinstimmen.
Bei (2): Prüfe ob wirklich ein Filesystem im NAND-Flash ist. Das geht
aber nur, wenn Du ein anderes Device als rootfs benutzt (USB-Stick,
SD-Card, ...).
timpi.
> Cannot find bounds of current function> (gdb) s> Cannot find bounds of current function> (gdb)>> Woran könnte dies liegen ??
Wahrscheinlich hat Dein uboot keine Symboltabelle...
(1) nand_mtd mit orion_nand ersetzen
Dies habe ich in "bootargs_1" getan. Siehe dazu
"sheeva-uboot-cmdline.txt"
bootcmd_2=setenv bootargs $(bootargs_1); run bootcmd_tftp_1
Keine Veränderung. s. dazu "sheeva-boot-3.5.7.txt"
Dann habe ich folgendes probiert
bootcmd_3=setenv bootargs $(console_1); run bootcmd_tftp
Hier wurde "initrd" aus "sheevaplug-installer-v1.0" geladen und es lief
hoch
s.dazu "sheeva-boot-3.5.7-initrd.txt"
(2) Flash ist nicht gelöscht. Denn nach wie vor läuft orig. Kernel mit
orig. Flash-rootfs hoch.
bootcmd_1=setenv bootargs $(bootargs_orig); run bootcmd_orig
Kernel-3.5.7 läuft immer noch nicht mit dem rootfs im Flash
Auffallend ist folgendes
Mit Flash-Rootfs findet er 2 partitionen
--------------------------------------------
2 cmdlinepart partitions found on MTD device orion_nand
Creating 2 MTD partitions on "orion_nand":
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "rootfs"
Mit initrd findet er 3 partitionen
----------------------------------
Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"
Weiss immer noch nicht, was nicht zusammenpasst
Vlt. liegt es auch da dran, dass flash-organisation widersprüchlich ist.
zB.
console_orig=console=ttyS0,115200
mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
und
bootargs_orig=console=ttyS0,115200
mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
rw root=/dev/mtdblock1 rw
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
console_orig: 0x1ff00000@0x100000(root)
bootargs_orig: 0x1fb00000@0x500000(rootfs)
Müssten die nicht gleich sein. Denn im flash kann sich rootfs nicht an
verschiedenen stellen befinden.
Ich gehe von folgenden Annahmen aus. Doku dazu habe ich nicht finden
können.
Adressbereich Size mtdblock
-------------------------------------------------------
u-boot 00000000 .... 000A0000 000A0000 0
u-boot ???????? .... ???????? ???????? 1
env.
kernel 00100000 .... 004FFFFF 00400000 2
rootfs 00500000 .... 1FFFFFFF 1FB00000 3
Ich weiss nicht, ob meine Annahme richtig ist. Bitte evtl. um Korrektur
IT WORKS.....
Ich bootete nochmal den mitgelieferten Kernel und stellte fest, dass
Flash "jffs2" hat und änderte bootargs wie folgt.
setenv bootargs_1 'console=ttyS0,115200
mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs
) root=/dev/mtdblock1 rw rootfstype=jffs2
ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none'
Dann bootete es und legte 2 Partitionen an
Creating 2 MTD partitions on "orion_nand":
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"
Dann machte ich folgenden Experiment
setenv bootargs_test 'console=ttyS0,115200
mtdparts=orion_nand::0xc0000@0(uboot)ro,0x400000@0x100000(uImage),0x1fb0
0000@0x500000(rootfs)rw root=/dev/mtdblock2 rw rootfstype=jffs2'
Damit lief es auch und legte 3 Partionen an
Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"
Meine erste Verständnisfrage. Wie passt die "mtdparts"-Angabe mit
Flashinhalt zusammen. Denn Flashinhalt ist doch fix. Wenn ja, wie ist es
möglich, dass ich über mtdparts angeben kann, wo sich rootfs im flash
befindet. Denn in bootargs_test funktionierte "root=/dev/mtdblock1"
nicht.
Also es haben folgende Angaben zum Erfolg geführt
- orion_nand (Danke timpi)
- jffs2 (Danke timpi, durch deinen Tip bin ich drauf gekommen)
Mir fehlt folgende Infos
- Flashinhalt (wo befindet sich was ?)
Denn ich zweifele an meine eigenen Angaben in vorherigen dem Beitrag
- Zusammenhang zw. mtdparts und Flashinhalt
- Kernel 3.5.7 - Source (damit ich Änderungen machen kann)
So endlich habe ich den 1.Meilenstein erreicht.
Ich habe die Files unter
http://www.xilka.com/sheeva/3/3.6/3.6.9/source/
downloaded, den Kernel mit den angegebenen patches gepatcht, kompiliert
über tftp geladen und es läuft.
Ausserdem kenne ich jetzt meinen Flashinhalt
Adressbereich Size mtdblock
-----------------------------------------------------------
uboot 0000_0000 .... 0009_FFFF 000A_0000 0
uboot-env 000A_0000 .... 000B_FFFF 0006_0000 1
kernel 0010_0000 .... 004F_FFFF 0040_0000 2
rootfs 0050_0000 .... 1FFF_FFFF 1FB0_0000 3
Nun werde ich mich mit der Änderung des Kernels und der Funktionsweise
von openOCD beschäftigen.
Jetzt wieder etwas Zeit für Hobby.
Ich habe den Kernel compiliert und auf Target mittels openOCD und gdb
geladen und versucht zu debuggen. Mein 1.Versuch war ein BP auf
start_kernel zu setzen und dort zu halten. Dies gelang mir nicht.
Probleme habe ich angehängt.
Ich hoffe, Ihr habt etwas Zeit und könnt mir einige Hinweise geben.
Besonderes darauf, was ich gegen "Error: Target not halted" machen kann.
Gruss
elvis61
So ich denke, ich habe es einigermassen hingekriegt. Aber ich bekomme
immer noch.
"Unable to set 32 bit software breakpoint at address c05ee48c - check
that memory is read/writable"
Kann vlt. jemand hier weiterhelfen
Gruss
elvis61
Hallo,
Hier ist anscheinend momentan keiner zu Hilfe bereit.
Ich bin momentan mit meinem JTAG-Debug-Problem einen Schritt
weitergekommen. Ich konnte u-boot einwandfrei debuggen. Dann habe ich
mir bei beiden System.map File angeschaut.
u-boot: 00600000 T __image_copy_start ... 0069c4b0 B _bss_end_
linux: c0004000 A swapper_pg_dir ... c06ced40 A _end
Ich denke die linux-Adressen sind flash-Adressen. Daher bekomme ich die
obengenannte Fehlermeldung. Aber dann habe ich in Ketnelkonfig geschaut.
Dort steht.
(0x0) Physical address of main memory
Eigentlich ok. Warum kriege ich noch die Adressen C00.... ?
Ein anderes Problem:
bootargs=console=ttyS0,115200
mtdparts=orion_nand.0:768k(uboot+env)ro,4MB(uImage)ro,-(rootfs)ro
root=/dev/mtdblock2 rw rootfstype=jffs2
Dann starte ich den Kernel..
..........
..........
Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"
..........
..........
debian login: root
Password:
Last login: Sun Sep 30 20:00:33 UTC 2012 on ttyS0
Linux debian 3.7.8 #1 PREEMPT Tue Mar 5 09:49:05 CET 2013 armv5tel
..........
..........
root@debian:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 1fb00000 00020000 "root"
root@debian:/# mount -t jffs2 /dev/mtdblock2 /mnt/nand
root@debian:/# ls /mnt/nand
bin dev home media opt root selinux sys usr
boot etc lib mnt proc sbin srv tmp var
root@debian:/# umount /mnt/nand
# mount -t jffs2 /dev/mtdblock0 /mnt/nand
uncorrectable error : uncorrectable error :
uncorrectable error : uncorrectable error :
uncorrectable error : mount: /dev/mtdblock0: can't read superblock
root@debian:/# umount /mnt/nand
root@debian:/# mount -t jffs2 /dev/mtdblock1 /mnt/nand >>> NOK
mount: /dev/mtdblock1: can't read superblock
root@debian:/#
1.Frage: Wieso stimmen die Partitionsangaben zwischen "bootargs" und
Linuxausgaben.
Hier habe ich in der folgendes gefunden
"arch/arm/mach-kirkwood/sheevaplug-setup.c"
static struct mtd_partition sheevaplug_nand_parts[] = {
{
.name = "u-boot",
.offset = 0,
.size = SZ_1M
}, {
.name = "uImage",
.offset = MTDPART_OFS_NXTBLK,
.size = SZ_4M
}, {
.name = "root",
.offset = MTDPART_OFS_NXTBLK,
.size = MTDPART_SIZ_FULL
},
};
Muss man diese Struktur anpassen ??
Ich dachte mir Linux intepretiert "bootargs" und übernimmt die
mtd-Partitionen von dort ??
2.Frage: Warum kann ich die Partitionen "u-boot" und uImage" nicht
mounten ??
Hoffe auf Hinweise
Danke
Hallo Denis,
Denis D. schrieb:> Hallo,> Hier ist anscheinend momentan keiner zu Hilfe bereit.
Oder auch nicht in der Lage...
>u-boot: 00600000 T __image_copy_start ... 0069c4b0 B _bss_end_
== Physikalisch Adressen.
>linux: c0004000 A swapper_pg_dir ... c06ced40 A _end
== Virtuelle Adressen (man Memorymapping)
> Ein anderes Problem:> bootargs=console=ttyS0,115200> mtdparts=orion_nand.0:768k(uboot+env)ro,4MB(uImage)ro,-(rootfs)ro> root=/dev/mtdblock2 rw rootfstype=jffs2> Dann starte ich den Kernel..
Das Ergebnis sieht nicht so aus, als würden die mtdparts-Parameter dem
Kernel übergeben. Mich verwirren die unterschiedlichen Namen
("uboot+env" != "u-boot" und "rootfs" != "root").
> root@debian:/# cat /proc/mtd> dev: size erasesize name> mtd0: 00100000 00020000 "u-boot"> mtd1: 00400000 00020000 "uImage"> mtd2: 1fb00000 00020000 "root">> root@debian:/# umount /mnt/nand> # mount -t jffs2 /dev/mtdblock0 /mnt/nand> uncorrectable error : uncorrectable error :> uncorrectable error : uncorrectable error :> uncorrectable error : mount: /dev/mtdblock0: can't read superblock
Meinst Du wirklich, dass das U-Boot-Image in eienem jffs2-Filesystem im
Flash abgelegt ist? ..... Ist's aber nicht.
Du kannst den Inhalt der Partition lesen, gegebenenfalls auch schreiben,
aber mounten klappt nicht. Selbiges gilt für die uImage-Partition. Dort
liegt der Kernel 'blank' drinnen, ohne Filesystem (ok, n' bissl
UBoot-Header ist noch dabei).
>> 1.Frage: Wieso stimmen die Partitionsangaben zwischen "bootargs" und> Linuxausgaben.
Sei doch froh, dass sie stimmen. Da würd' ich doch nicht hinterfragen
;-).
> Ich dachte mir Linux intepretiert "bootargs" und übernimmt die> mtd-Partitionen von dort ??
Macht's eigentlich auch. Adhoc kann ich Dir da auch nicht weiterhelfen.
Müsste selber nochmal nachschauen ob's bei der Sheeva anders ist.
>> 2.Frage: Warum kann ich die Partitionen "u-boot" und uImage" nicht> mounten ??
siehe oben.
timpi.
Denis D. schrieb:> Hallo,> Hier ist anscheinend momentan keiner zu Hilfe bereit.
Da liegst Du völlig falsch. Hier sind einfach nur die ARM-Linux-Nerds
sehr rar gesäht.
Hier sind hauptsächlich MC-Bastler, die z.B. einen AVR direkt in ihre
Schaltungen einlöten und dann unter plain C programmieren.
Also völlig ohne spezielle Evaluation-Boards und BS.
Oder anders gesagt, Du fragst die falschen Leute. Ihnen dann auch noch
fehlende Hilfsbereitschaft zu unterstellen, ist grob unhöflich.
Es gibt bestimmt auch spezielle Linux-Foren, wo viel mehr Leute mit
Deinen Problemen was anfangen können.
Hallo Stefan,
Stefan L. schrieb:> == Virtuelle Adressen (man Memorymapping)
OK. Aber ich hänge an der Stelle und kriege mein JTAG-Debugger nicht zum
Laufen und bekomme immer die Fehlermeldung.
"Unable to set 32 bit software breakpoint at address c05ee48c - check
that memory is read/writable"
Was könnte ich tun ? irgend eine Idee ?
> Das Ergebnis sieht nicht so aus, als würden die mtdparts-Parameter dem> Kernel übergeben. Mich verwirren die unterschiedlichen Namen> ("uboot+env" != "u-boot" und "rootfs" != "root").
Wenn der Kernel hochfährt, sehe ich die Zeile
Kernel command line: console=ttyS0,115200
mtdparts=orion_nand.0:768k(u-boot)ro,4MB(uImage)ro,-(root)rw
root=/dev/mtdblock2 rw rootfstype=jffs2
Dann gehe ich davon aus, dass es übernommen wird.
Wie du siehst, habe ich diesmal die Parts genauso genannt wie im Kernel.
Muss es so sein ?
Ein anderes Phänomen ist. Egal wieviele Parts ich über "mtdparts"
übergebe, kann ich die interne Kernel Parts-Einstellung nicht ändern.
Ich dachte mir. Ich könnte über "mtdparts" die interne Einstellung
überschreiben.
Ist es nicht so ?
Ohne mtdparts-Angabe fährt er auch nicht hoch. Er kennt ja doch die
Partitionen. Warum braucht er noch die mtdparts-Angabe ???
> Meinst Du wirklich, dass das U-Boot-Image in eienem jffs2-Filesystem im> Flash abgelegt ist? ..... Ist's aber nicht.
Ich dachte. FS-Type bezieht sich auf den Flash-Device nicht auf den
Inhalt. Wie zB bei einer Festplatte.
> Du kannst den Inhalt der Partition lesen, gegebenenfalls auch schreiben,> aber mounten klappt nicht. Selbiges gilt für die uImage-Partition. Dort> liegt der Kernel 'blank' drinnen, ohne Filesystem (ok, n' bissl> UBoot-Header ist noch dabei).
Aber wie kann ich den Inhalt lesen/schreiben, wenn ich das nicht mounten
kann ?
Ich konnte root-Partition mounten und habe den Inhalt in "/mnt/root"
gehabt. So etwas kann ich lesen/schreiben Aber wie soll das andere
funktionieren, wenn ich es nicht mal sehe ??
> Sei doch froh, dass sie stimmen. Da würd' ich doch nicht hinterfragen> ;-).
Oops, da fehlt ein "nicht" am Satzende. Aber das meinst du ironisch,
denke ich ;).
> Macht's eigentlich auch. Adhoc kann ich Dir da auch nicht weiterhelfen.> Müsste selber nochmal nachschauen ob's bei der Sheeva anders ist.
Ich habe den neuesten Kernel von http://www.xilka.com/sheeva/ genommen.
Da habe ich config gecheckt. Eigentlich sind alle notwendigen Param
dafür gesetzt.
#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
elvis61
Hallo Peter,
Peter Dannegger schrieb:> Denis D. schrieb:>> Oder anders gesagt, Du fragst die falschen Leute. Ihnen dann auch noch> fehlende Hilfsbereitschaft zu unterstellen, ist grob unhöflich.
Sorry, dies war nicht meine Absicht.
Ich bin Newbie auf dem Gebiet und brauche Hilfe. Weisst du, wie
frustrierend es ist, wenn man nicht mal einen Schritt vorwärts kommt.
Momentan kann ich den anderen nicht helfen. Aber dies wird sich bestimmt
ändern.
>> Es gibt bestimmt auch spezielle Linux-Foren, wo viel mehr Leute mit> Deinen Problemen was anfangen können.
Wo denn ? Ich habe hier folgende Adressen. Da ist es auch nicht viel
anderes.
http://www.newit.co.uk/forum/ : danke Timpi
http://www.plugcomputer.org/http://www.sheevaplug.de/index.phphttp://www.gmane.org/
Es gibt nicht soviele wie Timpi.
elvis61
Eine andere Verständnisfrage:
Ich habe meine eigene rootfs (ramdisk) erstellt und damit den Kernel
hochgefahren. Dabei habe ich folgendes festgestellt.
booot> tftpboot 0x02000000 uImage
booot> tftpboot 0x08000000 initrd
booot> setenv bootargs 'console=ttyS0,115200'
booot> bootm 0x02000000 0x08000000
Unterschiedliche Ausgaben:
..
Kernel command line: console=ttyS0,115200
..
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
..
Welcome to Buildroot
buildroot login:
booot> tftpboot 0x02000000 uImage
booot> tftpboot 0x08000000 initrd
booot> setenv bootargs 'console=ttyS0,115200 root=/dev/ram rw'
booot> bootm 0x02000000 0x08000000
Unterschiedliche Ausgaben:
..
Kernel command line: console=ttyS0,115200 root=/dev/ram rw
..
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing init memory: 176K
..
Welcome to Buildroot
buildroot login:
Wie man sieht. Starte ich den Kernel mit
bootargs=console=ttyS0,115200 root=/dev/ram rw
Dann habe ich zusätzlich folgende Ausgaben
devtmpfs: mounted
Freeing init memory: 176K
Aber beides Mal fährt der Kernel hoch.
Was bedeuten die zusätzlichen Zeilen ?
Ist die Angabe "root=/dev/ram rw" notwendig ? oder Wofür ?
Wenn ja was wird damit bewirkt ?
Danke im Voraus
elvis61
Hallo Denis,
Dein Problem im Moment ist vermutlich, dass du UBoot und Kernel nicht
getrennt betrachtest. Weder setzt ein Linux-Kernel UBoot als Bootloader
voraus noch erwartet das UBoot eine Linux-Umgebung, die es starten soll.
Du solltest Dir mal die Abläufe im UBoot und beim Starten des
Linux-Kernels genauer anschauen, getrennt voneinander. Insbesondere die
Startparameter für den Kernel und die Bedeutung der verschiedenen
Optionen der UBoot-Befehle. In der UBoot-Referenz ist auch beschrieben
wie die einzelnen UBoot-Befehle arbeiten. O.K. dort wird oft auf
Linuxumgebungen Bezug genommen, aber es können auch ganz andere Systeme
sein.
> Was bedeuten die zusätzlichen Zeilen ?> Ist die Angabe "root=/dev/ram rw" notwendig ? oder Wofür ?> Wenn ja was wird damit bewirkt ?
Mal vereinfacht:
Der UBoot Befehl 'bootm' starten das Programm (hier der Linux-Kernel),
das an der angegebenen Adresse (1.Argument) liegt. Wird ein zweiter
Parameter angegeben, dann bedeutet das für Linux-Systeme, dass dort eine
Ramdisk zu finden ist. Diese beinhaltet allerdings 'nur' die initrd,
also alle Kernelmodule, die notwendig sind um das System grundsätzlich
arbeiten zu lassen (z.B. Filesystem-Treiber, Netzwerk-Treiber, ...) und
die nicht fest im Kernel integriert wurden.
In Deinem Fall (mit bzw. ohne 'root=/dev/ram rw') macht es keinen
Unterschied, da die initrd, die sowieso schon mal gemountet war, auch
als Rootfilsystem gemountet wird.
Wenn allerdings ein anderes Rootfs (z.B. eine Flashpartition oder eine
NFS-Freigabe) angegeben wird, dann sieht das Ganze anders aus. Zwar wird
dann die initrd beim Starten gemountet um die notwendigen Kernelmodule
nachzuladen, danach jedoch wird das dem Kernel als Parameter übergebene
Rootfs benutzt.
> Wo denn ? Ich habe hier folgende Adressen. Da ist es auch nicht viel anderes.
Je nach Frage, die Du hast, gibt's verschiedenen Anlaufstellen. Die
meisten Sheeva-Foren behandeln Anwenderthemen, evtl. mal Fragen zu
Portierung von Software auf die Plugs uder Erste Hilfe wenn nix mehr
geht. Themen zur 'richtigen' hardwarenahe Entwichling kommen dort so gut
wie nie vor. Da solltest Du auch mal über den ARM-Tellerrand blicken,
denn Probleme im UBoot oder Probleme mit dem Debuggen per JTAG kommen
auch auf anderen Plattformen vor.
UBoot: http://www.denx.de/ -> Dokumentation ( z.B. wie arbeitet 'bootm')
openocd: http://openocd.sourceforge.net/ -> Forum
Und google hilft bei richtiger Fragestellung auch weiter.
Stefan.
Hallo Stefan,
Ich habe folgende Beschreibungen durchgelesen.
http://www.ibm.com/developerworks/library/pa-migrate2/?ca=dgr-lnxw01BootProcesshttp://www.ibm.com/developerworks/library/l-linuxboot/
Ich verstehe das so
bootm kernel-addr initrd-addr
-----------------------------
Kernel kopiert initrd in RAM-disk (gleichzusetzen mit "/dev/ram" und
mountet dies und arbeitet damit.
Am Ende wird "root=" ausgewertet.
"root=" nicht angegeben: Kernel arbeitet mit RAM-disk weiter.
"root=/dev/ram": Kernel arbeitet mit RAM-disk weiter.
"root=/dev/mtdblock2 rw rootfstype=jffs2": Kernel unmountet
RAM-disk(/dev/ram") und mountet "/dev/mtdblock2" und arbeitet damit.
bootm kernel-addr und root=/dev/mtdblock2 rw rootfstype=jffs2
-------------------------------------------------------------
Kernel kopiert mtdblock2 in RAM-disk (/dev/ram) mountet dies und
arbeitet damit.
Am Ende wird RAM-disk unmountet und "/dev/mtdblock2" mountet.
Nun bleibt nur noch zu klären. Was passiert, wenn rootfs sich auf einem
Massenspeicher befindet.
zB: "root=/dev/hda"
Wird dies auch in RAM-disk kopiert. Dies wäre doch etwas zu gros für
RAM-disk oder hat Kernel in dem Fall ein default-RAM-disk ?
Gruss
denis
Stefan L. schrieb:> Wenn allerdings ein anderes Rootfs (z.B. eine Flashpartition oder eine> NFS-Freigabe) angegeben wird, dann sieht das Ganze anders aus. Zwar wird> dann die initrd beim Starten gemountet um die notwendigen Kernelmodule> nachzuladen, danach jedoch wird das dem Kernel als Parameter übergebene> Rootfs benutzt.
um das zu verstehen, habe ich folgenden Test gemacht.
bootcmd-test=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock2 rw
rootfstype=jffs2; tftpboot 0x02000000 uImage; tftpboot 0x08000000
initrd; bootm 0x02000000 0x08000000
Ich bekam diese Fehlermeldung
...............
...............
RAMDISK: gzip image found at block 0
List of all partitions:
1f00 1024 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 519168 mtdblock2 (driver?)
No filesystem could mount root, tried: jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,2)
[<c000d948>] (unwind_backtrace+0x0/0xe4) from [<c04826a4>]
(panic+0x80/0x1d0)
[<c04826a4>] (panic+0x80/0x1d0) from [<c0603cc0>]
(mount_block_root+0x1e4/0x224)
[<c0603cc0>] (mount_block_root+0x1e4/0x224) from [<c060490c>]
(initrd_load+0xac/0x2bc)
[<c060490c>] (initrd_load+0xac/0x2bc) from [<c0603fac>]
(prepare_namespace+0xc0/0x1bc)
[<c0603fac>] (prepare_namespace+0xc0/0x1bc) from [<c047b23c>]
(kernel_init+0x8/0x104)
[<c047b23c>] (kernel_init+0x8/0x104) from [<c0008d30>]
(ret_from_fork+0x14/0x24)
...............
...............
Und das hier läuft einwandfrei hoch.
bootcmd-test=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock2
rw; tftpboot 0x02000000 uImage; tftpboot 0x08000000 initrd; bootm
0x02000000 0x08000000
Aber nicht mit "root=/dev/mtdblock2" sondern mit "initrd". Er hat die
Angabe "root=/dev/mtdblock2" ignoriert.
Ich wollte bloss. dass der Kernel mit "initrd" startet und zum Schluss
auf "root=/dev/mtdblock2" umschaltet.
Oder habe ich da etwas völlig falsch verstanden ?? Got ist es
kompliziert.
Gruss
Denis
Ich denke, ein Blick in
.../linux/Documentation/kernel-parameters.txt
könnte Dir vielleicht weiterhelfen (in den Kernel Sources).
>No filesystem could mount root, tried: jffs2
Sieht für mich aus, als ob Dein rootfs kein jffs2 wäre.
>Kernel kopiert mtdblock2 in RAM-disk (/dev/ram) mountet dies und>arbeitet damit.
Wieso sollte er das mtdblock2 in die RAM-Disk kopieren?
Das FS wird natürlich direkt gemount und über die entsprechenden
Treiber auf das Device zugegriffen.
Selbes für "Massenspeicher" - mtdblock2 ist auch einer.
Moin,
Denis D. schrieb:>> Ich verstehe das so> ...> bootm kernel-addr initrd-addr> -----------------------------> Kernel kopiert initrd in RAM-disk (gleichzusetzen mit "/dev/ram" und> mountet dies und arbeitet damit.
Genau, und zwar von der mit initrd-addr angegebenen Adresse.
> bootm kernel-addr und root=/dev/mtdblock2 rw rootfstype=jffs2> -------------------------------------------------------------> Kernel kopiert mtdblock2 in RAM-disk (/dev/ram) mountet dies und> arbeitet damit.> Am Ende wird RAM-disk unmountet und "/dev/mtdblock2" mountet.
Auch richtig.
>> Nun bleibt nur noch zu klären. Was passiert, wenn rootfs sich auf einem> Massenspeicher befindet.>> zB: "root=/dev/hda">> Wird dies auch in RAM-disk kopiert. Dies wäre doch etwas zu gros für> RAM-disk oder hat Kernel in dem Fall ein default-RAM-disk ?
Nein, die wird nur gemountet. Vorraussetzungen sind:
* auf das Device kann zugegriffen werden (USB-Treiber, MTD-Treiber,
Netzwerktreiber, ....)
* das Filesystem, in dem das Rootfs vorliegt wird unterstützt. Entweder
der Kernel hat den passenden Treiber fest implementiert, oder dieser
werden aus der initrd als module nachgeladen.
>> RAMDISK: gzip image found at block 0
OK, initrd wurde erkannt
> List of all partitions:> 1f00 1024 mtdblock0 (driver?)> 1f01 4096 mtdblock1 (driver?)> 1f02 519168 mtdblock2 (driver?)> No filesystem could mount root, tried: jffs2> Kernel panic - not syncing: VFS: Unable to mount root fs on> unknown-block(31,2)
Nur 'ne Vermutung... Falscher NAND-Treiber?
Allerdings kann man bei so bruchstückhaften Informationen nicht wirklich
eine Aussage machen.
Stefan.
Hallo Stefan,
Danke für die Infos. Das alles ist jetzt etwas klarer für mich.
Aber ich habe immer noch nicht einen konkreten Fall gefunden, wo die
Angabe "root=/dev/ram" im linux-cmdline unbedingt notwendig wäre.
Kannst du mir ein Bespiel nennen ?
Das andere Thema wäre. Ich erzeuge momentan mein rootfs mit buildroot.
Ich habe herausgefunden, dass yocto dies auch kann. Aber das sind
mammut-tools. Gibt es auch kleine tools, die nur rootfs erstellen und
klein sind ?
Dennis
Denis D. schrieb:> Hallo Stefan,>> Danke für die Infos. Das alles ist jetzt etwas klarer für mich.> Aber ich habe immer noch nicht einen konkreten Fall gefunden, wo die> Angabe "root=/dev/ram" im linux-cmdline unbedingt notwendig wäre.>> Kannst du mir ein Bespiel nennen ?
Hm..., wüsste jetzt keinen.
> Das andere Thema wäre. Ich erzeuge momentan mein rootfs mit buildroot.> Ich habe herausgefunden, dass yocto dies auch kann.
Kannte ich noch nicht, danke.
> Aber das sind mammut-tools. Gibt es auch kleine tools, die nur rootfs > >
erstellen undklein sind ?
Diese Tools (ich habe von den beiden jedoch nur buildroot, allerdings
nicht für die Shheva, benutzt) nehmen Dir halt 'ne Menge Arbeit ab. Du
könntest auch alles manuell erledigen: Sourcecode aller gewünschten
Pakete downloaden, entpacken, evtl. patchen, konfigurieren, compilieren,
installieren. Dann noch die Konfigurationsdateien für das Zielsystem
anpassen und das rootfs-Image erstellen.
Ausserdem ist es relativ einfach eigene Pakete in das Buildroot-System
einzubinden.
Und wenn Deine Projekte größer werden, dann kannst Du auch einen eigene
Buildumgebung aufsetzen.
Wenn Du allerdings alle Binaries schon vorliegen hast (bei buildroot
unter output/target/) und nur ein Image daraus oder ein existierendes
Image manipulieren willst, kannst Du das auch manuelle machen. Du
findest für diesen Schritt 'ne Menge Anleitungen im Netz, jenachdem was
für ein Imageformat vorliegt und rauskommen soll.
Thread beobachten
Seitenaufteilung abschalten