<Entitlement>
Pali - [ GitHub - pali/u-boot-maemo: Maemo packaging of U-Boot bootloader for Nokia N900 ]
<parazyd>
Pali: Thanks. This nandwrite stuff is done from userspace, right?
<Pali>
it contains u-boot-gen-combined script which generates from u-boot.bin and uImage files one binary
<parazyd>
Nice
<Pali>
yes, nandwrite is called from userspace... but beware that NOLO expects some "proprietary" header, so you cannot easily write new image into nand
<parazyd>
Sure. I won't be writing anything now really, just good to keep it in mind.
<parazyd>
We obviously don't want to forcefully wreck existing installations.
<Pali>
in case somebody provide more "dumps" I can try to decode content of this header and extend 0xFFFF to support on-device flashing
<parazyd>
Got any guide to do so?
<Pali>
I think I already discussed about it month ago on some IRC channel... but do not remember neither channel nor with who
<Pali>
tested on my N900 with Maemo Fremantle+CSSU and it is working fine
<parazyd>
Yeah ok
<parazyd>
I'm doing it on our 5.1.21 n9xx-linux and Leste userspace
<parazyd>
When I finish up on something, I'll send you the dump from Fremantle
<Pali>
nandsim.ko on desktop returns "nanddump: error!: mtd_get_dev_info failed"
<parazyd>
heh
<Pali>
but "/usr/sbin/nanddump --omitoob -s 0 -l 2048 -f header.bin /dev/mtd3" is working
jonsger has joined #maemo-leste
<parazyd>
Here too
<parazyd>
Do you want this file?
<Pali>
it is needed to collect more "dumps", ideally also from devices which are flashed by COMBINED image
<parazyd>
I have 3 working RX-51 here
<parazyd>
If there's any image I should flash, I can. Just link it to me if you have time :)
<Pali>
"full" combined firmware: RX-51_2009SE_21.2011.38-1_PR_COMBINED_MR0_ARM.bin or RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin
<parazyd>
ACK
<Pali>
which rewrites everything
<Pali>
so it erase all data in n900 and also sets versions strings to Maemo, etc...
<parazyd>
All good
<sicelo>
Where can I send my header dump
<Pali>
if you do not care about privacy of this file then hexdump on some pastebin is fine
<sicelo>
I think I know your email ... will forward it there if you don't mind
<Pali>
ok
<sicelo>
I wanted to ask ... how to append kernel to u-boot? I wanted to append fremantle kernel in new u-boot, so I can eventually flash new u-boot but still have access to Fremantle
<Entitlement>
Pali - [ GitHub - pali/u-boot-maemo: Maemo packaging of U-Boot bootloader for Nokia N900 ]
<sicelo>
Thanks!
<Pali>
you need to generate uImage from your kernel (by u-boot tool mkimage) and then use this u-boot-gen-combined script which generates one binary from u-boot.bin and uImage
<sicelo>
Awesome
<uvos>
parazyd: yes @dfb
sicelo_ has joined #maemo-leste
<uvos>
parazyd: no order dosent matter
<parazyd>
ok
<uvos>
parazyd: puting it into boot run level breaks bypassing it tho
<uvos>
parazyd: i dont like that
<parazyd>
uvos: I just tested it on d4 and it doesn't work. It only works with openrc-init, and not sysvinit (which we use)
<parazyd>
But with openrc-init we lose inittab and I don't really want that
<sicelo_>
oh, thought we were openrc :)
<parazyd>
sicelo_: Yes as service manager, but not the init binary itself.
<parazyd>
(Same default is in Gentoo fwiw)
<uvos>
what do you want initab for?
<parazyd>
uvos: All our devices have an entry for the serial console in there
<Entitlement>
sicelo_ - [ kicherer.org - Recovering a non-booting Nokia n900 with Maemo from a SD card ]
<sicelo_>
i had the idea that we could make the whole u-boot process manageable inside Leste (or other linux), but still manage to keep Fremantle intact and bootable
<parazyd>
sicelo_: If you work on this, please let me know. I'd like to include such a script in our future N900 u-boot package.
<parazyd>
sicelo_: This way we could keep updating u-boot from Leste
<uvos>
kexecboot is not ok with it being a link :(
<parazyd>
eh
<parazyd>
I guess that's why we didn't have it there in the first place :D
<parazyd>
tmlind: Any idea why? ^
<sicelo_>
parazyd: sent my nand header now. will try 0xFFFF shortly
<sicelo_>
ah, meant, Pali ^^
<parazyd>
:)
<Pali>
got it
<Pali>
seems that everything is zero except "NOLO!img" at offset 0x00 and bytes 0x00 0x4c 0x1b 0x00 at offset 0x10
<Pali>
on my N900 I have bytes 0x80 0xa7 0x1e 0x00 at offset 0x10
<Pali>
so looks like some checksum? or version info?
<sicelo_>
i ran `/usr/sbin/nanddump --omitoob -s 0 -l 2048 -f header.bin /dev/mtd3` to produce that. let me try on a different N900
<sicelo_>
looks like i can only do that later. battery super empty on that n900. which is strange - it was fully charged two or three days ago, and was switched off
<Pali>
hm..., "sudo 0xFFFF -t kernel -e" on my N900 dumps kernel image to file with size 2008832 and 0x80 0xa7 0x1e 0x00 in little endian is number 2008960
<Pali>
so I bet it is size of the image
<Pali>
0xFFFF currently dumps bytes from mtd, trim that header and then truncate zeros from the end of the file
<Pali>
sicelo_: could you run "sudo 0xFFFF -t kernel -e" and look what is the size of dumped file "kernel-*"? if it is about 1788928 bytes (little endian 0x00 0x4c 0x1b 0x00)
<sicelo_>
btw that needs N900 to be switched off?
<Pali>
that from which you generate dump which you sent me via email
<Pali>
anyway, somebody else could confirm this
<sicelo_>
no idea what's up with my laptop ... 0xFFFF sees device in USB Mass Storage mode :'(
<Entitlement>
parazyd - [ Community SSU - maemo.org wiki ]
<Wizzup>
parazyd: yeah, ok, I'll just download some combined PR and see, I'm sure it'll break a few times along the way
<sicelo_>
Wizzup: yes, there is. anyway, for the purpose of Leste, CSSU isn't a requirement. so after flashing regular images, one can go ahead with Leste
<Wizzup>
like the repo lines being wrong, containing the wrong components
<parazyd>
Could happen :D
<Wizzup>
sicelo_: It's not for leste, I want to flashthis n900 for daily usage with fremantle
<sicelo_>
oh nice :)
<Wizzup>
my current one has a broken usb port and broken earspeaker
<Wizzup>
(yeah)
<sicelo_>
ouch. i still need to fix my broken usb port n900. for current mainline play i've been using older n900 with broken modem and half-working touch :p
<uvos>
uff the conditions of these devices :P
<Wizzup>
I have plenty of n900s, but I am not looking forward to the migration
<Wizzup>
my current one is quite customised
<uvos>
dd?
<sicelo_>
you could migrate very easily with bootmenu ;)
<Wizzup>
rather not, some things about it are also broken in a way that I suspect are rootfs corruption :P
<parazyd>
Wizzup: btw I might have solved the ntp flakiness.
<sicelo_>
ah
<Wizzup>
sicelo_: what do you mean?
<Wizzup>
parazyd: ah?
<parazyd>
Wizzup: I appended "-4" to the ntpdate opts
<Wizzup>
heh
<parazyd>
To force IPv4 and it's working for me constantly now
pere has joined #maemo-leste
<sicelo_>
bootmenu can take image of the entire device, and can be placed on any other n900 ... you just need to ensure the is the same kernel on the other device (quite easy to do with u-boot)
<sicelo_>
not u-boot's bootmenu, btw. Fanoush Bootmenu
<Wizzup>
ok, but I think I don't want to do htat per above
<sicelo_>
sure, makes sense
<halftux>
sicelo_: ah there was a release of version 0.9 from 0xFFFF in January. Did not know about it because it was not in maemo repos. I can make a version up and compile it again if this satisfy you more.
<Pali>
sicelo_: omfg, I have there a bug in that patch ... memcmp(header_buf, "NOLO!img", 8) == 8 ... obviously memcmp returns zero on "success"
<Pali>
to it should be == 0
<Wizzup>
sicelo_: btw I dropped you a pm, not sure if you saw it
<Wizzup>
(you said you had trouble with PMs)
<parazyd>
Wizzup: I've scheduled this ntp -4 configuration for tomorrow's image builds, so we'll see if it solves the issue for people who had it
<Wizzup>
that includes me :p
<parazyd>
:)
<parazyd>
It's not part of any package though, so add it manually if you don't plan to reflash
<parazyd>
/etc/default/ntpsec-ntpdate
<parazyd>
Should be "-b -4"
<Wizzup>
can we make it part of some package somehow?
<parazyd>
No point
<Wizzup>
otherwise we will have users reporting bug sfor it still
<parazyd>
I don't want to (yet)
<parazyd>
Because we might again just switch to chrony if it's better
<parazyd>
Let's first see if it works
<Wizzup>
if it's part of leste-config we can also remove it later, right?
<Wizzup>
and fine if not yet
<parazyd>
Yes @ leste-config
<parazyd>
tbh I'm a bit overwhelmed again with the state of devel
<parazyd>
I should really just promote some stuff
<Wizzup>
better than users getting -devel on them and being overwhelmed :p
<Entitlement>
Pali - [ Flashing an eMMC image returns "Error: Not implemented yet" · Issue #6 · pali/0x... ]
<Wizzup>
ok
<halftux>
Wizzup: is screen orientation working in Qt? I guess the old maemo way of a widget attribut is no more valid or?
<Wizzup>
yes, that does
<Wizzup>
that should work
<Wizzup>
halftux: please let me know if you encounter missing qt5 features
<Wizzup>
Unable to download 'community ssu-enabler' Application not found RIP
<uvos>
Wizzup: better get cracking on that phone app then :P
<parazyd>
:p
<Wizzup>
:/
<Wizzup>
will try non-thumb then
<halftux>
yes I will do so far I managed to find already your work about progress indicator and stackedwindow well done of course same goes for the other work on Qt I really appreciate it
<Wizzup>
Yeah, looking at Dorian or countdowntimer will show what to do for porting
<uvos>
parazyd: is there an easy way to see whats in devel?
<parazyd>
Gimme a few minutes, on a phone call atm
<uvos>
i think these periferal apps can skip devel
<uvos>
or is countdowntimer important somehow?
<Wizzup>
countdowntimer is 'my' app
<Wizzup>
it might just never been moved over since I am always on devel
<parazyd>
Yeah also I'm the only one doing this promotion maintenance
<parazyd>
So for sure I miss stuff
<uvos>
stuff like countdowntimer or osso-caluclator dosent need to be in devel first at all imo
<parazyd>
++
<parazyd>
Except if it had a -devel dependency
<Wizzup>
yeah that's probably exactly what happened
<Wizzup>
wrt my qt5 work
<uvos>
yeah ok
<parazyd>
mhm
<parazyd>
Wizzup: You ok with moving h-d to main?
<parazyd>
This implies all the shortcut and h-i-m stuff
<uvos>
devl h-d is inidpendant of him
<Wizzup>
Do we have the shortcuts for the n900 working still?
<uvos>
devel him that is
<uvos>
Wizzup: yes
<Wizzup>
ok
<Wizzup>
then sure
<uvos>
Wizzup: not vm tho
<uvos>
Wizzup: problem was vm has no leste-config
<Wizzup>
that should be fixable
<parazyd>
Yeah VM only has the -common
<parazyd>
Sure
<parazyd>
But not trivial through upgrade
<parazyd>
Only for new images
<uvos>
probubly unimportant
<uvos>
vm is for developers
<Wizzup>
would be nice to have a config for it still though
<Wizzup>
and yeah probably ok if upgrade doesn't pick it up
<uvos>
just copy n900 config
<uvos>
then its the same as before
<uvos>
(shortcuts.ini)
* Wizzup
hopefully almost done with migration to working n900
<Wizzup>
then the next things are d4 modem debugging (sim not seen on reboot, data only working sometimes with ofono), libicd ofono async data setup, pulse policies
<Wizzup>
uvos: do you recall what has to be done to have headphone jack detection on the d4
<uvos>
yeah sure
<Wizzup>
could we document that somewhere (here is ok, I can make a ticket)
<parazyd>
Wizzup: Yeah lmk please when you figure that modem thing
<uvos>
so the android kernel uploads a firmware to cpcap (that runs some sort of rtos from rom)
<parazyd>
Wizzup: That "blocks" clean GPS
<Wizzup>
parazyd: that is not 'ofono does not detect modem is already online' fwiw
<uvos>
and it dose mostly everything for the kernel
<parazyd>
Well
<uvos>
so we dont know how plug detection works
<parazyd>
I had hoped it's connected
<Wizzup>
uvos: how large is this firmware?
<uvos>
because fw is closed source
<uvos>
Wizzup: pretty small
<Wizzup>
do you have the file?
<uvos>
Wizzup: its an app for the rtos after all
<uvos>
Wizzup: not full fw
<uvos>
its integrated into dts as hex iirc
<Wizzup>
I wouldn't mind throwing it in ida
<uvos>
its not that simple
<uvos>
the android kernel has lots of code to interface with the rtos
<uvos>
maybe the nxp datasheet says how to do plug detection without the cpcap-uc
<uvos>
as the nxp chip dosent have that
<uvos>
maybe it would be better to do that (if registers align)
<Wizzup>
is there a way to probe the states and compare before/after or something?
<uvos>
sure you could read the register space of the chip
<uvos>
and see if it changes when you plug stuff in
<uvos>
you still need to enable the itterupt on that channel somehow tho
<Wizzup>
tmlind: do you have any more info / suggestions here?
<sicelo_>
(yay, fm transmitter now working nicely)
<Wizzup>
leste?
<sicelo_>
after hardware 'fix'
<Wizzup>
Do you use the alsa way, or is it picked up by pulse now
<parazyd>
uvos: btw. did you get my message earlier about megapixels (the camera app)
<sicelo_>
sorry ... this is on fremantle. the fm transmitter was hardly usable now because the antenna contacts were no longer making good contact with the board. as for Leste, i haven't played with the fm transmitter again since the alsa days
<Wizzup>
ok
<uvos>
parazyd: yes neat :)
<Wizzup>
we probably want to see how we can make it work with pulse in the near future
<parazyd>
IIRC there are resources for Raspberry Pi and pulse regarding fmtx
<Entitlement>
Pali - [ GitHub - pali/0xFFFF: Open Free Fiasco Firmware Flasher for Maemo devices ]
<Wizzup>
ok, need to run an errand outside now
<Pali>
parazyd: u-boot is stored in kernel mtd area together with kernel... so to safely update just u-boot you need to dump kernel mtd area to local file, update uboot in this local file and then flash local file back to the kernel mtd area
<parazyd>
oh ok, makes sense
<Pali>
kernel starts at fixed location 262144
<parazyd>
So it'd always be safe in theory
<Pali>
so before it is u-boot
<parazyd>
sicelo_: ^ If you want to make a script... Here's your chance :p
<Pali>
and via new patches in 0xFFFF you can play with dumping and flashing image
<Pali>
I think now you have everything needed for updating u-boot from any OS which can access /dev/mtd*
<parazyd>
Definitely seems like it
<Pali>
in 0xFFFF is also detection code if binary file is u-boot or zImage linux kernel
<Pali>
so you can add similar check to detect if user has in kernel mtd area u-boot or not
<parazyd>
*nod*
<Pali>
if it does not have u-boot it is zImage kernel... and it its size is less than maxsize - 262144 then you can "append" it into newly flashing uboot
<Pali>
so user does not loose its kernel which is currently flashed