ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | http://irclog.whitequark.org/linux-rockchip
naobsd has quit [Quit: Page closed]
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 248 seconds]
mmind00 has joined #linux-rockchip
Astralix has joined #linux-rockchip
<Astralix> good morning
<mmind00> monring Astralix
<Astralix> Ups, there is soeone active.
naobsd has joined #linux-rockchip
Astralix has quit [Quit: Leaving.]
Astralix has joined #linux-rockchip
<Astralix1> little bit silent in here
<mmind00> :-)
<Astralix1> Uh, hi!
<Astralix1> I am a bit.... crew-chat, omegamoon hangout, linux chat... IDA session and some kernel compiling...
<Astralix1> At least, have a new soundcard and musik rocks!
<mmind00> hehe ... music as life essence
<Astralix1> yes without it gets hektic. A good baseline gets everything in line
<Astralix1> For evening we take this http://www.youtube.com/watch?v=cOv6L9FLU6w
<mmind00> interesting :-)
<Astralix1> Yes, sort of medium speed for tonight... Need to take a rest. Last two weeks I read assembler the whole night
<Astralix1> Had no sound on my machine for a while. Onboard sound was to niosy... no fun. But got an opened Creative X-Fi USB box in a market. Works fine with a sennheiser
mmind00 has quit [Ping timeout: 246 seconds]
mmind00 has joined #linux-rockchip
<Astralix1> anyone still in?
Astralix has quit [Quit: Leaving.]
<mmind00> yep
<Astralix1> du kannst auch nicht schlafen?
<mmind00> will nur noch die v2 der smp unterstützung auf den weg bringen
<Astralix1> Wer spricht denn hier eigentlich kein deutsch?
<Astralix1> leowt, denke ich , ist bislang der einzige
<mmind00> naobsd ... hab jetzt keine Ahnung wer sich dahinter verbirgt :-)
<Astralix1> Aber du bist der maintainer
<Astralix1> also der der an dem künftigen chaos schuld ist...
<mmind00> künftiges Chaos? Achso irgendwie funktionierender Rockchip Code vs. nur Grundlagen mainline code ;-)
<Astralix1> was hast Du denn jetzt wirklich vor?
<mmind00> keine Ahnung, wirklich ... das ist einfach nur mein erkundungsdrang
<Astralix1> Du willst den chinesen die Arbeit abnehmen ordentlichen Code schreiben zu müssen
<mmind00> für meine Freitzeitsachen mag ich diese "unbeschriebenen Blätter", da ich da einfach wie ich zeithabe weiterbasteln kann
<mmind00> bisher hab ich an einem Thalia Oyo rumgehackt (Samsung S3C2416) und wollte jetzt auch mal was anderes sehen ;-)
<Astralix1> Ich bin da schon seid 1.5 Jahren drin und es wird nur geringfügig besser, was die produzieren
JochenKauz has joined #linux-rockchip
<Astralix1> Hallo Jochen
<JochenKauz> 'Abend in die Runde
<Astralix1> Normal ist englisch, aber wir sind gerade unter uns
<mmind00> ah, jetzt wo wir auf Deutsch umgeschaltet haben, kommen alle vorbei ;-)
<Astralix1> Nee, hab ihn rüber gezogen
<JochenKauz> lol... okay... lets switch to english, no prob
<mmind00> achso
<Astralix1> war mir zu doof in zwei chatfenster mit nur zwei leuten zu chatten
<Astralix1> Gibt es irgendwo werbung für diesen Channel?
<mmind00> ich glaub nicht ... nur der leo hat scheinbar alle möglichen Leute eingeladen
<JochenKauz> na dann switch back zu Deutsch
<Astralix1> lol, ok
<Astralix1> Wie läuft das denn jetzt?
<Astralix1> Du hast in kernel.org einen Zweig auf gemacht und willst da RK rein füttern
<Astralix1> Aber Du hast mir auch was in github zugeschustert
<Astralix1> ich bin jetzt überfordert... Erklär mal wie es ablaufen soll...
<mmind00> github war vorher :-)
<mmind00> das kernel.org repo ist hauptsächlich dafür da, dass die arm-soc-Leute pullen können
<JochenKauz> aha
<mmind00> nach dem 3.11-rc1 will ich da auch einen "devel" Zweig ablegen
<Astralix1> Also entwickeln wir im github und einer schunst dann nach kernel.org, die nehmen dass dann auf, oder rejecten es
<mmind00> momentan bekomm ich die ganzen Patches die dafür notwendig sind nicht mehr zusammen, weswegen ich einfach mal auf 3.11-rc1 warte :-)
<mmind00> ne
<mmind00> die Entwicklung erfolgt immer mehr oder weniger einzeln ...
<mmind00> es muss immer als Review über die Mailingliste
<Astralix1> auch wenn ein neues SOC aufgenommen wird? Das ist ja schon ein Hammer, der dann da drüber muss
<Astralix1> Also nur mal mach-rk29, mach-rk30 und mach-rk31 und dazu dann noch plat-rk
<mmind00> jap ... die review geschichte muss sein
<Astralix1> ist schon klar
<mmind00> ne, auch nur mach-rockchip
<Astralix1> oh, sportlich....
<Astralix1> plat ist outdated, oder?
<mmind00> das ganze Rockchip-Gerümpel geht halt gar nicht
<Astralix1> Da hast Du sowas von recht!"
<mmind00> richtig und auch devicetree-only
<Astralix1> oftree? Ich bin sowas von dafür!
<JochenKauz> wie lange seit ihr noch da? Wollte mich jetzt auf mein Hotelzimmer begeben...
<Astralix1> Jochen, wir schreiben ab morgen einfach alles neu, machste mit?
<Astralix1> Ich muss dringend ins Bett
<mmind00> hihi
<JochenKauz> gerne.. aber bitte vernünftig
<Astralix1> Hier musste aufpassen, da läuft ein logger mit und jeder kann es lesen :)
<JochenKauz> okay... eventuell noch bis gleich...
JochenKauz has quit [Read error: Connection reset by peer]
<mmind00> d.h. eben auch mit den devicetree im rücken, darf der Code-Teil auch überhaupt nicht mehr ausufern
<Astralix1> Wir werden halt sehr sorgfältig prüfen müssen, welche Sourcen und Einstellungen wir auf offiziellem Wege erhalten haben, und welche nicht... Das ist nicht immer so einfach
<Astralix1> Ich habe manches mal schwere Geschütze aufgefahren um hinter gewisse Dinge zu kommen.
<mmind00> ich arbeite momentan nur mit den quellen die regular per Source-Release verfügbar sind
<Astralix1> Aber viel Code ist inzwischen auch durch dusselige Patzer der Chinesen selbst online gegangen.
<mmind00> und die dienen dann auch nur dazu, herauszufinden, was da überhaupt abläuft
<Astralix1> Ja, die Patzer gehören da aber nur teilweise rein... HDMI Schlüssel wollen wir ja nicht verteilen, oder?
<Astralix1> Hast Du eine Hardware auf der Du das testen kannst?
<mmind00> jap ein rk3066a tablet aus der Firma :-)
<Astralix1> woran erkennt man a oder b?
<mmind00> tablets eigentlich nur a ... der b hat weniger pins, keine pull steuerung
<Astralix1> Vom Code her würde ich sagen, das waren Chinese a und Chinese b und beide haben versucht den 3066 in den kernel bringen. Chinese a hat verloren, weswegen sein Code irgendwann versumpft
<mmind00> ne, die SoCs sind auch wirklich unterschiedliche Hardware
<Astralix1> denn der 3066b hat viel mehr unterstützung
<mmind00> dein Datenblat z.B. ist eigentlich ein 3066a auch wenn es so nicht direkt da steht (vermutlich weil der b später kam)
<Astralix1> Na das hat nix zu sagen... Mein erstes 2918 Tablet hat auch einen Treiber von einem Texas Instruments TPSirgendwas Battery-Manager geladen
JochenKauz has joined #linux-rockchip
<Astralix1> der Chip hat die Prototyp Bemusterung von TI nicht überstanden
<Astralix1> Und im Tablet war überhaupt kein BatteryManager Chip verbaut
<JochenKauz> So... nun auf dem Hotelzimmer..
<Astralix1> es war nicht einmal einer vorgesehen
<mmind00> dass die da amateurhaft irgendwelche alten sachen laden ist aber normal ... hier gehts mehr um die SoC interna
<mmind00> der 3066b hat z.B. die pin-Bänke 4 und 6 überhaupt nicht
<Astralix1> Ist schon klar, nur nie die Vorsicht vergessen, Daten zu hinterfragen
<Astralix1> #if defined(CONFIG_ARCH_RK3066B) || defined(CONFIG_ARCH_RK3188)
<Astralix1> #define GPIO_BANKS4
<Astralix1> #define GPIO_BANKS7
<Astralix1> #endif
<Astralix1> #else
<mmind00> :-)
<Astralix1> Jaja, kenne ich
<Astralix1> Ich habe gerade den Tronsmart MK908 kernel im disassembler um die Belegung der GPIOs haeraus zu finden
<Astralix1> Aber nun blinkt die LED im Heartbeat :)
<Astralix1> Tablet ist immer kompliziert, weil man auch die ganzen Rahmendaten haben muss, also LCD Panel und Touch und so weiter.
<Astralix1> Hast Du die passenden Kernel-Quellen?
<mmind00> für bq produkte ja
<Astralix1> der kernel ist auch reproduzierbar, also wenn ich den mit der config compiliere, dann bootet der auch bei Dir?
<mmind00> die Frage ist nur wie weit ... d.h. hardwaretechnisch unterscheiden die sich schon etwas
<Astralix1> Das ist es ja
<Astralix1> D.h. der Code stimmt mit der Hardware auch nicht so ganz überein?
<mmind00> naja, code 1 passt zu hw 1 und code 2 zu hw2 ...
<Astralix1> also versteh mich nicht falsch. Wenn ich deinen kernel für dein tablet, also mit der mitgelieferte korrekten .config oder *_defconfig kompiliere, dann passt der?
<Astralix1> Äh?
<Astralix1> wat jetzt?
<mmind00> richtig
<Astralix1> Also eigentlich sollte doch nur ein kernel aber mehrere _defconfig geben
<mmind00> ja eigentlich, aber auch die Upstream-Entwickler hacken dann da immernoch drin herum
<JochenKauz> Darf ich kurz mal einhaken?
<mmind00> um es an spezifische hardware anzupassen
<mmind00> ja klar :-)
<Astralix1> bq entwickelt da aktiv mit am kernel oder bekommt ihr auch nur einen zufälligen snapshot von irgendeiner chinesischen festplatte gezogen
<JochenKauz> Du sagst Du hast einen vollständige Kernelsource, die mit passender config defakto auf jedem Tablet funzen sollte?
<mmind00> ein bisschen von beidem ... und mehr werd ich dazu mal lieber nicht sagen
<mmind00> ne, wenn du z.B. den Kernel vom bq Curie nimmst (http://www.bqreaders.com/descargas-curie.html), dann sollte der auf einem Curie Tablet laufen
<mmind00> mehr aber eben leider auch nicht
<Astralix1> Das ist ja klar
<Astralix1> soweit ist das ja quasi auch in ordnung
<JochenKauz> ahso, denn ich haben nun schon viele Sourcen gesehen, aber da war oftmals dann doch im entschiedenden Bereich dann eine Lücke
<Astralix1> Die Lücke ist aber weniger im Kernel
<JochenKauz> wie man es nimmt
<Astralix1> Also mmind00, oft genug sind auch schon sourcen aufgetaucht, die meines erachtens nach künstlich verstümmelt worden sind, oder für ein völlig anderes Ding waren
<Astralix1> Außerdem ist es immer wieder beliebt, den nötigen Touchscreen Treiber entweder durch eine alte variante zu ersetzen, das uC Image nicht dabei zu tun, oder ein falsches, oder einfach 5 verschiedene sourcen für den gleichen chip über den device/ ordner zu verteilen
<JochenKauz> ja, mit Treibern die sich als was anderes ausgeben, oder vollkommen veralteten, die nicht übertragbar sind
<Astralix1> Und die LCD Einstellungen fehlen natürlich gerne
<Astralix1> Aber was aktuell bauchschmerzen macht, sind die Android Libs, die den kernel an das Android binden.
<JochenKauz> eigentlich sollten wir mal funzende Treiberkombis zusammentragen
<Astralix1> Ab 4.2.2 sollte man ja den kernel im android kompilieren.
<Astralix1> Und noch eine Baustelle:
<Astralix1> kernel mit SMP geht nur mit gcc 4.4.3 bis max. 4.5.3
<JochenKauz> womit wir dann wieder bei diesem 3.6er experimental gcc wären
<Astralix1> google baut den kernel mit 4.4.3
<Astralix1> den rest mit 4.6.x
<JochenKauz> Oma sagte doch jetzt hätte er einen Kernel mit 4.6er gcc bekommen
<Astralix1> andere haben aber auf den Multicores schon 4.9.x laufen mit SIMD und die kompilieren sogar Android mit 4.9.x und NEON/SIMD
<JochenKauz> und das war eine Toolchain die ich schon desöfteren gesehen habe
<Astralix1> nur RK bekommt es nicht hin
<Astralix1> da fehlen die Anpassungen im kernel
<naobsd> Grüß Gott
<Astralix1> ja schon ,aber wo sind die Quellen. ich habe ja schon einige Sachen gefunden... Aber scheinbar noch nicht alles
<mmind00> achso, du meinst im 3.0.36 rockchip kernel
<Astralix1> moinsen
<JochenKauz> Guten Abend
<Astralix1> Ja
<mmind00> tach
<naobsd> looks like cryptic
<Astralix1> Jochen -> Uhr!
<Astralix1> Wir haben mal in deutsch weiter gemacht, weil sonst niemand da ist
<JochenKauz> lol..
<JochenKauz> okay... good morning
<Astralix1> mmind00: nein, auch der 3.0.8 stürzt ab, wenn mit gcc >= 4.6.3 compiliert wird
<mmind00> english again?
<naobsd> don't mind, I'll leave soon
<Astralix1> naobsd, from where you are?
<Astralix1> you told about time shift
<naobsd> Japan
<Astralix1> yess, that's what we call time-shift ;)
<Astralix1> so, just talking about the basics and how to start
<mmind00> Astralix1: same outdated kernel version .... I guess the issue got fixed in the mainline kernel somewhere between then and now
<Astralix1> there was a bug in 4.6.3 that caused an oops at the point any network driver started
<Astralix1> ok, I check that later this day
<mmind00> it of course calls generic code for the core bringup
<JochenKauz> looks interesting
<mmind00> my guess is just, that the issue with newer gcc's got fixed in kernel versions somewhere after the 3.0.36 rockchip uses
<Astralix1> Now that I have a stick, it is easy to test. You don't need to have an LDC set up correctly that hasn't a datasheet availbale
<JochenKauz> do we have a starting point for a kernel version >3.0.36?
<Astralix1> Important for now ist to implement the patch, but don't count up the version. As if you do, the rkXXnand.ko doesn't start anymore and you have no MTDs
<Astralix1> If anyone knows how to do it, I would prefer to get rid of RK nand driver.
<JochenKauz> Astra, you mentioned it in the past that the kernel for 3188 looks like a mixed up kernel
<JochenKauz> that would be best
<Astralix1> Yes, rk3188 is implemented fine, RK30 is just thrown inside
<Astralix1> and then they do cross-borrowing
<JochenKauz> and that it not a real 3.0.36
<JochenKauz> it is
<Astralix1> rk30 and rk31 have separate iomux.c and iomux.h and gpio.c but separate gpio.h and such
<Astralix1> so rk31 is stealing #include "../mach-rk30/include/mach/..."
<Astralix1> I am actually at decoding the bootloader... so if we decide to support a mainline NAND flash driver...
<Astralix1> But I need to figure out some things there. If someone ist fit in sort of flash fs related things...
<Astralix1> Ok, I try to hit the bed, before my head does same with the table...
<Astralix1> cu later this fresh born day
<mmind00> n8
<JochenKauz> ok... cu and gn8
<Astralix1> dito
<Astralix1> ;)
<JochenKauz> ok, I think it's time for me to go to bed also, it was a hard and long day... gn8 and cu the next days
JochenKauz has quit [Quit: Leaving.]
mmind00 has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]