<gnarface>
dunno if it's important or not, but anecdotally, in relation to the specs on the 2 main pinephone models, it should be mentioned for completeness there's also a 3GB version of the regular (allwinner) pinephones' motherboards in the wild
<gnarface>
i just remembered that i'd forgotten to mention it when it came up before
mdz has joined #maemo-leste
<Wizzup>
gnarface: I think they sell that, right?
<Wizzup>
oh, of the regular pinephone
* Wizzup
waking up
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
<gnarface>
yes, they sell them too, and they sell the boards as a replacement part
<gnarface>
so you can theoretically upgrade a 2GB one to a 3GB one by replacing the mainboard
mdz has quit [Remote host closed the connection]
mdz has joined #maemo-leste
xmn has joined #maemo-leste
jpit has joined #maemo-leste
jpit has quit [Client Quit]
spire has quit [Ping timeout: 252 seconds]
mdz has quit [Quit: mdz]
mdz has joined #maemo-leste
<Wizzup>
tmlind: if you recall, do you know why in particular having the modem on spi is problematic?
<Wizzup>
uvos and I were looking yesterday and he said the main problem was some big userspace blob on android that is required for it to work at all
<Wizzup>
or he said that was what he recalls anyway
uvos has joined #maemo-leste
<uvos>
Thats just why looking at the android implementation is only semi-usefull
<uvos>
the qmi over usb mapphones use the same blob
<uvos>
its not related what exactly is bus senstive in the mainline kernel
<uvos>
i have no idea about that
<tmlind>
i think there's a separate qmi driver for spi in the v3.0.8 kernel sources, no idea how much work making that work with the usb qmi in the mainline kernel could be
<tmlind>
if the spi driver just implements a network interface maybe it would be simple
<tmlind>
hmm no i guess the transport is usb underneath qmi..
<tmlind>
yeah but i think that's not how the mainline kernel does qmi, it's mostly the libqmi doing i believe
<tmlind>
on the kernel side it seems to be cdc_wdm and qmi_wwan modules
<tmlind>
so some kind of spi ethernet device would need to be implemented i think similar to usb ethernet similar to qmi_wwan
<Wizzup>
that doesn't sound too easy but conceptually also perhaps not too hard
<Wizzup>
uvos: so for mz617,
<Wizzup>
oops
<Wizzup>
so for mz617, which partitions can we safely nuke?
<Wizzup>
and can we re-partition somehow? to merge partitions?
<uvos>
Wizzup: we can not modify the partition table in any way its singed and the bootloader relies on the exact table to function anyhow (since it checks partitions for integrety)
<uvos>
im not exactly sure for mz617, it depends on if you want to sacrifice android or not
<uvos>
you can use cache and emtstorage if you need to keep android
<uvos>
and preinstall
<uvos>
if you dont care about android you can also eat system and data
<uvos>
system needs to stay ext3, the bootloader checks this
<uvos>
otherwise it dosent care about these partitions
<uvos>
(its not only ext3 but also the exact fs label and uuid)
<uvos>
data and emtstorage are probubly the only ones of usefull size
<uvos>
for a rootfs that is
<uvos>
we could use a btrfs spaned volume to span all the partitions together
<uvos>
for rootfs maybe
<uvos>
and use system as ext3 for boot
<uvos>
since the 3.0.8 kernel wont be able to mount a btrfs volume to kexec a kernel there
<Wizzup>
uvos: heh yeah @ btrfs
<Wizzup>
that's a good idea
<uvos>
there is also cdrom
<uvos>
its small
<uvos>
but thats where i have kexecboot
<uvos>
iirc
<uvos>
on mz617
<Wizzup>
and I guess we need to be able to actually format these partitions somehow
<Wizzup>
like, we can't from android, and not from kexecboot
<Wizzup>
also, I think if btrfs uses more than one device, it needs an initramfs unfortunately
<uvos>
on a single device this would mean allways doing random reads/writes
<Wizzup>
it needs to find all the devices
<Wizzup>
I don't know if what you describe exists though
<uvos>
yes it dose
<uvos>
btrfs has a spaned mode
<Wizzup>
oh yes
<Wizzup>
ok, -d single
<Wizzup>
maybe also with -m single
<uvos>
yes both
<Wizzup>
so how do we do this in a method that isn't completely a pita
<uvos>
we have an installer
<uvos>
we flash it to system with the contense of boot
<Wizzup>
can we have the user kexec to a usb stick (or microsd on usb stick) which then runs a script that sets this up?
<uvos>
that boots, sets up the partitions
<Wizzup>
ah
<uvos>
we can just use fastboot
<Wizzup>
wait so what is actually on /boot ?
<Wizzup>
or 'boot' rather
<uvos>
the android kernel
<uvos>
that bit needs to stay
<uvos>
ofc
<uvos>
since kexecboot uses it
<uvos>
besides its signed you cant change it anyhow
<Wizzup>
oh, sorry, you said we flash it to system
<uvos>
yes
<uvos>
we flash leste boot + small rootfs to system
<uvos>
the small rootfs sets up everything else
<Wizzup>
ok, so leste boot is kernel, dtb, and some busybox with btrfs-progs
<uvos>
and then prompts the user for wifi to download the real rootfs image to flash to the spaned volume
<uvos>
jup
<Wizzup>
argh, that would require making some ui for wifi
<uvos>
not really
<Wizzup>
can't we have the image on usb or so?
<uvos>
could just be a cli program
<Wizzup>
oh, they would use otg with keyboard?
<uvos>
sure but that requires everyone to have an otg cable
<uvos>
id rather it just pull it via wifi really
<uvos>
Wizzup: we have fbkeyboard
<Wizzup>
what I meant to ask is how do you type in your wifi credentials without a keyboard
<Wizzup>
ok
<uvos>
fbkeyboard works great
<Wizzup>
wifi to mean feels less reliable but if that works, then great
<Wizzup>
to me*
<uvos>
seams the simplest for the user
<uvos>
to me
<uvos>
its also how destop installers work
<uvos>
after all
<Wizzup>
what if we set up usbnet and ssh and just have them rsync
<uvos>
sure
<uvos>
but thats more involved for the user too
<uvos>
since he has to use the cli on his desktop
<uvos>
the wifi method could be fully automated after the fastboot call
<uvos>
besides asking the user for wifi pw via fbkeyboard
<uvos>
wait no
<uvos>
all this is unessecary
<uvos>
you can add to a btrfs span while its mounted
<uvos>
so we can simply flash a leste rootfs to data or emtstorage (need to try if fastboot allows either of those with an unsinged image, but probubly)
<uvos>
and then when leste boots the first time it adds the spans
<uvos>
ether data or emstorage would be big enough for this maneouver
<Wizzup>
leste rootfs needs over a gigabyte
<Wizzup>
unless we also have btrfs compress, then it might be smaller
<uvos>
emstorage is 8
<uvos>
and data is 4 iirc
<uvos>
so no problemo
<Wizzup>
oh, then we can just dd a leste image indeed
<uvos>
you cant dd
<Wizzup>
well fastboot
<uvos>
but you can ask fastboot nicely
<uvos>
im not sure it will allow it
<Wizzup>
would be worth checking
<Wizzup>
btw, I have a mz617 here that is the 16G version
<uvos>
yeah mine is 16g too
<Wizzup>
I didn't try kexecboot yet (since the utags file has 23 in it, not 16)
<uvos>
i used custom utags for it
<uvos>
it boots from cdrom, as i say
<Wizzup>
ok so we could try to set up a loopback and format it as btrfs, rsync an image (minus boot) and try to use fastboot
<Wizzup>
ok, well, if we can have a utags file for 16G that would be good for users (me :D )
<uvos>
needs to be exact size
<uvos>
im not sure if the partion table is different
<uvos>
besides different sizes
<uvos>
i think not
<uvos>
so same utags should be fine
<Wizzup>
ok
<Wizzup>
what do you think about btrfs compression?
<Wizzup>
I think it might make sense given the space contraints
<Wizzup>
zstd should be quite good for this
<uvos>
idk omap4 is pretty slow too
<uvos>
on the 32gb variants it seams excessive for sure
<bencoh>
if that thing has a microsd slot I wouldn't bother with compression
<uvos>
they dont
<bencoh>
oh
<uvos>
its 16gb with 12 or so usable
<Wizzup>
zstd is quite fast though
<uvos>
quite tight
<uvos>
or 32gb with 25 or so usable
<uvos>
pretty ok
<Wizzup>
well, let's just get it working and then we can see :)
pere has quit [Ping timeout: 276 seconds]
arno11 has joined #maemo-leste
<arno11>
Wizzup: for pm stuff: thank you for helping me to understand :)
<arno11>
freemangordon: i maybe found something interesting about slow shutdown
<arno11>
event 4 - gpio_keys: client bug: event processing lagging behind 12ms, your system is too slow
<arno11>
twl4030 keypad client bug: event processing lagging behind 12ms, your system is too slow
<arno11>
it happens on other distros and seems related to CONFIG_USB_AUTOSUSPEND_DELAY=2 in kernel config
<arno11>
the delay is too low
pere has joined #maemo-leste
<Wizzup>
arno11: yeah so it's not trivial unfortunately, and most of it requires kernel work/dev
<Wizzup>
finding what blocks is just the first step, the second is then to actually fix the drivers
<arno11>
yup, makes sense
<freemangordon>
arno11: what it is?
<arno11>
i don't know exactly how it works atm, but increasing the delay could help apparently
<arno11>
bbl
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
arno11: when you get back, can you share some links on this finding?
xmn has quit [Ping timeout: 245 seconds]
<uvos>
arno11: thats harmless really
<uvos>
this is just libinput complaining that it cant keep up with evdev events which is fine and expected on a heavly loaded n900 (like during shutdown)
<uvos>
you can make this happen at any time on d4 to by loading its io alot and then madly swipeing at the ts
<uvos>
i also suspect this sort of thing will be compleatly unavoidable when/if we get off mode working on n900
<uvos>
considering how long the n900 takes to wake up from ret and off
<sicelo>
this happens even on my i5-4300M + 16GB RAM
mqlnv has quit [Ping timeout: 255 seconds]
mqlnv has joined #maemo-leste
<Wizzup>
sicelo: your system is too slow
<sicelo>
yeah, libinput needs amd epyc :-p
<Wizzup>
hey, that's what they tested it on ;)
<Wizzup>
uvos: did you find the time to look at the derive tree from atrix2?
<Wizzup>
pardon my ignorance but which are the modem ones
<Wizzup>
ipc_* ?
<uvos>
very likely this is omap4->omap2 comms
<uvos>
inter processor comunication baseband proc wake
<uvos>
and
<uvos>
inter processor comunication application proc wake
<uvos>
etc
<uvos>
whats wierd
<uvos>
is the missing cpcap-*
<uvos>
also lm3532_reset is the same
<uvos>
which is annoying
<uvos>
since that means 1 it exists and 2 the gpio is the same
<uvos>
but its not working
<uvos>
maybe its on another bus
<uvos>
no its not bus1devices = "lm3532";
<uvos>
huh
<uvos>
no idea why its not working
<uvos>
regulator different maybe
<uvos>
hmm not it must be getting power otherwise the backlight would simply be off
<Wizzup>
maybe this is silly but you're sure the python unsignalmap does the right thing?
<Wizzup>
(just in case that might explain the diff)
<Wizzup>
also, I think this confirms that the modem is not on usb, eh
<uvos>
it decodes the bionic signalmap the same as the file
<uvos>
also the signalmap for edison is simply mutch shorter (raw bytes)
<uvos>
also the gpios of edison are all the same as bionic (when listed)
<uvos>
so
<uvos>
im pretty sure
<uvos>
at least the accelrometer not working is no suprise
<uvos>
it uses lis3dh like d4 not kxtf9 like bionic
<uvos>
but it also has the magnetometer like bionic, unlike d4/3
<uvos>
thats sad kxtf9 is the better chip
<uvos>
Wizzup: modem is spi
<uvos>
Modem@0 type = <0x2400>; is the same as xt910 but unlike xt875/xt894 so 0x2400 is probubly the spi variant
<Wizzup>
yeah :(
<uvos>
yeah usb mbm6600 is 0x1e0001 across the board
<uvos>
so besides the spi modem
<uvos>
the only unsolved mystery is why whats wrong with lm3532
<uvos>
probubly the same thing thats wrong with lm3532 on the d3 so would be good to find out
<uvos>
otherwise its just copy bionic dts, replace the accel node with the one from d4 and add the shutter button to the omap matrix and were done here
<Wizzup>
oh, right, the d3 also had backlight problems
<uvos>
same exact thing
<Wizzup>
yeah
<uvos>
dts entries and gpios are the same as on d4
<uvos>
but writeing there dosent do anything
<Wizzup>
wrt modem on spi, this also means currently we don't get an audio card, can we get it without modem?
<uvos>
sure we can
<uvos>
you just have to eject it from the dts for me/mb865
<Wizzup>
right
<uvos>
me865 seams exatcly the same btw
<uvos>
same dts same signal map to the byte
<Wizzup>
yeah was just about to ask :)
<uvos>
me865 is just the retail non-att branded version
<uvos>
its not a huge suprise its the same device
<uvos>
presumably only the modem firmware differs
<uvos>
if that
<Wizzup>
mhm
uvos has quit [Quit: Konversation terminated!]
humanbeta has quit [Quit: Client closed]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 264 seconds]
xes_ has quit [*.net *.split]
vahag has quit [*.net *.split]
LjL has quit [*.net *.split]
dsc_ has quit [*.net *.split]
dos has quit [*.net *.split]
crab has quit [*.net *.split]
nohit has quit [*.net *.split]
_alice has quit [*.net *.split]
elastic_dog has quit [*.net *.split]
mqlnv has quit [*.net *.split]
Kabouik has quit [*.net *.split]
sch has quit [*.net *.split]
tk has quit [*.net *.split]
mdz has quit [*.net *.split]
akossh has quit [*.net *.split]
pere has quit [*.net *.split]
lexik has quit [*.net *.split]
peetah has quit [*.net *.split]
retr0id has quit [*.net *.split]
Armen has quit [*.net *.split]
attah has quit [*.net *.split]
lel has quit [*.net *.split]
hexnewbie has quit [*.net *.split]
lightbringer has quit [*.net *.split]
[TheBug] has quit [*.net *.split]
Danct12 has quit [*.net *.split]
joerg has quit [*.net *.split]
parazyd has quit [*.net *.split]
Wizzup has quit [*.net *.split]
sunshavi_ has quit [*.net *.split]
srb has quit [*.net *.split]
Blikje has quit [*.net *.split]
freemangordon has quit [*.net *.split]
Oksana has quit [*.net *.split]
peterM has quit [*.net *.split]
udder has quit [*.net *.split]
Juest has quit [*.net *.split]
f_ has quit [*.net *.split]
buZz has quit [*.net *.split]
bencoh has quit [*.net *.split]
danielinux has quit [*.net *.split]
ungeskriptet has quit [*.net *.split]
branon has quit [*.net *.split]
jrayhawk has quit [*.net *.split]
eval has quit [*.net *.split]
ikmaak has quit [*.net *.split]
inky has quit [*.net *.split]
l_bratch has quit [*.net *.split]
moparisthebest has quit [*.net *.split]
aat596 has quit [*.net *.split]
doc has quit [*.net *.split]
meridion has quit [*.net *.split]
TheTechRobo has quit [*.net *.split]
panzeroceania has quit [*.net *.split]
RedW has quit [*.net *.split]
nela has quit [*.net *.split]
Amnesia_ has quit [*.net *.split]
norly has quit [*.net *.split]
vectis has quit [*.net *.split]
enyc has quit [*.net *.split]
sixwheeledbeast has quit [*.net *.split]
eloy has quit [*.net *.split]
juiceme has quit [*.net *.split]
antranigv has quit [*.net *.split]
Langoor has quit [*.net *.split]
sicelo has quit [*.net *.split]
jr-logbot has quit [*.net *.split]
LIERO has quit [*.net *.split]
jessicant has quit [*.net *.split]
brabo has quit [*.net *.split]
tmlind has quit [*.net *.split]
Wizzup has joined #maemo-leste
LjL has joined #maemo-leste
Armen has joined #maemo-leste
Juest has joined #maemo-leste
mdz has joined #maemo-leste
joerg has joined #maemo-leste
vahag has joined #maemo-leste
mqlnv has joined #maemo-leste
Danct12 has joined #maemo-leste
xes_ has joined #maemo-leste
inky has joined #maemo-leste
ikmaak has joined #maemo-leste
sch has joined #maemo-leste
parazyd has joined #maemo-leste
pere has joined #maemo-leste
srb has joined #maemo-leste
sunshavi_ has joined #maemo-leste
ungeskriptet has joined #maemo-leste
elastic_dog has joined #maemo-leste
branon has joined #maemo-leste
RedW has joined #maemo-leste
f_ has joined #maemo-leste
attah has joined #maemo-leste
dos has joined #maemo-leste
dsc_ has joined #maemo-leste
antranigv has joined #maemo-leste
Langoor has joined #maemo-leste
_alice has joined #maemo-leste
bencoh has joined #maemo-leste
hexnewbie has joined #maemo-leste
lexik has joined #maemo-leste
buZz has joined #maemo-leste
moparisthebest has joined #maemo-leste
nela has joined #maemo-leste
l_bratch has joined #maemo-leste
norly has joined #maemo-leste
Kabouik has joined #maemo-leste
lightbringer has joined #maemo-leste
lel has joined #maemo-leste
Blikje has joined #maemo-leste
aat596 has joined #maemo-leste
crab has joined #maemo-leste
freemangordon has joined #maemo-leste
peetah has joined #maemo-leste
peterM has joined #maemo-leste
Amnesia_ has joined #maemo-leste
doc has joined #maemo-leste
brabo has joined #maemo-leste
[TheBug] has joined #maemo-leste
nohit has joined #maemo-leste
meridion has joined #maemo-leste
sixwheeledbeast has joined #maemo-leste
jrayhawk has joined #maemo-leste
retr0id has joined #maemo-leste
TheTechRobo has joined #maemo-leste
juiceme has joined #maemo-leste
jessicant has joined #maemo-leste
eloy has joined #maemo-leste
tk has joined #maemo-leste
jr-logbot has joined #maemo-leste
Oksana has joined #maemo-leste
enyc has joined #maemo-leste
tmlind has joined #maemo-leste
panzeroceania has joined #maemo-leste
LIERO has joined #maemo-leste
sicelo has joined #maemo-leste
vectis has joined #maemo-leste
udder has joined #maemo-leste
eval has joined #maemo-leste
danielinux has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
DPA has quit [Max SendQ exceeded]
DPA has joined #maemo-leste
<Wizzup>
uvos: with zstd:15 and -m single -d single, we need ~1.2G:
<Wizzup>
$ df /mnt/leste-btrfs/
<Wizzup>
Filesystem 1K-blocks Used Available Use% Mounted on