<Entitlement>
parazyd - [ #maemo-leste on 2021-04-10 — irc logs at whitequark.org ]
<tmlind>
cool, hi all whitequark readers :)
<parazyd>
:))
<parazyd>
I'll update the chan topic once I'm at my computer later today
<tmlind>
ok
xmn has joined #maemo-leste
belcher_ is now known as belcher
<Pali>
Hello! Is somebody using (or tested) upstream U-Boot on Nokia N900?
<parazyd>
Pali: I wanted to actually package it at some moment
<Pali>
I would like to know if it is finally working fine or somebody found some issue...
<parazyd>
Pali: Do you know if it's possible to flash/update it from Linux userspace running from sdcard (i.e. Leste)?
<parazyd>
fwiw it seemed to be working fine
<parazyd>
The serial console and all
<Wizzup>
parazyd: I have only tried your version with patches, I can try latest master from upstream if you want
<Pali>
there is one issue with flashing, image in mtd partition is prepended with some proprietary nokia header
<Pali>
which NOLO loads & validate
<parazyd>
Meaning?
<Pali>
so for flashing is needed to use nokia tool
<parazyd>
Can 0xffff flash it?
<parazyd>
ah
<Pali>
Maemo has softupd daemon and flasher client tool
<Pali>
softupd is doing flashing and listen on TCP port on localhost
<Pali>
flasher then just pass data over TCP to softupd
<Pali>
0xFFFF does not implement this TCP flashing protocol
<Pali>
and I have not looked at it
<Pali>
but you may try to take Maemo softupd, flasher, libraries binaries and run them from sd card and different userspace
<Pali>
I guess that they should work, there is probably only libc.so dependency
<Pali>
or if you collect enough "dumps" from mtd partition I can try to decode that proprietary header and create simple script which generate it
<Pali>
with nokia header generator, it could be possible to generate full image and write it to mtd partition via /usr/sbin/nandwrite
<Pali>
according to my notes, header has fixed size 0x800 on all nokia/maemo devices
<Wizzup>
if we make a simple tool, we could ask all lestenians to run it
<Pali>
this command should dump that 2048 byte long nokia header from kernel partition to header.bin file: /usr/sbin/nanddump -o -b -s 0 -l 2048 -f header.bin /dev/mtd3ro
<Wizzup>
do you also need the contents after the header (in case it's checksum)
<Pali>
after header is raw image (kernel image)
<Pali>
or u-boot
xmn has quit [Ping timeout: 265 seconds]
<Wizzup>
ok, but in case that contents is checkesummed in the header?
<Wizzup>
I suppose it might not matter, just thinking out loud
<Pali>
ok, make sense
<Pali>
via usb flashing is sent XOR checksum
<Pali>
so maybe it is stored also in header
xmn has joined #maemo-leste
<freemangordon>
Wizzup: pong
<Wizzup>
freemangordon: I would like to merge uvos' PR for him that seems to properly fix enter handling and also provide vkb for plain x apps
<Wizzup>
I'm looking at the code still, but it looks pretty good, and wanted to get your OK on getting it in -devel
<Wizzup>
(since you're the maintainer)
<freemangordon>
Wizzup: I am fine with introducing it to -devel
<freemangordon>
did you manage to show VKB in VM?
<Wizzup>
freemangordon: vkb yes, but not uvos his specific changes yet
<freemangordon>
can't parse, please rephrase
<Wizzup>
I have no problems wit vkb in my current vm, in gtk2 apps
<Wizzup>
but trying his new support (for plain x) I still need to figure out when it should work
<freemangordon>
I meant your note on github
<freemangordon>
ok
<buZz>
does anyone know , does MMS work on maemo leste ?
<freemangordon>
BTW, by "proper fix", you mean - instead of hardcoding KP_ENTER to show VKB, a dbus iface is introduced. Do I get it right?
<Entitlement>
Wizzup - [ Unredirect enter key by IMbackK · Pull Request #2 · maemo-leste/hildon-input-met... ]
<Wizzup>
s/I'm//
<freemangordon>
Wizzup: I was just asking about your confirmation (or not) of my understanding
<freemangordon>
have to go afk, bbl
<Wizzup>
freemangordon: yes @ dbus interface
<siceloa>
buZz: nothing for it yet, plus i don't think anyone tested it yet, even on cli. additionally, many networks no longer have MMS, like mine
<buZz>
siceloa: ofono has mmsd by intel(??)
<siceloa>
i meant - gui :)
<buZz>
yeah i was suprised someone started talking about MMS in this day and age :P
<buZz>
appearantly some nations still use it
<siceloa>
seems MMS is still popular in some places, indeed. there's a lot of recent work on supporting it for Pinephone for example. so yeah
<siceloa>
anyway, fremantle didn't even have mms support, as delivered by nokia. was a community addon - fMMS (which still works well, according to fmg)
<siceloa>
i should think fMMS should work as is on Leste
<buZz>
either way, someone in #linux-sunxi was trying to figure out how to get commit rights to kernel.org 's mmsd repo :P
<buZz>
seems all commits were by @intel.com accounts , so just seems unlikely they will care
<siceloa>
that being kop316, perhaps?
<buZz>
yes :)
<siceloa>
:p
<siceloa>
sorry for pinging, but, freemangordon , Wizzup , i've mentioned here before that the keyboard LEDS on N900 aren't working since 5.9, with the following message/error in dmesg, "lp5523x probe of 2-0032 failed with error -22"
<siceloa>
i will look at this, and try a couple of things, but just thought that if you have any ideas about how to approach it, would be helpful
<siceloa>
i know there were a couple of commits affecting lp5523 sometime in august, so will probably start by reverting those, etc. someone suggested that this kind of issue would be due to bad dts ... no idea. will look
<siceloa>
the lazy approach (or is it the better one?) would probably be to just write to ML or pavel
xmn has quit [Read error: Connection reset by peer]
_blasty`_ has quit [*.net *.split]
vectis_ has quit [*.net *.split]
Armen has quit [*.net *.split]
Armen has joined #maemo-leste
vectis_ has joined #maemo-leste
_blasty`_ has joined #maemo-leste
xmn has joined #maemo-leste
<Wizzup>
siceloa: I'd mail sre and pavel wrt the probe fail
<Wizzup>
unless -22 is -EDEFER, then it might be something else
<Wizzup>
then you might lack some config option
<siceloa>
it's EINVAL, apparently
<Wizzup>
ok, then it might make sense to send him an email
<siceloa>
cool. thanks. :)
<siceloa>
otherwise nice that 5.12-rc6 seems to be working good. haven't tested SGX yet
<Pali>
buZz: admins on kernel.org can gain access to git kernel.org repos
<buZz>
right
<buZz>
but asking in #linux-sunxi for commitaccess on kernel.org isnt really productive i guess :P
<Pali>
Konstantin Ryabitsev is contact person
<Pali>
or sending email to helpdesk@kernel.org
<siceloa>
buZz: i guess he went there because someone said: "The Pine64 kernel should be maintained by the sunxi linux community. If you join me in the #linux-sunxi channel on the Freenode server we can ask them how the upstreaming process works"
<buZz>
i dont think anyone on linux-sunxi has commit access to kernel.org , but ok :P
<siceloa>
yeah. i guess that good samaritan was mistaken :)