Flashen MTD root device

[NS_5]

Beste tweakers,

Ik had een tijd geleden al een vraag over het booten vanuit een Redbootomgeving. Inmiddels draait er een mooi rootsysteem met een UnionFS (deels NFS (root), deels flash). Het bordje start vanaf een deftige 16 core server waarop chromium e.d. draaien. Deze gebruikt de X-display van het bordje en zo wordt de touch-input van het touchscreen naar de server gestuurd en het door de server snel gerenderde beeld weer terug. Nu het volgende:

Deze opzet werkt nu op één scherm. De bedoeling is dit kunstje te herhalen op nog 27 schermen met exact dezelfde functie. Daarvoor moet de Redbootconfiguratie uiteraard aangepast worden en tot nu deed ik dit met een USB naar RS232. Maar dat zou in ons geval betekenen dat ik 27 schermpjes moet losschroeven. Vanzelfsprekend zou dat ook via SSH moeten kunnen, maar dat blijkt lastiger dan gedacht.

De Redbootpartities zijn in linux zichtbaar in /dev/mtd/[0..6]. Deze worden beschikbaar gemaakt door de kernel tijdens het opstarten en zijn niet zichtbaar in /proc/mounts. So far zo goed nog steeds. Ware het niet voor het feit dat de partitie met de Redbootconfiguratie maar 4k groot is. Dit is kleiner dat een erase block en dus geforceerd read-only.

De vraag daarom: wat doe ik hieraan? Kan ik de partitie forceren toch writeable te zijn? Kan ik de 16MB NOR "root device?" als geheel flashen? Wat is wijsheid?

[Thralas]

NS_5 schreef op maandag 05 januari 2015 @ 13:46:
Kan ik de partitie forceren toch writeable te zijn?

Lijkt me niet, om de reden die je zelf geeft. Wat zou er moeten gebeuren met data die na de partitie valt, maar binnen hetzelfde eraseblock?

Kan ik de 16MB NOR "root device?" als geheel flashen?

Welke 16 MB NOR? Is dat *alle* flash memory?

Wat is wijsheid?

Volgens mij hebben we zo geen duidelijk beeld van de flash layout. Was handiger geweest als je /proc/mtd even annotated had gepost..

Maar als je de partitie zelf niet kunt beschrijven dan lijkt de logische uitweg gewoon met de hele device te werken, een veelvoud van de blocksize te lezen, je config aan te passen en de boel terug te schrijven. Problem solved?

[NS_5]

Wat zou er moeten gebeuren met data die na de partitie valt, maar binnen hetzelfde eraseblock?

Nou in principe kan je dat gewoon eerst inlezen, het blok wissen, de data veranderen en terugschrijven. Eigenlijk zoals jij beschrijft voor het hele geheugen. Maar blijkbaar is dat niet mogelijk of wordt dat om een andere reden niet gedaan. Misschien gewoon om het geheugen tegen write wearing te beschermen? I don't know.

Welke 16 MB NOR? Is dat *alle* flash memory?

Ik zal mijn flash layout zo even posten, maar ja, de 16MB is inderdaad de gehele chip dit ik tot mijn beschikking heb. Daar stond de kernel + het rootsysteem op. Het apparaat is al wat jaartjes ouder namelijk.

Maar daarover gesproken, wat is het "root" device? Of beter gezegd: waar? Ik zie alleen de partities, niet de schijf zelf, zoals /dev/sda, etc.

[Mijzelf]

Wat heeft dat mtdblock met je probleem te maken? Waarom moet je in de redboot configuratie om touch data over ssh te versturen?

[NS_5]

Mijzelf schreef op dinsdag 06 januari 2015 @ 13:09:
Wat heeft dat mtdblock met je probleem te maken? Waarom moet je in de redboot configuratie om touch data over ssh te versturen?

Met mtdblock bedoel ik de block device mapping naar de partitie die in Redboot is geconfigureerd. Het 'probleem' daarmee is dat die partities rare groottes hebben en ze middenin erase blocks vallen, en daardoor read-only zijn bestempeld door de kernel. Het geheugen als geheel is echter niet zichtbaar. Ik weet in ieder geval niet waar.

SSH heeft er op zich niet veel mee te maken. Behalve dat ik via ssh die configuratie wil aanpassen, ipv via een seriële verbinding, want dan zouden die 28 al opgehangen schermpjes weer van de muur en opengeschroefd moeten worden (om tot de seriele poort te komen).. Touch data was onderdeel van het inleidende verhaaltje, niet van de probleemstelling .

Overigens, ik bedenk me net dat het niet erg zou zijn als er data verloren gaat. Dus in het geval van een geforceerde writable. Zou daar toch een omweg naartoe zijn?

[ Voor 5% gewijzigd door NS_5 op 06-01-2015 13:34 ]

[NS_5]

Voor de volledigheid nog even de partities:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "RedBoot"
mtd1: 00200000 00020000 "kernel"
mtd2: 00e00000 00020000 "rootfs"
mtd3: 00020000 00020000 "nvram"
mtd4: 0001f000 00008000 "FIS directory"
mtd5: 00001000 00008000 "RedBoot config"
mtd6: 04000000 00004000 "mxc_nand"

En snippet van de kernel log bij het booten:

[    1.227622] physmap platform flash device: 04000000 at c0000000
[    1.246402] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x003000
[    1.271696] Amd/Fujitsu Extended Query Table at 0x0040
[    1.284803]   Amd/Fujitsu Extended Query version 1.4.
[    1.297701] physmap-flash.0: CFI contains unrecognised boot bank location (1). Assuming bottom.
[    1.314654] number of CFI chips: 1
[    1.326345] Searching for RedBoot partition table in physmap-flash.0 at offset 0x1fe0000
[    1.387594] 6 RedBoot partitions found on MTD device physmap-flash.0
[    1.402415] Creating 6 MTD partitions on "physmap-flash.0":
[    1.416338] 0x000000000000-0x000000040000 : "RedBoot"
[    1.434658] 0x000000040000-0x000000240000 : "kernel"
[    1.454344] 0x000000240000-0x000001040000 : "rootfs"
[    1.473937] 0x000001fc0000-0x000001fe0000 : "nvram"
[    1.493247] 0x000001fe0000-0x000001fff000 : "FIS directory"
[    1.508342] mtd: partition "FIS directory" doesn't end on an erase block -- force read-only
[    1.530743] 0x000001fff000-0x000002000000 : "RedBoot config"
[    1.546374] mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only

[Mijzelf]

Ik ben wel eens ergens tegengekomen dat je ook kunt schrijven naar /proc/mtd, en daarmee de partitietabel aanpassen. Ik heb even gegoogled, maar kan de syntax niet vinden. Misschien even in de kernelsource kijken?

[NS_5]

Hmm, dat lukt niet zo 1-2-3. Het zou kunnen als ik read-onlybeveiliging uit de kernel sloop. Maar dat is nou niet echt elegant. En er ontstaat weer hetzelfde kip-eiprobleem als eerst: dan moet ik alsnog eerst aan de bordjes komen en ze naar de andere kernel wijzen. Dan kan ik het zo goed gelijk mijn eigen kernel flashen.

De kernel geeft wel aan dat het 't physmap-flash.0 device gebruikt. Maar dat is virtueel: een memory mapped geheugen. Kan ik daar dan niet naar schrijven?

[Thralas]

NS_5 schreef op vrijdag 09 januari 2015 @ 15:05:
Hmm, dat lukt niet zo 1-2-3. Het zou kunnen als ik read-onlybeveiliging uit de kernel sloop. Maar dat is nou niet echt elegant. En er ontstaat weer hetzelfde kip-eiprobleem als eerst: dan moet ik alsnog eerst aan de bordjes komen en ze naar de andere kernel wijzen. Dan kan ik het zo goed gelijk mijn eigen kernel flashen.

/proc/mtd is niet writable, dus dat klopt.

Verder had ik eerder een interessante thread gezien, was hem even kwijt, maar ik heb hem weer gevonden.

Dat lijkt me momenteel de netste oplossing. Kernel module inschieten die de partition map herschrijft. Ik zou alleen niet zomaar simpelweg de write mask weghalen zonder uit te zoeken wat er vervolgens met writes gebeurt die over de partition boundary vallen.

Waarschijnlijk is het dan handiger om mtd4 te deleten/resizen zodat je ruimte hebt om je configpartitie te alignen.

Wat me verder opvalt is dat de erasesize van alle partities verschilt. Hoewel ik niet bekend ben met NOR flash lijkt me dat niet helemaal juist? Neem aan dat er of 1 eraseblock size is, of geen. Misschien is het slim om even de datasheet/specs van het flash in kwestie op te zoeken, zou goed kunnen zijn dat alles stiekem toch aligned is met de juiste erasesize, hoef je alleen dat en die writemask te fixen in je module..

EDIT: Volgens de Linux source bevat de FIS directory partition info, is deze 1 erase block groot, en zit de config area van Redboot er soms bij in (check). En variable eraseblock sizes is ook een ding, blijkbaar, TIL.

De kernel geeft wel aan dat het 't physmap-flash.0 device gebruikt. Maar dat is virtueel: een memory mapped geheugen. Kan ik daar dan niet naar schrijven?

Volgens mij niet. Hij is wel mapped voor reads, maar writes moeten per block, dat gaat niet als het device 1:1 mapped zou zijn voor writes.

[ Voor 10% gewijzigd door Thralas op 09-01-2015 16:28 ]