923 replies to this topic

[WanWizard]

Als alles goed blijft werken zolang je maar uit die OSD wizard blijft, dan is er nog een beetje hoop voor een fatsoenlijke default setting.

[cobus]

Ik blijf er wel uit nu.

[Erik Slagter]

De enige oorzaak kan nu nog zijn: andere GCC waarmee de Linux kernel wordt gecompileerd. De drivers compileren wij niet zelf (kan niet, want die zijn closed source). Als de drivers (incorrecte) aannames doen over de ABI, dan kan een Linux kernel met een andere GCC gecompileerd inderdaad dit soort problemen geven. En ook dan kan het alleen in de drivers worden opgelost. Of je moet weer die stokoude GCC uit de kast halen, maar dat is wat lastig in combinatie met een huidige OE versie.

 

Tot zover lijkt het er dus op dat we OSD schaling zullen moeten uitzetten, want dat leidt tot crashes (al dan niet meteen of later). En dat betekent, als we die ook niet op "0" kunnen zetten, dat de gebruiker vastzit zit aan een overscan-schaling van 5%. Maar dan loopt het tenminste niet vast.

[cobus]

Maar is er dan geen mogelijkheid om de oude kernel met drivers terug te zetten al is het maar voor een test dan weet je of het de drivers zijn want nogmaals van wat ik begrepen heb hebben ze stokoude drivers geporteerd naar een nieuwere kernel versie.

[catastrofus]

Bij mij gaat het fout direct na het flashen, het enige wat ik gezegd heb tegen de UI is dat ik de autobackup wil restoren. Daarna is het afgelopen.

De 2de flash gaf hetzelfde resultaat. Ik heb nog geen werkende 6.0rc op een et10k gezien.

 

Ik denk dat de enige vraag nu nog is:

 

Gaat het bij iemand al fout direct na het opstarten van de box? Of heb je een werkende OSD totdat je een keer die overscan wizard opstart?

[littlesat]

Laatste optie die voor mij overblijft is de 'openATV' methode

 

open("/proc/stb/fb/dst_left", "w").write('%08x' % dst_left)

 

vervangen door

 

...

fb = open("/proc/stb/fb/dst_left", "w")

fb.write('%08x' % dst_left)

fb.close

....

 

Alleen zal dit alleen de kans dat het gebeurt misschien veranderen, doordat de timing iets afwijkt...

 

Ik ga voor feature van reposition OSD uit zetten.... en hopen dat er niet meer procs over de 'streef' gaan...

Edited by littlesat, 12 October 2017 - 16:37.

[WanWizard]

Allemaal al geprobeerd, ook

with open("/proc/stb/fb/dst_left", "w") as f:
    f.write('%08x' % dst_left)

en

with open("/proc/stb/fb/dst_left", "w") as f:
    f.write('%X' % dst_left)

maakt allemaal niets uit.

 

Ook de box opstarten zonder dat enigma start, en dan met "echo -e" er naar schrijven hangt op den duur de box op. Ben er nu al een uur of 6 mee bezig...

[littlesat]

Dan nu stoppen lijkt me!

Edited by littlesat, 12 October 2017 - 16:45.

[WanWizard]

Ik heb nog even OpenPLi 4-release geinstalleerd, en die lijkt het probleem niet te hebben. En ook die versie is met de nieuwere gcc gecompileerd.

 

Dus voorlopig verdenk ik de optimizer, in combinatie met drivers die assumpties doen die niet meer valide zijn, bv ten aanzien van memory alignment of zo.

[catastrofus]

Dat weet ik, want ik draai op beide et10k's die laatste final probleemloos.

 

Ik heb nog even OpenPLi 4-release geinstalleerd, en die lijkt het probleem niet te hebben. En ook die versie is met de nieuwere gcc gecompileerd.

 

Dus voorlopig verdenk ik de optimizer, in combinatie met drivers die assumpties doen die niet meer valide zijn, bv ten aanzien van memory alignment of zo.

[cobus]

Denk dat ik die er ook maar op zet als hij weer kuren heeft.

[Erik Slagter]

Ik zou met alle liefde oudere drivers weer activeren, waarmee dit probleem waarschijnlijk opgelost is (inclusief ook het volume-probleem). Dat is alleen complex, omdat die ook een oudere kernel vereisen.

[WanWizard]

Ik zou wel eens willen weten waar OE-A zijn drivers vandaan tovert. Die hebben sinds de laatste officiele BSP al twee keer een kernel upgrade + nieuwe drivers uitgevoerd, die ze van hun eigen download servers halen, in plaats van bij Xtrend.

 

Hebben die een alternatieve ingang, of gebeuren daar in de schemering andere zaken? We zullen Xtrend eens om opheldering moeten vragen denk ik.

[cobus]

Athoik weet het ook wel want doe hadden toen ook de nieuwere drivers en kernel in hun satdreamgr exeperimentel image zitten.

[WanWizard]

Die houdt voor zijn images zelf zijn BSP's bij, en heeft gewoon die van OE-A overgenomen. Die heeft ook geen idee waar OE-A zijn inside info haalt.

[littlesat]

Zeker maar eens vragen of 'Xtrend' de bsp layers eens update....

[Erik Slagter]

Dat zou uiteraard het beste zijn. Maar het is niet de eerste keer dat we die vraag neerleggen.

[catastrofus]

Dus een 6.0 release is voor ons een no-go?

[Erik Slagter]

Ja, we hebben net besloten geen et10k en et8k voor release-6.0 te bouwen. We gaan nu het eerst nog weer eens de leverancier voorleggen en ook waarom andere images nieuwere drivers hebben (waar het probleem kennelijk is opgelost) die niet in onze BSP zijn geplaatst. Dit is natuurlijk een zeer ongewenste situatie.

[catastrofus]

Dat is dan wel behoorlijk k*t. Flikker ik die 2 dm8k's (geïnstalleerd met PLi2 (en die werken probleemloos en zij is er blij mee)) eruit naar mijn ex om vervolgens et10k's te kopen om deze te vervangen kunnen deze geen PLi6 draaien.

Rest mij niets anders dan afwachten. Hoewel ik niet snap dat die PLi4-final wel goed draait op mijn et10k's terwijl deze image ook met gcc 5.4 is gecompileerd.

WW heeft het over de optimizer hoewel ik denk dat dit voor hem ook een 'best guess' is.

Edited by catastrofus, 13 October 2017 - 19:51.