Hallo, wie viele von euch wissen gibt es ja in der Fritzbox z.B. fest eingebaute Flash Speicher, auf denen entweder die Software liegt, die die Fritzbox bootet oder in der auch z.B. die Daten gespeichert sind. Wird eine Fritzbox (mein Beispiel) geflasht, so wird der Speicher für das Betriebssystem gelöscht und neu beschrieben und dann neu gebootet, damit das aufgespielte System laufen kann. Ich frage mich jetzt, mit Bezug zu einem Raspberry PI, ob ich (hypothetisch) wohl die SD-Karte durch einen Festspeicher ersetzen könnte. Bei meinem Computer weiß ich, dass das BIOS des Systems diese Festplatte als solchen Speicher erkennt. Beim Raspberry PI wird der Broadcom Prozessor das erste Bit der Speicherkarte aufrufen und dort den Bootloader starten; zumindest gehe ich davon aus. Kann (und wenn wie) ich einen Speicher an dieser Stelle integrieren und ist die Schnittstelle des Broadcom Chips, dort wo die SD Karte angeschlossen ist, kompatibel zu Festspeichern? Wir befinden uns ja noch vor jedem Bootvorgang, also noch vor dem Laden einer jeden Software, weshalb das aus meiner Sicht eine Frage zum Chip / zur Hardware ist. Ein kurzer Überblick und / oder eine Beantwortung wäre sehr nett. MfG
:
Verschoben durch Moderator
Kai S. schrieb: > Ich frage mich jetzt, mit Bezug zu einem Raspberry PI, ob ich > (hypothetisch) wohl die SD-Karte durch einen Festspeicher ersetzen > könnte. Klar. Es gibt viele verschiedene "Festspeicher". Die SD-Card ist auch ein Festspeicher. An Schnittstellen sind (Q)SPI, Hyperbus, (E)MMC, SD-Bus, PCIe, ... üblich. Auch die SD-Card kann SPI. Kai S. schrieb: > Kann (und wenn wie) ich einen Speicher an dieser Stelle integrieren und > ist die Schnittstelle des Broadcom Chips, dort wo die SD Karte > angeschlossen ist, kompatibel zu Festspeichern? Wenn du dir einen kompatiblen "Festspeicher" suchst dann ja. Du könntest die SD-Card schlicht festkleben und schon ist es ein "Festspeicher".
:
Bearbeitet durch User
Dem entnehme ich, dass da nichts zwischen kommt, sofern die Schnittstelle gleich ist und Festspeicher direkt mit 8 Pins angebunden werden? Wie kann über jegliche Schnittstelle festgestellt werden, welche Kapazität der betreffende Speicherchip hat; darf ich das auch noch eben fragen? Ist im Speicherchip ein Bereich für die Kennzeichnung, Größe, Art, etc. definiert, der nicht überschrieben wird? Funktioniert das so? Denn den gesamten Speicher einmal durchtesten wie groß er ist (bis er nicht mehr beschreibbar ist), würde zu lange dauern. Danke im Voraus. (es geht bei mir um Grundlagen)
:
Bearbeitet durch User
Kai S. schrieb: > Festspeicher direkt mit 8 Pins angebunden werden? Das kommt sehr drauf an was das für ein Speicherinterface ist. SPI gibt es mit 4 Leitungen, HyperBus hat minimal 12. Kai S. schrieb: > Wie kann über jegliche Schnittstelle festgestellt werden, welche > Kapazität der betreffende Speicherchip hat; darf ich das auch noch eben > fragen? Entweder man muss das nicht wissen weil das schon eingebaut ist als feste Konstante oder man kann den Speicher fragen. Die haben oft ein paar Konfigurations- und Statusregister. Kai S. schrieb: > Ist im Speicherchip ein Bereich für die Kennzeichnung, Größe, Art, etc. > definiert, der nicht überschrieben wird? Funktioniert das so? Kann man machen bei manchen Modellen. Aber so ein Write Protect gibt es nicht immer. Kai S. schrieb: > Denn den gesamten Speicher einmal durchtesten wie groß er ist (bis er > nicht mehr beschreibbar ist), würde zu lange dauern. Naja als Hersteller baut man die Firmware für ein Produkt das man kennt. Da muss man die Speichergröße nicht herausfinden. Den Speicher hat man da selber hingebaut oder zumindest entschieden dass der da hingebaut wird.
Gustl B. schrieb: > Naja als Hersteller baut man die Firmware für ein Produkt das man kennt. > Da muss man die Speichergröße nicht herausfinden. Den Speicher hat man > da selber hingebaut oder zumindest entschieden dass der da hingebaut > wird. In meinem Beispiel spreche ich jetzt von einem Raspberry PI und ersetze z.B. den SD Slot mit einem passenden Bus durch einen Speicher. Dann gibt es, da ich Raspbian benutze, ja keine genaue Kennzeichnung im Prozessor für den Speicher (dürfte ja wie bei einem PC sein und keine Firmware außer dem Kernel verbaut sein). Der Kernel hat ggf. für die entsprechende Festplatte SD-Drive Speicherchip den richtigen Treiber bereits integriert oder ich muss ihn als Modul nachladen oder einkompilieren. Gibt es da Anforderungen an ein SpeicherMODUL, sodass dem eigentlichen Speicher noch ein Mikroprozessor / fester Chip vorgeschaltet sein muss, der dann diese Register mit der Größe, etc. beinhaltet? Ist das in der Spezifikation ((Q)SPI, Hyperbus, (E)MMC, SD-Bus, PCIe, ...) festgelegt oder wie funktioniert das? Nehmen wir zum Beispiel einen ATMEL AT27C010, was laut meiner Sicht ein "reiner" Speicher, ohne feste Register ist. Wenn ich den jetzt in Raspbian auf meinem Raspberry PI als /dev/sda einbinden möchte, mit einem Dateisystem versehen und formatieren möchte, was muss ich dann noch gemacht haben (vorgeschaltet haben), damit das funktioniert? Betrachten wir den Speicher und die vorgeschalteten Chips als "imaginäre Festplatte". Das wäre meine Frage. Für die Antwort und Geduld schon jetzt vielen Dank.
:
Bearbeitet durch User
> In meinem Beispiel spreche ich jetzt von einem Raspberry PI und ersetze > z.B. den SD Slot mit einem passenden Bus durch einen Speicher. Dann gibt > es, da ich Raspbian benutze, ja keine genaue Kennzeichnung im Prozessor > für den Speicher (dürfte ja wie bei einem PC sein und keine Firmware > außer dem Kernel verbaut sein). > Der Kernel hat ggf. für die entsprechende Festplatte / SD-Drive / > Speicherchip den richtigen Treiber bereits integriert oder ich muss ihn > als Modul nachladen oder einkompilieren. Ich habe mich ein wenig umständlich ausgedrückt: Z.B. weiß das Betriebssystem, dass es ein SMD20 Chip ist, hat aber keinen Treiber dafür. Also muss es doch eine spezielle Kennzeichnung geben, die entweder, wie ich hier bereits erfahren habe, in speziellen Registern im Speicherchip vorliegt oder, wie ich mir das dachte, auch von einem vorgeschalteten Chip bereitgestellt wird. Ist das so? Zum 2. Teil: Und dann gibt es div. Speichermodule, wie USB-Sticks oder Festplatten, etc., die von Linux / Unix als Speicher eingehängt werden können, ohne, dass ein spezieller Treiber installiert wird. Gibt es dafür einen Standard oder mache ich mir das zu kompliziert, hängt es also von einem bereits dafür ausgelegten Standard für den Chip selbst ab? Der Standard zur Übertragung ist SATA, in div. Ausführungen und mit unterschiedlichen Geschwindigkeiten; hierfür wird dann ja sicherlich ein spezieller Chip zur Umsetzung auf das Speichermedium in der Festplatte vorhanden sein; beim USB Stick, ist es da auch so? Das wird ein fester Chip sein, der die "Vermittlung" zwischen dem Computer und dem reinen speicher übernimmt und gleichzeitig auch die Kenndaten zur Verfügung stellt, richtig? So, wie mein WLAN Dongle von AVM unter anderem einen kleinen Speicherbereich für zu installierende Software hat, wo der chip die Ansteuerung WLAN-Stick / Speicherbereich regelt, müsste es doch auch beim USB Stick sein, richtig? Dann müsste ich doch theoretisch solch einen Chip auch manuell mit einer Firmware bauen können, also z.B. mit einem ATMEL Prozessor, der dann einen Speicherchip nachgeschaltet hat und nach der Spezifikation einer der o.agg. Standards funktioniert, richtig? Das wäre dann mein Ziel. Ich danke schon jetzt.
:
Bearbeitet durch User
Kai S. schrieb: > SMD20 Chip Was ist das? Kai S. schrieb: > ohne, dass ein spezieller Treiber installiert wird. Speziell nicht, aber ein Treiber muss installiert sein. Und zwar für die https://en.wikipedia.org/wiki/USB_mass_storage_device_class . Kai S. schrieb: > Der Standard zur Übertragung ist SATA SATA umfasst sehr viel. Nicht nur die physikalische Übertragung, sondern auch das Protokoll, nämlich https://de.wikipedia.org/wiki/ATA/ATAPI . Kai S. schrieb: > Das wird ein fester Chip sein, der die "Vermittlung" zwischen dem > Computer und dem reinen speicher übernimmt und gleichzeitig auch die > Kenndaten zur Verfügung stellt, richtig? Oft ist das nur ein Chip, also Controller/SoC und Flashspeicher in einem Package. Kai S. schrieb: > Dann müsste ich doch theoretisch solch einen Chip auch manuell mit einer > Firmware bauen können, der dann einen Speicherchip nachgeschaltet hat > und nach der Spezifikation einer der o.agg. Standards funktioniert, > richtig? Klar, kannst du. Du brauchst einen Mikrocontroller/oder Schnelleres und ein paar IOs die die Anforderungen von der gewünschten Schnittstelle erfüllen. Also wenn du einen USB Speicher bauen willst, dann nimm einen Mikrocontroller mit USB Device Schnittstelle. Aber: Damit du von so einem Speicher auch booten kannst, muss im BIOS/Firmware/ ... auch irgendeine Art Treiber zur Verfügung stehen. Ein PC kann z. B. üblicherweise nicht von einer SD-Card booten, eben weil das das Bios nicht kann. Prinzipiell geht das schon, aber ist eben nur dann möglich wenn es das BIOS/Firmware/... unterstützt.
Moin, Kai S. schrieb: > Z.B. weiß das Betriebssystem, dass es ein SMD20 Chip ist, hat aber > keinen Treiber dafür. Das waere sehr eigenartig. Woher soll denn das Betriebssystem sowas wissen, wenns nicht auf den Speicher zugreifen kann und ihn fragen? Kai S. schrieb: > Und dann gibt es div. Speichermodule, wie USB-Sticks oder Festplatten, > etc., die von Linux / Unix als Speicher eingehängt werden können, ohne, > dass ein spezieller Treiber installiert wird. Gibt es dafür einen > Standard oder mache ich mir das zu kompliziert, hängt es also von einem > bereits dafür ausgelegten Standard für den Chip selbst ab? USB-Sticks und -festplatten sind USB-Massstrorage devices. Also Softwaremaessig werden die identisch angequakt. Und natuerlich brauchts dann unter Linux den entsprechenden Treiber. Es gibt fuer's booten von SoC keine Spezifikation. Ausser dem jeweiligen Datenblatt. Das macht jeder anders. Oft laeufts so, dass direkt nachdem Reset eine CPU anfaengt, code aus einem SoC internen ROM auszufuehren, mit dem werden dann bestimmte IO-Pins abgefragt und davon abhaengig ueber verschiedene Busse/Schnittstellen versucht, irgendwo aus einem evtl. angeschlossenen Baustein/Interface was auszulesen. Dann kanns sein, dass das was da gelesen wird, mit einer passenden Signatur versehen sein muss, sonst geht's nicht weiter. Wenn die Signatur passt, dann hat das gelesene oft einen Header in einem bestimmten Format, innerhalb dem z.b. RAM-Controller initialisiert werden koennen. Bis dahin kann man das DRAM nicht verwenden. Dann wird oft entweder der richtige oder ein Vor-Bootloader in irgendeinen RAM-Bereich kopiert und dann da hingesprungen. Dann gehts entweder los mit dem richtigen Bootloader oder tatsaechlich schon dem Betriebssystem/BareMetal. Aber wiegesagt: Das macht jeder anders, wie genau, steht im Datenblatt. Wenn man das nicht kriegt, sieht man ziemlich alt aus... Gruss WK
Kai S. schrieb: > Ich frage mich jetzt, mit Bezug zu einem Raspberry PI, ob ich > (hypothetisch) wohl die SD-Karte durch einen Festspeicher ersetzen > könnte. Beim Pi4 ist das auf jeden Fall möglich, bei den Vorgängermodellen nur dadurch, dass du einen Festspeicher findest, der sich nach außen hin wie eine SD-Karte verhält. Das Problem beim Raspi ist, dass zur Bootzeit ein völlig proprietär abgeschottetes System das Sagen hat. Du hast keinen Zugriff auf dessen Bootverhalten, jedenfalls nicht über die dokumentierten Eingriffsmöglichkeiten hinaus. > Beim Raspberry PI wird der Broadcom Prozessor das erste Bit der > Speicherkarte aufrufen und dort den Bootloader starten; zumindest gehe > ich davon aus. Nö, das ist dann doch etwas komplizierter... Aber bis (auschließlich) RasPi4 läuft es darauf hinaus, dass da zwingend eine SD-Karte sein muss, oder jedenfalls irgendwas, was sich wie eine solche verhält. Beim RasPi4 wird die Sache komplizierter. Ist aber genausowenig brauchbar dokumentiert. Im Prinzip läuft es auch hier darauf hinaus, dass du die von der PasPi-Klitsche vorgegebenen Wege zum Booten benutzen musst. Nur dass es jetzt einen mehr gibt, und damit immerhin die Exklusivität der SD-Karte als Bootdevice beendet ist...
c-hater schrieb: > Aber bis (auschließlich) RasPi4 läuft es darauf hinaus, dass da zwingend > eine SD-Karte sein muss Nope. Auch der 3B+ konnte schon von USB und Netzwerk booten. Ohne SD-Karte.
Gustl B. schrieb: > Kai S. schrieb: >> SMD20 Chip > > Was ist das? Eine Beispielbezeichnung (ausgedacht) für einen Chip. In Windows weiß ich, dass er bei einem Device, welches er nicht kennt, in manchen Fällen, auch ohne Treiber, zumindest den Namen angibt (hatte ich schon); ich meine in Linux ist das mit lsdev möglich und dann kommt da der Text des Chips und den muss er ja vom device irgendwo ausgelesen haben, also muss der ja irgendwie im Register stehen oder von einem vorgeschalteten Chip bereitgestellt werden. Schonmal vielen Dank für die ausführlichen Infos; das trifft echt was ich wissen wollte!
Dergute W. schrieb: > USB-Sticks und -festplatten sind USB-Massstrorage devices. Also > Softwaremaessig werden die identisch angequakt. Und natuerlich brauchts > dann unter Linux den entsprechenden Treiber. Dem entnehme ich, dass das auch wieder ein Standard für die "Massstrorage devices" ist, der irgendwo von der IEEE oder so etwas definiert wurde, richtig? MfG
Kai S. schrieb: > Dem entnehme ich, dass das auch wieder ein Standard für die > "Massstrorage devices" ist, der irgendwo von der IEEE oder so etwas > definiert wurde, richtig? Das ist ein Teil der USB-Spec. Da kenn ich mich nicht gut aus, aber ich vermute mal stark, dass das eng an die SCSI-Spec. angelehnt/uebernommen wurde. Und die wird auch nicht aus dem Nichts aufgetaucht sein... Gruss WK
Kai S. schrieb: > Ich frage mich jetzt, mit Bezug zu einem Raspberry PI, ob ich > (hypothetisch) wohl die SD-Karte durch einen Festspeicher ersetzen > könnte. sogar praktisch µSD Karte mit OS bespielen, swap ausschalten oder auf NAS USB umleiten, Karte an einer Stelle kaputtschreiben bis sie in den RO Mode geht, fertig ist der Festspeicher PI
Kai S. schrieb: > Wie kann über jegliche Schnittstelle festgestellt werden, welche > Kapazität der betreffende Speicherchip hat; darf ich das auch noch eben > fragen? Garnicht. Selbst wenn die Schnittstelle gleich ist gibt es zig verschiedene Arten von Speichern die alle unterschiedlich angesprochen werden sollen und daher auch ganz unterschiedliche Möglichkeiten haben. Das legt man normalerweise bei der Hardwareentwicklung schon fest was man da verbaut und weiss somit wie der verbaute Stein behandelt werden will. Kai S. schrieb: > Ist im Speicherchip ein Bereich für die Kennzeichnung, Größe, Art, etc. > definiert, der nicht überschrieben wird? Funktioniert das so? Bei SD-Karten gibt es sowas Teilweise: https://www.sdcard.org/downloads/pls/ SoC -> SPI-Schnittstelle -> SD-Karte -> SD-Kontroller -> Flash Und zu dem ganzen kommt noch das auf dem ganzen ja auch noch als logische Schicht ein Filesystem "obendrauf sitzt". Das muss deine Software ja auch noch alles berücksichtigen. https://de.wikipedia.org/wiki/File_Allocation_Table#exFAT Nur mal so als Beispiel für die im PC Bereich gängigen Schnittstellen für externen Speicher: https://de.wikipedia.org/wiki/Serial_ATA https://de.wikipedia.org/wiki/NVM_Express https://en.wikipedia.org/wiki/USB#USB_mass_storage_/_USB_drive Praktisch alle bestehen immer auch einem Hardwareteil und einen Softwareanteil. Selbst wenn die Hardwareschnittstelle ähnlich sein sollte kann die notwendige Softwarelogik total anders sein. Und oben auf die Softwareschicht zur Kommunikation kommt da dann noch eine Filesystem oben drauf das für die Organisation der Daten notwendig ist. Zum Booten benötigst du z.B. am Anfang erstmal einen Speicher der in den Adressbereich der CPU eingeblendet ist damit diese die darin enthaltenen Befehle überhaupt ausführen kann. Dieser Speicher kann als Flash oder gar ROM in den Chip integriert sein, es kann aber auch einen externen Flash oder ROM sein der speziell dafür ist. Eine SD-Karte z.B. kann das überhaupt nicht, da musst du den Datenblock erstmal in den RAM kopieren und erst von dort kann die CPU da überhaupt drauf zugreifen. In dem Programm muss dann alles enthalten sein damit das System die weiteren Schritte durchführen kann. Wenn da z.B. mir die Software drin ist um von einer SD-Karte mit einem exFAT Filesystem eine bestimmte Datei in den RAM zu laden und auszuführen hast du schon verloren, wenn die die SD-Karte anders Formatiert hast. Von ganz anderen Schnittstellen und/oder Chips die ganz anders Angesprochen werden müssen ganz zu schweigen. Mal ein Beispiel wo Speicher fest an einen µC via SPI angeschlossen wird so dass die CPU auch direkt drauf zugreifen kann: https://www.e4ds.com/webinar_tech_dn.asp?idx=178 https://www.mouser.de/datasheet/2/268/S71380-373265.pdf Das ist aber eine völlig andere Art von Speicher der mit einer SD-Karte so überhaupt nichts gemeinsam hat auch wenn beides im Prinzip aus Flash-Chips besteht- Dazwischen gibt es auch noch einige Arten die z.B. zwar wie SD-Karten eine SPI-Schnittstelle nutzen, aber von der Logik her dennoch völlig anders angesteuert werden müssen. https://www.mouser.de/datasheet/2/949/w25r128jv_revb_09032018-1499765.pdf
Vielen Dank für die übersichtliche, strukturierte und umfassende Antwort. Ist komplizierter als gedacht. Von der Idee her war es einfach: Datenverbindung herstellen, Dateisystem mit Partitionierungstabelle bereitstellen, Daten nach Vorgabe des Dateisystems im Speicher ablegen und auslesen, weiterleiten, fertig. Schade, dass es nicht so einfach ist. --------------- Jetzt suche ich noch ein Buch, z.B. von O'Reilley, über Dateisysteme, Speichermedien und deren Ansteuerung. Gibt es da ein wirklich gutes, allumfassendes, Grundlagen und Details vermittelndes Werk, dass jemandem bekannt ist und möglichst einfach in diese Thematik einführt und auch als Nachschlagewerk genutzt werden kann?
Moin, Kai S. schrieb: > Datenverbindung herstellen, Wie das gemacht wird, steht im Datenblatt des SoC. Gaengig: JTAG, RS232, USB (wenn das SoC schon auf einen Bootloader zurueckgreifen kann, ggf. auch Ethernet( z.b. tftp)). > Dateisystem mit Partitionierungstabelle > bereitstellen, Daten nach Vorgabe des Dateisystems im Speicher ablegen Ob du eine Partitionstabelle brauchst (nicht immer, das ist eher so ein PC Ding) oder nicht, steht im Datenblatt des SoC. Welches Dateisystem du hernimmst, haengt hauptsaechlich von deiner Software ab, die drauf zugreifen soll. Normalerweise machst du auf deinem Entwicklungs-PC ein Verzeichnis auf, innerhalb von dem kannst du deine ganzen Files und gedoens anlegen, so wie du's spaeter gerne auf deinem SoC sehen willst. Wenn du damit fertig bist, machst du daraus dann ein Image z.b. mit so tools wie mksquashfs oder mkyaffs. Dieses Image (und weiteres Zeugs, wie z.b. bootloader, etc. - genaueres dazu steht im Datenblatt deines SoC) schreibst du dann ueber deine "Datenverbindung" in deinen ominoesen Speicherchip. > und auslesen, weiterleiten, fertig. Nee. Und bootest dann aus deinem Speicherchip. Fertsch. > Schade, dass es nicht so einfach ist. Wenn man das Datenblatt gelesen und verstanden hat und das 1-2 mal gemacht hat, wird man sehen, dass es auch nicht soooo schwierig ist. Gutes Buch dazu kenn' ich keines. Ausser: Das Datenblatt deines SoC :-) Gruss WK
Kai S. schrieb: > Jetzt suche ich noch ein Buch, z.B. von O'Reilley, über Dateisysteme, > Speichermedien und deren Ansteuerung. Gibt es da ein wirklich gutes, > allumfassendes, Grundlagen und Details vermittelndes Werk, dass jemandem > bekannt ist und möglichst einfach in diese Thematik einführt und auch > als Nachschlagewerk genutzt werden kann? Nein, und nach sowas fragt jeder zweite Anfänger: Gibt es ein Buch GENAU für mein Problem, und ganz einfach. NEIN! Gibt es nicht. Denn du hast viele Probleme: - Dateisysteme: Es gibt viele Davon und es gibt recht umfassende Bücher über Dateisysteme. - SD-Karten Ansteuerung: Da gibt es Datenblätter und viel Beispielcode. Beides muss man aber auch erst mal verstehen. Dazu braucht man auch Vorwissen und Erfahrung z.B. über Bussysteme, SPI, Speicher, Bäume, Algorithmen usw. Fazit: Will man SD-Karten und Dateisysteme bis ins Detail verstehen und anwenden können muss man sich reinhängen. Verschiedene Quellen angucken, Code angucken, Datenblätter lesen, ausprobieren, selber coden. Wie bei allem: Erfahrung macht hier den Meister. Niemals irgendein magisches Buch.
:
Bearbeitet durch User
Kai S. schrieb: > Ich frage mich jetzt, mit Bezug zu einem Raspberry PI, ob ich > (hypothetisch) wohl die SD-Karte durch einen Festspeicher ersetzen > könnte. Wenn du jetzt mal all das hypothetische Geschwafel und dein hypothetisches Wissen über hypothetische Speicher beiseite lässt, die alle mit der Realität nichts zu tun haben. kommt man zur realen Frage: Was versprichst du dir davon? Oder kürzer: Warum? Oliver
Cyblord -. schrieb: > Nein, und nach sowas fragt jeder zweite Anfänger: Gibt es ein Buch GENAU > für mein Problem, und ganz einfach. > NEIN! Gibt es nicht. Ich wollte kein Buch genau für mein Problem, sondern ein gutes Buch über Dateisysteme. Ich denke, dass das eine angemessene Frage ist, nach einer Rezension? Was hast du denn daran auszusetzen? Durch Bücher liest man sich fundiertes Fachwissen an, wie du es weiter unten ja auch beschreibst. Da sind es deine Worte: Cyblord -. schrieb: > Will man SD-Karten und Dateisysteme bis ins Detail verstehen und > anwenden können muss man sich reinhängen. Verschiedene Quellen angucken, > Code angucken, Datenblätter lesen, ausprobieren, selber coden. Tut mir leid, verstehe die Aufregung nicht. MfG
Oliver S. schrieb: > Wenn du jetzt mal all das hypothetische Geschwafel und dein > hypothetisches Wissen über hypothetische Speicher beiseite lässt, die > alle mit der Realität nichts zu tun haben. kommt man zur realen Frage: > > Was versprichst du dir davon? Oder kürzer: Warum? > > Oliver Geschwafel ist unhöflich, beantworte ich nicht. Mit all den anderen Antworten bin ich sehr zufrieden, sie haben das, was ich wissen wollte, umfangreich, detailliert und gut bis sehr gut beantwortet. Vielen Dank nochmal! MfG
Moin, Kai S. schrieb: > Ich wollte kein Buch genau für mein Problem, sondern ein gutes Buch über > Dateisysteme. Um ein SoC zu booten braucht's dieses Wissen ueber Filesysteme ueberhaupt nicht. Da nimmt man erstmal das, was der Hersteller vorschlaegt. Aber wenn's so grundsaetzlich interessiert, wie das so mit Filesystemen ist, wuerd' ich mal Dokumentation vom Linux VFS und von Fuse (Filesystem in User Space) vorschlagen. Und dann halt noch von der jeweils persoenlich interessanten Filesystemgeschmacksrichtung. Gruss WK
Kai S. schrieb: > Nehmen wir zum Beispiel einen ATMEL AT27C010, was laut meiner Sicht ein > "reiner" Speicher, ohne feste Register ist. > Wenn ich den jetzt in Raspbian auf meinem Raspberry PI als /dev/sda > einbinden möchte, mit einem Dateisystem versehen und formatieren möchte, > was muss ich dann noch gemacht haben (vorgeschaltet haben), damit das > funktioniert? Einbinden als /dev setzt voraus, daß ja bereits ein Linux gebootet wurde, d.h. Dein OS läuft und muß entsprechende Treiber geladen haben, um das Filesystem auf dem Chip anzusprechen. Der AT27Cxx ist ein EPROM, d.h. kann nur mit einem Programmiergerät beschrieben werden (VPP = 12V), muß also read only gemounted werden. Das OS muß nur wissen, an welcher Adresse der EPROM gemappt ist und dort die Datenträgerinformationen lesen (Partitionstabelle). Findet das OS ein ihm bekanntes Filesystem vor, kann es das mounten. Ist der EPROM leer (0xFF), kann das OS damit nichts anfangen, also auch nicht dessen Größe erkennen oder ob da überhaupt was angeschlossen ist. Das Booten eines OS ist ein mehrstufiger Prozeß. Nach dem Power-On sprint die CPU an den Resetvektor, wo sich ein Festspeicher befinden muß und führt dessen Code direkt aus. Dieser kann dann Treiber beinhalten, um z.B. ein OS in den RAM zu laden und zu starten (auszuführen).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.