Werkt PLi Flubber met deze kernel ?

[Gast]

Voor de PLi gurus, ik draai al sinds jaar en dag een Miniroot met in de Flash de oude vertouwde 'Hydra' image. Nu heb ik in de loop der tijd wel eens de kernel in mn host image aangepast, maar ik vroeg mij af of Flubber hier mee gaat werken. Ik wil namelijk toch wel overschakelen naar PLi aangezien ik de developers daarachter veel meer op prijs stel dan die bij Gemini omdat zij toch meer 'Open Source' minded zijn. Echter ik ik heb problemen met de laatste kernels in mn host-image zetten en bij de andere multiboot oplossingen zie ik allemaal 'reformat' etc. voorbij komen, en die weg wil ik gaarne even vermijden indien mogelijk.

 

De kernel die in mn host image draait is :

 

Code:

Linux dm7020 2.6.9 #1 Tue Aug 30 12:57:56 CEST 2005 ppc unknown

 

De head.ko komt van een Gemini versie ergens in de buurt van 25 April 2006.

[Gast]

Ik verwacht geen enkel probleem, maar om heel eerlijk te zijn zou ik je niet aanraden dergelijke multiboot oplossingen te gebruiken.

De laatste keer dat ik met miniroot experimenteerde, gooide hij telkens m'n secondstage bootloader weg.

En je gebruikt altijd in minder of meerdere mate zaken uit een ander image.

 

Wat ik hier zelf doe, en dat bevalt uitstekend, is een stabiele image in flash, en dan een experimentele ontwikkel image op een compactflash.

Als de compactflash aanwezig is, boot de PLi secondstage loader netjes van de CF, gebruikt dan niet alleen het rootfilesystem, maar ook de kernel.

En haal je de CF eruit, dan boot hij van flash.

Beide images zijn superstabiel, en gebruiken of merken niks van elkaar.

 

Voor dit doel hebben we de 2nd stage bootloader wat uitgebreid, zodat hij kernel cmdline argumenten kan parsen uit de zgn startscripts die in flash of CF staan.

 

En dat noem ik een echte multiboot oplossing, in tegenstelling tot die chroot methode die 'multiboot' oplossingen volgens mij nog steeds gebruiken.

 

Als er interesse is zouden we voor de 7020 best een CF versie van Flubber beschikbaar kunnen stellen, die standalone wil booten, onafhankelijk van wat er in de interne flash staan.

[Gast]

Tja, ik zoek al tijden een oplossing om 'echt' te multibooten, en eerlijk gezegd is dit de eerste keer dat ik hoor dat in PLi de secondstage loader (die was toch nog niet vrijgegeven ? <img src="/forums/images/graemlins/smile.gif" alt="" />) aangepast is zodat deze 'echt' van CF boot. Dit is erg interessant inderdaad en ik zal dit ook zeker uitproberen. Zelf heb ik zitten experimenteren met rdev en de mogelijkheid om op de CF een autorun te zetten (methode die voor flashen vanaf CF gebruikt wordt) echter zonder resultaat (hij bootte wel de kernel vanaf CF maar ik kreeg het rootfs niet vanaf de CF gemount).

 

Is er in PLi dan ook de mogelijkheid, als men toch de ssl heeft aangepast, om een 'lilo' achtige oplossing te maken om zo te kiezen welke partitie op cf/hdd/usb te booten ? Dit zou geweldig zijn.

 

Over het inrichten van de CF zoals jij aangeeft, is dat een kwestie van met 'nfi_extract' een image uitpakken en de root partitie naar CF kopieren? Of komt hier meer bij kijken? Zo'n standalone PLi versie (in tgz die je zo naar de CF kan kopieren) zou natuurlijk ideaal zijn.

 

Iig erg bedankt voor de info zover, dit is een echte eye-opener en bewijst mijn gevoelens dat het PLi team beter weet waar ze mee bezig zijn dan de andere image bakkers <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

 

<flames_over_andere_images_die_zgn_beter_zijn_hier>

</flames_over_andere_images_die_zgn_beter_zijn_hier>

[Gast]

Citaat:

Zelf heb ik zitten experimenteren met rdev en de mogelijkheid om op de CF een autorun te zetten (methode die voor flashen vanaf CF gebruikt wordt) echter zonder resultaat (hij bootte wel de kernel vanaf CF maar ik kreeg het rootfs niet vanaf de CF gemount).

De kernel booten gaat idd vanzelf al goed, als je een 'autorun.bat' file aanmaakt op de eerste (fat) partitie van je CF, met daarin '/cf/zImage', en zImage de naam van de kernel, in diezelfde partitie.
Het enige wat je dan nog mist, zijn de custom cmdline args om een ander rootfs te booten.

Zo ziet mijn CF er momenteel uit:
-4MB FAT partitie
-rest van de ruimte ext3 partitie

In die FAT partitie staat een zImage-2.6.9-r3, en een autorun.bat, met de volgende inhoud:

Code:

/cf/zImage-2.6.9-r3 console=ttyS0,115200 root=/dev/hdc2 rootfstype=ext3 rw

Het rootfs staat in de tweede partitie (hdc2), en die kan je inderdaad met nfi_extract zelf ook genereren.

Citaat:

Is er in PLi dan ook de mogelijkheid, als men toch de ssl heeft aangepast, om een 'lilo' achtige oplossing te maken om zo te kiezen welke partitie op cf/hdd/usb te booten ? Dit zou geweldig zijn.

De boot settings staan in de front eeprom, en we hebben nog geen tool kunnen maken om daar vanuit een draaiende image bij te kunnen. En dat is wel een vereiste, om een echte multi-boot oplossing te maken, waarbij je voor het resetten aangeeft welke image je na de reboot wilt starten.
De bootloader communiceert rechtstreeks met de frontprocessor op de bus, maar dat kan natuurlijk niet meer zodra de kernel draait. Dan zijn we aangewezen op de drivers, en die missen zo te zien een interface om bij de eeprom te kunnen.

Maar goed, voor mij persoonlijk is 1 image in flash en 1 in CF voorlopig al meer dan voldoende.

PS, het zou kunnen dat het parsen van cmdline args inmiddels ook al met de 'standaard' bootloader werkt, we hebben DMM namelijk wel op de hoogte gesteld van onze wijzigingen.
Maar als dat nog niet werkt, zal je eerst een PLi image moeten flashen, om een werkende bootloader in flash te krijgen.

Je zult overigens merken dat het 'boot' partitie in de interne flash nog wel gemount wordt als je van CF boot, en dat de splash screens die daar in staan, afgebeeld worden tijdens booten.
Als je dat wilt voorkomen, zou je wat init scripts moeten ombouwen in je CF rootfs.

[Gast]

Citaat:

Het enige wat je dan nog mist, zijn de custom cmdline args om een ander rootfs te booten.

Ik heb hier toen e.e.a. mee geexperimenteerd zonder succes. Misschien dat het nu, met de nieuwe DMM ssl's wel mogelijk is idd.

 

Citaat:

De boot settings staan in de front eeprom, en we hebben nog geen tool kunnen maken om daar vanuit een draaiende image bij te kunnen.

Ik had geen idee dat je zelf de kernel parameters zou kunnen specificeren. Een lilo oplossing is dan niet meer nodig aangezien je gewoon zelf, mocht je een ander image willen booten, je de autoexec.bat (iemand zou gestraft moeten worden voor deze naam!) kan aanpassen en zo je 'oude' image weer kan booten (deze staat immers op de CF en dat kan je op een andere machine aanpassen).

 

Ik zou namelijk gaan voor een configuratie als een 'host' image in flash, en dan 2 image partities op de CF waartussen je steeds wisselt bij nieuwe images en zo dus je info uit het 'oude' image kan kopieren. Daarnaast is mijn ervaring dat de box veel vlotter draait vanuit CF aangezien dat een uncompressed FS is en de CF sneller lijkt dan de interne flash.

 

Citaat:

Als je dat wilt voorkomen, zou je wat init scripts moeten ombouwen in je CF rootfs.

Dat is een minimaal probleem en is idd als rc script wel op te lossen.

 

Dank voor de heldere uitleg. Ik ga hier binnenkort gelijk mee aan de slag. Zover hulde aan het PLi team <img src="/forums/images/graemlins/wink.gif" alt="" />

[Gast]

Zat even te brainen gisteren, maar is het niet mogelijk om op mn huidige box alleen de ssl te updaten ? Hij is verder toch compatible met andere images ? En weet jij toevallig of de ssl als gz op de flash partitie wordt gezet of uitgepakt ?

[Gast]

Citaat:

Zat even te brainen gisteren, maar is het niet mogelijk om op mn huidige box alleen de ssl te updaten ? Hij is verder toch compatible met andere images ? En weet jij toevallig of de ssl als gz op de flash partitie wordt gezet of uitgepakt ?

Hij zit ge-gzipt in de nfi, en nfi is de enige mogelijkheid om iets te flashen vanuit de ssl zelf.
Volgens mij kan de 1st stage wel rechtstreeks de 2nd stage overschrijven, maar dat moet dan serieel gebeuren, en ik weet niet zeker of dit protocol beschreven is.

En je kunt hem niet op een vast flash adres zetten, het gaat hier om NAND flash, dus de exacte start positie (sector nummer) is afhankelijk van hoeveel bad sectors je hebt, en waar die zitten.

Eind vorig jaar is ook de boot partitie wat vergroot ten koste van de root partitie, dus als je alleen de ssl vervangt, zonder de boot+root partities ook te vervangen, heb je kans dat hij je huidige boot/root niet meer kan booten.

Dus de veiligste en eenvoudigste manier is een volledige nfi flashen.