<uvos>
Wizzup: nice :), but likey wont be able to recive it today.
<uvos>
parazyd: i got my 1st shot on wensday, its certly "fun" i feal like im 80 yo suddenly :P
<parazyd>
:D
<parazyd>
I got AZ, so doses are like 12 weeks separated
<parazyd>
In any case, tonight might be sleepytime
<uvos>
btw upgrade went fine on bionic
<uvos>
after you changed the kexecboot pkg
<mighty17[m]>
<uvos "dont add that kind of crap to om"> okay 😅
<uvos>
mighty17[m]: just add the absolue minimum config flags you really need
<mighty17[m]>
<uvos "mighty17: please dont send files"> so pastebin?
<uvos>
mighty17[m]: yeah or an email is even better
<mighty17[m]>
<uvos "mighty17: just add the absolue m"> i will need brcm for wifi
<uvos>
mighty17[m]: sure thats fine
<mighty17[m]>
and other config is for display and acclerometer
<uvos>
sure all of that is fine
<uvos>
just add the modules with =m
<mighty17[m]>
`User is blocking messages from unregistered users, and you are not registered.` :(
<uvos>
mighty17[m]: yeah you have to resigter with libera
<parazyd>
uvos: ok @ update; then I'll promote to main soon
<uvos>
if you can read my message its fine
<mighty17[m]>
<uvos "just add the modules with =m"> i have tried to use as much modules as possible
<uvos>
and stuf like CONFIG_BRCM_TRACING
<uvos>
only add that if you really really need it for the device
<uvos>
like CONFIG_BRCMDBG
Twiggy3 has quit [Quit: Leaving]
<uvos>
drop that pls
<mighty17[m]>
well yes, the dbg arent that necessasy
<mighty17[m]>
necessary*
<uvos>
right
<uvos>
i want the patch to just include what is nessecary for functionality
<uvos>
nothing else
<uvos>
that means just the modules themselves most likely
<mighty17[m]>
even b43leagcy should be dropped but im kins skeptical about taht
<mighty17[m]>
that*
<uvos>
if it doesent probe on your device or is coverd by another better driver please drop
<mighty17[m]>
<uvos "if it doesent probe on your devi"> device uses brcmfmac driver
<uvos>
then drop bt43
<uvos>
just the essentials please, i mean it ;)
<mighty17[m]>
also i needed to ask, the linux-firmware-brcm doesnt seem to have proper driver for bcm4330, so is it fine if i use downstream nvram and driver
<uvos>
by driver you mean firmware i assume
<uvos>
yeah thats fine
<mighty17[m]>
<uvos "just the essentials please, i me"> well there's no other way than i will have to test it myself, removing stuff gradually
<uvos>
mighty17[m]: sure just check what is loaded
<freemangordon>
Wizzup: the only remaining issue I am aware of is this endless blinking icon when you try to connect to non-existing hidden AP
<freemangordon>
but that shall be fixed in icd plugin IIUC
<Wizzup>
ok
<Wizzup>
yes
<tmlind>
uvos: gpmc on droid4 keeping device busy?
<tmlind>
uvos: also just found my mz609, i guess i'll try installing bootloader to it now
<freemangordon>
Wizzup: hmm, now it seems to always behave correctly
<freemangordon>
oh, wait
<freemangordon>
yeah, my bad, I was entering correct hidden AP SSID so it was rejecting the assoc
<freemangordon>
if you enter wrong one, it never stops blinking neither it gives error message
<tmlind>
uvos: yup i did fastboot flash cache boot.img, booted android and as root wrote utags-mz609-32-mmcblk1p6-boots-mmcblk1p18-kexecboot.bin to /dev/block/mmcblk1p6 with dd and mz609 booted to kexecboot just fine :)
<tmlind>
hmm i guess i need to build and upload proper droid4-kexecboot images at some point now
<tmlind>
uvos: i'll wait with the images until you've confirmed xt875 boots ok and maybe let's remove boot.cfg for xt875 on first boot if you have such a patch
<Wizzup>
freemangordon: I will try to fix that soon
<Wizzup>
freemangordon: I also want to make sure the dialog isn't grey when it shouldn't be
<Wizzup>
I felt it was sorted before, but with the different scan method it changed maybe?
<freemangordon>
no idea, I have dummy nets here so never gray
<freemangordon>
*grey
inky_ has joined #maemo-leste
<uvos>
tmlind: ok ill try and build kexecboot today
<uvos>
i dont have time to make a patch atm
<uvos>
tmlind: yes gpmc keeps it awake
_inky has quit [Ping timeout: 272 seconds]
<parazyd>
uvos: Let's think about how we could ship kexecboot as .deb
<parazyd>
For updates
<uvos>
parazyd: easy just package the image and dd it over on postins
<uvos>
its perfectly safe worst case the user has to fastboot flash it again if we crash during update
<tmlind>
uvos: ok well probably best you make your own then, that way you can patch away that xt875 default boot.cfg file :p
<uvos>
but you can just paste the patch after your email message
<mighty17[m]>
alrighty thanks
<uvos>
mighty17[m]: you can use git format-patch to write the email for you btw
<mighty17[m]>
<uvos "mighty17: you can use git format"> oh thats better i'll look into that (ps already sent email)
<uvos>
mighty17[m]: still needs a proper [subject] line and maybe a bit more of a long form description than just Adding support for Samsung Galaxy Tab 2 (7 inch)
<uvos>
should be something like for instance [PATCH] ARM: dts: <whatever dts file>: add this stuff
<uvos>
also cc tm
<uvos>
tmlind:
<uvos>
also mighty17[m] you cant use gmail
<uvos>
its breaking the patch by formating it
<tmlind>
mighty17[m]: do you have a tc358765 lcd bridge also on espresso?
<tmlind>
hmm maybe it's there only on tablets
<tmlind>
anyways, need to go pick up my wife, ttyl
<uvos>
Wizzup: i did manage to get your pacakge
<uvos>
Wizzup: its in bad shape
<uvos>
Wizzup: did you forget to add a hw4x battery or did it fall out? (package has a big hole)
<uvos>
otherwiese the xyboard and the d4 seam to have made it in one piece
<mighty17[m]>
<tmlind "mighty17: do you have a tc358765"> hm? the lvds bridge is doestek dtc34lm85am
<mighty17[m]>
<uvos "also mighty17 you cant use gmail"> ohk, git format-patch is the way
<mighty17[m]>
<uvos "mighty17: still needs a proper ["> we arent mainlining it yet are we?
<uvos>
mighty17[m]: i dont see why not maybe add just [RFC PATCH] to signify to the ml that your not intending to mainline rn
<mighty17[m]>
i cant edit it now 😅
<uvos>
mighty17[m]: otherwise if you fix the formating and the other nitpicks i dont see why we should not try and mainline immidatly
<uvos>
also the dts goes and defconfig changes go to linux-omap
<uvos>
but the code changes to the input driver go nowhere since they are in kernel allready
<uvos>
just send that to me privately
uvos has quit [Quit: Konversation terminated!]
<mighty17[m]>
uvos: reason is, i dont think its mainline ready, the pixel clock is half of whats in downstream (basically its wrong) and so is the pwm in backlight node, mmc is bugged (sometimes its mmc0 and 1 then 1 and 2 its random in dmesg), usb is broken, need to send a twl6032 patch as well
<mighty17[m]>
and he left the room wut?
inky_ has quit [Remote host closed the connection]
_inky has joined #maemo-leste
Twig has joined #maemo-leste
_inky has quit [Remote host closed the connection]
<sicelo>
mighty17[m]: we have logs ;-)
<Wizzup>
uvos: hrm
<Wizzup>
uvos: battery for what?
Daanct12 has joined #maemo-leste
Daanct12 has joined #maemo-leste
<Wizzup>
uvos: I did not provide a battery with the d4, the tablet should work as-is
inky_pbp has joined #maemo-leste
uvos__ has joined #maemo-leste
uvos__ is now known as uvos
Danct12 has quit [Ping timeout: 245 seconds]
<uvos>
Wizzup: we had discussed a non extended battery, because i wanted to test the cpcap changes with that
<uvos>
wrt autodetection of the battery type
<uvos>
but its ok its not so important
<uvos>
the xyboard is missing the screws in the back, they seam to be M1.3
<uvos>
bu i dont know the length, and as i can see the backlight through the holes i dont want to try it
<uvos>
could you unscrew one from your device (or tmlind) and tell me how long it is so i can get a replacement?
<uvos>
non extended battery for the bionic btw
<uvos>
someone really had a go at that d4 you sent me :P
<uvos>
every other screen is striped or in the wrong place or missing
<Wizzup>
uvos: ok yeah I forgot that @ battery
<uvos>
Wizzup: ok :)
<uvos>
Wizzup: at least it dident get lost in the post :)
<Wizzup>
I definitely didn't open up the tablets, but can see about the screws
<uvos>
its just the screws on the metal back plate
<uvos>
there all missing
<Wizzup>
hrm @ someone had a go at the d4 that I sent
<uvos>
idk whats holding the plate in
<uvos>
and the somone who really dident know what they are doing tried to solder the usb port
<uvos>
it has all the pins shorted :P
<Wizzup>
right, that's the non-working usb port
<uvos>
anyhow no matter the display is fine so i can use it to repair the other one :)
<Wizzup>
btw, regaridng damage to the package, that's weird, I think I was quite careful
<uvos>
Wizzup: you where
<uvos>
but it was droped or something
<Wizzup>
aha
<uvos>
looked like someone droped something heavy on one end really
<uvos>
but everything survived thanks to the bubbel wrap
uvos__ has joined #maemo-leste
<Wizzup>
glad to hear
lyubov_ has joined #maemo-leste
<uvos__>
old d4 works again :)
<uvos__>
i swaped the upper assembly with the one you sent me and it works
<uvos__>
tmlind: if you ever need me to test something on the unit where wifi only works on mainline with the pullup disabled this device exists again.
<mighty17[m]>
<sicelo "mighty17: we have logs ;-)"> ah right makes sense
<uvos__>
mighty17[m]: ok sounds sane
<Wizzup>
uvos: great
<uvos__>
mighty17[m]: leave the ml out then
uvos has quit [*.net *.split]
scops has quit [*.net *.split]
lyubov has quit [*.net *.split]
<mighty17[m]>
okayy
<mighty17[m]>
so nowbuilding maemo first?
<uvos__>
mighty17[m]: yeah so maemo steps 1. fix the patches 2. send them to me 3. if i think they are ok ill give to parazyd to include in the kernel and we will start building the espresso dtb. then you can do the image builder + hildon meta and leste config stuff
<uvos__>
and also figure out what the bootloader situation is going to be
<uvos__>
then we can start building images for the device
<uvos__>
i would not worry about sgx to mutch if ddk1.17 works on pmos ddk1.9 will very very likely just work with the droid4 packages
<uvos__>
bootloader situation must involve you booting the mainline or vendor kernel to kexecboot pretty mutch
<uvos__>
since thats the only way your device can share a kernel build with our other devices
<uvos__>
since the android bootloader wont be able to let you set cmdline or dtb
<uvos__>
vendor kernel rebuilt with kexec built in booting to kexecboot
<uvos__>
is likely best
<mighty17[m]>
<uvos__ "and also figure out what the boo"> about that for now, can we have another branch with that cmdline? we are not in the stage when we can call it booting so 1st step would be to get stuff working imo
<uvos__>
as this avoid any buggyness in kexecboot that might get in the way of development
<mighty17[m]>
<uvos__ "i would not worry about sgx to m"> yeah ddk isnt a big issue, if it works on d4 it will work here
<uvos__>
mighty17[m]: no i dont think we will include your device will a different branch
<uvos__>
ofc you can go and work on leste like that
<uvos__>
by building your own kernel
<uvos__>
but untill you figure out the bl situation so that you dont have to force the cmdline we cant accept the device
<mighty17[m]>
<uvos__ "mighty17: no i dont think we wil"> noo not like that, for initial testing then we'll figure out a way
<mighty17[m]>
<uvos__ "by building your own kernel "> yeah till it boots we can do that?
<uvos__>
sure but this dosent require "me" to do anything
<uvos__>
just base apply your patches to our kernel then and try boothing the bionic rootfs
<uvos__>
should mostly work
<mighty17[m]>
i mean yes but i have no clue on how to build maemo
<uvos__>
you dont have to build anything really
<uvos__>
just use the bionic rootfs
<uvos__>
and then uninstall the leste-config and hildon meta once its booted
<uvos__>
and then you just have to make and build those 2 packages
<uvos__>
and once you have the bl stuff figured out well add the device to our packages
<mighty17[m]>
flash boot.img (with leste kernel) and rootfs nice
<uvos__>
yeah dont forget to add the needed modules to the rootfs after dding it to the sdcard