arcean has quit [Read error: Connection reset by peer]
Kabouik_ has quit [Ping timeout: 265 seconds]
XDS2010_ has quit [Ping timeout: 252 seconds]
PeperPots____ has quit [Ping timeout: 265 seconds]
modem has quit [Ping timeout: 245 seconds]
norly has joined #neo900
PeperPots____ has joined #neo900
XDS2010_ has joined #neo900
norly has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
~die
infobot_ has quit [Quit: cyal8r]
infobot has joined #neo900
nox- has quit [Quit: Leaving]
norly has joined #neo900
norly has quit [Quit: Leaving.]
vakkov has joined #neo900
ashneo76 has quit [Ping timeout: 252 seconds]
ashneo76 has joined #neo900
vakkov_ has joined #neo900
vakkov has quit [Ping timeout: 245 seconds]
wicket64 has quit [Remote host closed the connection]
vakkov_ has quit [Ping timeout: 252 seconds]
vakkov_ has joined #neo900
Pali has joined #neo900
SylvieLorxu has joined #neo900
sparetire has quit [Quit: sparetire]
<DocScrutinizer05>
freemangordon: didn't we discuss Jazelle any time during last year? I now see why Jazelle is not ever used: >> The Cortex-A8 processor provides a trivial implementation of the Jazelle Extension. This means that the processor does not accelerate the execution of any bytecodes, and all bytecodes are executed by software routines.<<
<Wizzup>
kerio: I also still have two lying around ;)
<freemangordon>
DocScrutinizer05: check the last log on #harmattan
<kerio>
oh man, the beagleboard c is a beast
<kerio>
*beagleboard black
<Wizzup>
well.. depends on your viewpoint
<Wizzup>
There are much more powerful arm [dev boards|phones] out there, I think
<Wizzup>
but nevertheless it's nice
<kerio>
Wizzup: like what?
<kerio>
the beaglebone black costs slightly more than a rPi as well
<Wizzup>
kerio: tegra K1, recent odroids, ifc6410 (and newer ifc6540 or something), and more
<Wizzup>
but it's perhaps a bit OT
<kerio>
hoooooooooooooooooooly shit that costs 250$
<Wizzup>
the ifc6540 you mean?
<kerio>
yes
<Wizzup>
the ifc6410 was 75 when I got it, odroid is similar
<Wizzup>
tetra is 192, one dollar for every CUDA core
<Wizzup>
tegra k1*
norly has joined #neo900
arcean has joined #neo900
<freemangordon>
DocScrutinizer05: I'll wait for coderus to provide the bootrom
<freemangordon>
in the meanwhile I am trying to boot maemo with 3.19
<DocScrutinizer05>
:-)
<DocScrutinizer05>
however, bootrom is not really relevant for us, we neither can change it nor is it supposed to contain any RAM init. That's done by xLoader instead
<freemangordon>
actually it contains the CHxxxx sections :)
<freemangordon>
at least on n900
<DocScrutinizer05>
BR only initializes on-chip SRAM
<freemangordon>
see 26.4.8.2.2 CHRAM in TRM
<DocScrutinizer05>
BR is flashed by chip manuf at production time
<freemangordon>
this CHRAM section is in the bootrom on n900
<freemangordon>
and I bet it is the same on N9
<DocScrutinizer05>
when BOOTROM would initialize DRAM, why would we need any xLoader?
<DocScrutinizer05>
I dunno what's CHRAM (I dunno the TRM by heart, and I don't know which of the ~30 TRM I got locally here you're referring to), but I suspect it's about SRAM
<freemangordon>
"The CHRAM configuration header contains settings specific to SDRAM memory controller (SDRC)."
<freemangordon>
so at least it contains some safe defualts
<freemangordon>
*defaults
<DocScrutinizer05>
awell, how could that be when the whole SoC neither TI have any idea about that SDRAM at time of flashing BOOTROM?
<DocScrutinizer05>
mind that SDRAM is attached to SoC during production of device, not at time of SoC getting BOOTROM flashed(? if not mask programmed) at TI fab
<freemangordon>
dunno, but this is what I see in the code :)
<DocScrutinizer05>
"...settings specific to SDRAM memory controller (SDRC)." may mean "save defaults for resetting the thing to inactive state"
<DocScrutinizer05>
you don't hope for hardware to wake up in a sane state, you want to make sure early in boot that everything is powered down, configured at hifg-Z or input for GPIOs, proper lowest clock rate for clock generators etc
<DocScrutinizer05>
maybe it's fatal for your device to run at undefined clock speeds etc for >10ms, unless your fan etc would already act as defined in thermal management SOFTWARE(!!!)
<freemangordon>
anyway, the problem seems more like HW related than SW
<DocScrutinizer05>
yes, in the end it's clearly a hw problem since we can't do *anything* in sw to make xloader run more stable
<DocScrutinizer05>
unless xloader does some init to e.g. SDRC tha's so catastrophically wrong that it kills off CPU and SRAM
che11 has joined #neo900
<DocScrutinizer05>
Nik answered to my similar comments: >> I think the conclusion that it *must* be a hw issue is too fast (it still can). X-Loader initializes something (NAND + MMC + SDRAM) *before* becoming active on UART.<< but that still doesn't explain to me how it may stall on doing so
<DocScrutinizer05>
freemangordon: that is what Nik pointed me to right after his above quoted comment
paulk-aldrin has joined #neo900
<DocScrutinizer05>
umm, my above staements actually assume a perfect bugfree xLoader. That _might_ not be realistic ;-P Maybe xLoader actually does something wrong only when detecting DM3730 and a SDRAM of 1GB size and/or NAND of 512MB size
<DocScrutinizer05>
it might read an uninitialized var and use the value of that for some conditional branch which then would fail at random
<DocScrutinizer05>
or similar failure pattern
* DocScrutinizer05
idly wonders if an uninitialized IRQ triggered by e.g. SDRC may cause the xloader to go south at random times and locations in code, depending on whatever the freewheeling SDRC does until it emits such IRQ
arcean has quit [Ping timeout: 244 seconds]
<DocScrutinizer05>
just think refresh, which might run into trouble at arbitrary point in time, depending on configuration (mem range, nr of banks etc) and starting point of refresh counter register. Not saying that SDRC actually does any refresh on SDRAM LPDDR, iirc the chip itself does that. but maybe it also needs some config for _how_ to do refresh, and when that's not configured propperly, eventually the RAM chip may send whatever error signal to
<DocScrutinizer05>
SDRC which in turm sends an IRQ to xLoader which doesn't have any servincing routine vector set up for that IRQ
<freemangordon>
DocScrutinizer05: all vectors point to dead loops on exit from the BR
<DocScrutinizer05>
garbled return address on stack?
<freemangordon>
the return address is not on stack, but in LR
<DocScrutinizer05>
ooh
<DocScrutinizer05>
sorry
<freemangordon>
Pali: is there some trickery when you use mutex in .ko?
<Pali>
I do not know anything
<Pali>
maybe problem is in fsg_alloc_inst?
<freemangordon>
oh, wait, that mutex is right after func_list
<DocScrutinizer05>
suggestion: printf LR before return.
<freemangordon>
already done
<freemangordon>
(16,00,38) Pali: printk before return is printed correctly, but crash dump is in try_get_usb_function_instance function
<DocScrutinizer05>
didn't think he printed LR
<Pali>
no I did not printed LR
<freemangordon>
Pali: you can attach debugger, correct?
<Pali>
I could
<freemangordon>
could you verify what happens with func_lock, I suspect it is being overwritten
<DocScrutinizer05>
dang, those ARM cores and all their registers. I always forgot the details same evening after learning them during daywork
<Pali>
looks like attaching debugger is not easy :-(
<Pali>
I do not know offset where is loaded kernel
<Pali>
so I cannot add break points
MonkeyofDoom has joined #neo900
MonkeyofDoom has quit [Read error: Connection reset by peer]
MonkeyofDoom has joined #neo900
<freemangordon>
Pali: "reboot request received from pid 1416: dsmetool" any idea?
<Pali>
somebody called dsmetool to reboot device
<freemangordon>
when I boot in KP, /var/lib/dsme/saved_state is user
<Pali>
reboot command in CSSU is doing that too
<freemangordon>
oh
<freemangordon>
but it was not like that 5 minutes ago
<freemangordon>
could it be that getbootstate?
<Pali>
getbootstate? no it does not call dsmetool
<freemangordon>
but who calls it then? dammit :(
<freemangordon>
therere is nothing in the logs
<Pali>
telinit? reboot?
<freemangordon>
but it is not booted
<freemangordon>
that is why I suspect getbootstate
<freemangordon>
i rebooted or did a poweroff with charger attached, I remember there was some problem
vakkov has quit [*.net *.split]
ashneo76 has quit [*.net *.split]
varu|zZz has quit [*.net *.split]
deafboy has quit [*.net *.split]
vakkov has joined #neo900
deafboy has joined #neo900
varu|zZz has joined #neo900
ashneo76 has joined #neo900
<DocScrutinizer05>
dsme could reboot when any controlled process exceeds restart linit
<freemangordon>
the device is in RD mode
<DocScrutinizer05>
that's basically one of the major purposes of dsme
<DocScrutinizer05>
hmm, then prolly not
mvaenskae has joined #neo900
<freemangordon>
wait, what? it booted with a charger attached?!?
<freemangordon>
Pali: ^^^
<freemangordon>
oh, well, I did depmod -a, that might be it
<Pali>
"reboot request received from pid 1416: dsmetool" means that external process with name "dsmetool" asked dsme daemon to do regular device reboot
<freemangordon>
yes, I know
<freemangordon>
but the question is who and why?
<Pali>
it is controlled reboot
<freemangordon>
:nod:
<Pali>
grep 'dsmetool -b' -R /
<Pali>
or what
<freemangordon>
anyway, it booted now
<Pali>
and check which binary can call that command
<Pali>
I only know that in CSSU is reboot and telinit (number reboot) mapped to dsmetool -b
<Pali>
(-b is reboot)
<Pali>
so again need to check which process can call "reboot" or "telinit" command...
<MonkeyofDoom>
Pali: I don't mean to bother, but is there a guide/couple-line-instructions somewhere for building the upstream kernel for N900?
<Pali>
freemangordon: it is not g_nokia.ko related
<Pali>
any gadget crash
<Pali>
MonkeyofDoom: elinux.org/N900
<freemangordon>
Pali: ok. will see
<MonkeyofDoom>
does any of that apply to linus's 3.19 tree, or just the n900 3.13-tree there?
<Pali>
there are no specific instructions
<Pali>
just compile kernel as normal...
<MonkeyofDoom>
I ended up fumbling with omap2plus_defconfig which handed me a 100M kernel, so obviously I have no idea what I'm doing :x
<Pali>
if you are using n900 tree, then you can use prepared rx51_defconfig file
<Pali>
(which is in git)
<Pali>
also you can copy that defconfig file to mainline linus tree and use it
<MonkeyofDoom>
ah, I didn't know if that was a sane thing to do
<MonkeyofDoom>
thank you
<DocScrutinizer05>
freemangordon: Pali: (@all:) Nik boted up Linux on 1GB BB-xM. Alas the system/kernel DT has 512MB RAM only
<DocScrutinizer05>
booted*
<DocScrutinizer05>
>> Linux has booted after disabling the NAND init code in MLO. With 512 MB RAM (because that is configured into the device tree).<<
<freemangordon>
yeah :D
<Pali>
need to edit DT
<DocScrutinizer05>
yup
<freemangordon>
I guess this is the easy part
<DocScrutinizer05>
and fix the NAND stuff
<Pali>
and also uboot
<Pali>
DocScrutinizer05: nand or onenand?
<freemangordon>
DocScrutinizer05: the same device that was failing yesterday?
<DocScrutinizer05>
prolly OneNAND, no?
<DocScrutinizer05>
freemangordon: yep
<Pali>
in uboot there is nand driver and onenand driver
<Pali>
need to use correct one!
<DocScrutinizer05>
Pali: the bug is in MLO
<Pali>
so yes, disable nand init code and enable onenand init code
<Pali>
MLO == XLoader?
<DocScrutinizer05>
xLoader/MLO stalls when trying to init NAND
<Pali>
uboot spl (= replacement for xloader) does not have onenand support yet, only nand
<DocScrutinizer05>
>>I have just added #undef CONFIG_NAND to the GTA04 MLO code [...] The interesting thing in this phase is that I now always get the “Texas Instruments X-Loader (MLO) 1.4.4ss…” message. On 100% of the resets.<<
<Pali>
CONFIG_NAND is nand and CONFIG_ONENAND is onenand
<Pali>
make sure you use correct driver!
<DocScrutinizer05>
to avoid misconceptions: I'm quoting mails from Nikolaus
<DocScrutinizer05>
>> So the problem is the NAND interface. And that might need a different config than it is currently using (because the original BB XM has no NAND).<<
<freemangordon>
Pali: the first call to usb_get_function_instance leads to device reset
<freemangordon>
as if the list and the mutex are in a wrong section
<DocScrutinizer05>
maybe one of you guys could check what type of NAND the N9 actually uses?
<DocScrutinizer05>
I'd love to see a BB-xM with our KCE00E00CA run a 1GB RAM and 512MB NAND
<DocScrutinizer05>
..before I consider securing production quantities of the KCE00E00CA
<DocScrutinizer05>
our problem stays same it was before: we have no datasheets for KCE00E00CA
<DocScrutinizer05>
zilch
<DocScrutinizer05>
so the answer "please check N9! to question "NAND or OneNAND?" is what we earned from using a chip we can't get docs for, and it's way better than worst case (when e.g. using a PN544 NFC chip for which we also couldn't find datasheets but no "check N9" answer possible)
<freemangordon>
Machine: Nokia RM-696 board == N9?
<DocScrutinizer05>
!GB-RAM+512MB-NAND PoP chip
<DocScrutinizer05>
1
<Pali>
RM-696 is N9 and RM-680 is N950
<DocScrutinizer05>
yep
<freemangordon>
ok, so this is the correct dmesg log
<mvaenskae>
the neo900 will be sooo fun to have :)
che11 has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
:-D
<DocScrutinizer05>
>>Linux has booted after disabling the NAND init code in MLO. With 512 MB RAM (because that is configured into the device tree).
<DocScrutinizer05>
Ethernet works, USB works. LEDs are blinking. ssh over Ethernet works. apt-get update/upgrade does not fail (which I hope is testing the RAM well enough).<<
<DocScrutinizer05>
to get a SD card that should directly boot 3.19-rc7 on the other BB XM in your possession.
<DocScrutinizer05>
<<
<DocScrutinizer05>
note I'm not *really* a sw-developer ;-)
<DocScrutinizer05>
I'm however sure Nik will appreciate any patch you send to him
<freemangordon>
DocScrutinizer05: neither do I possess BB-XM :)
<DocScrutinizer05>
well, adding this warning to the patch will do, I guess
<DocScrutinizer05>
freemangordon: I also have no BB-xM with 1GB RAM for now. There's only one such board on this globe for now: Munich, GDC
<DocScrutinizer05>
sufficiently similar hw platform though: Nokia N9 ;-P
<DocScrutinizer05>
though unsigned MLO on that one will bail out I guess
<DocScrutinizer05>
but we're not talking MLO but rather linux DT here
<freemangordon>
yep, it is linux DT
<DocScrutinizer05>
Nik is aware DT needs patching (of course). It just might help providing those patches so he doesn't need to do that work himself, and you could earn some eternal fame for participating in bringing up Neo900 ;-D
<DocScrutinizer05>
eventually one of the 1GB BB-xM will move to your location so you can test maemo on it
<DocScrutinizer05>
maybe already with Neo900 dummy attached
<DocScrutinizer05>
well, "dummy", or rather SoC-less eval proto
<DocScrutinizer05>
anyway, o/ bbl
fling has quit [Quit: leaving]
<freemangordon>
Pali: can a function in module be __init declared?
* DocScrutinizer05
tries parsing
trx has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
can a function be declared in module __init? ? ?
<freemangordon>
ok, if you say so :)
<DocScrutinizer05>
I dunno, it has a different semantics
<DocScrutinizer05>
I just dunno the term "__init declared"
<DocScrutinizer05>
maybe it means some special way of declaration
<freemangordon>
yep
<DocScrutinizer05>
so "can a function get __init-declared, in a module?"
<freemangordon>
ok
<DocScrutinizer05>
aah, it's a compiler hint. Well why shouldn't it work for .ko?
<DocScrutinizer05>
when it doesn't work, it at least won't hurt, eh?
<freemangordon>
this places the code/data in different sections
<DocScrutinizer05>
yes, and when it does, thus should be valid thing to do. Otherwise compiler should reject or discard it
<DocScrutinizer05>
aiui the memchunk allocated for __init stuff will get free()ed after module/process initialization completed
<DocScrutinizer05>
anyway I don't see why it wouldn't work for modules (that's been your question, right?)
modem has joined #neo900
modem has quit [Changing host]
modem has joined #neo900
<freemangordon>
DocScrutinizer05: yep
<DocScrutinizer05>
for sure tricky to not accidentally __init something that's needed _after_ initialization completed
<DocScrutinizer05>
resp tricky to find the error in case you did
<DocScrutinizer05>
you think the var is still there, it got properly initialized before you use it, and yet when you access it now you get a segfault for accessing memory not in your address space
<DocScrutinizer05>
;-) does that error description sound familiar?
<freemangordon>
no :)
<freemangordon>
the problem is elsewhere
<DocScrutinizer05>
nice test case for debuggers and in-circuit emulators
<DocScrutinizer05>
one of the cases of "it returms 3 for me asking "1+1" but when I attach debugger it simply segfaults in the middle of nowhere"
<paulk-aldrin>
DocScrutinizer05, hey, do you know if upstream Linux reconfigures SDRC with fine dram config values?
<paulk-aldrin>
(on omap3)
<paulk-aldrin>
the device I'm working on (lg optimus black/p970) has that in the android kernel
<paulk-aldrin>
so I use "generic" hynix configuration in u-boot, which works fine and then it gets configured to optimized values
<paulk-aldrin>
but I'm worried that it would still use the generic configuration with mainline
<paulk-aldrin>
i.e. no reconfiguration
<freemangordon>
Pali: almost there, removing __init and __exit makes g_nokia working :)
<freemangordon>
just want to check if any of those could be kept
fling has joined #neo900
<Pali>
freemangordon: __init declaration for function means it is used only at init stage, after that function is freed from memory
<freemangordon>
Pali: yeah, thought as much, the point is - why it is a problem for g_nokia?
<freemangordon>
and most probably for the other g_ modules
<Pali>
modprobe g_mass_storage crash too
<freemangordon>
Pali: remove __ init from the bind function
<freemangordon>
:)
<Pali>
ok, will look at it later... now afk
<freemangordon>
me too
che11 has joined #neo900
che11 has quit [Ping timeout: 265 seconds]
bencoh has quit [Changing host]
bencoh has joined #neo900
arcean_ has joined #neo900
arcean has quit [Ping timeout: 246 seconds]
mvaenskae has quit [Ping timeout: 246 seconds]
sparetire has joined #neo900
arossdotme has quit [Ping timeout: 264 seconds]
arossdotme has joined #neo900
norly has joined #neo900
ChanServ has quit [shutting down]
ChanServ has joined #neo900
modem has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
__init bind? maks no sense since you want to keep binding
<freemangordon>
DocScrutinizer05: bind as the function bind_xxxxx
paulk-aldrin has quit [Quit: Quitte]
<Pali>
I looked at that code and I think *all* gadget modules should *not* have __init in that bind_* functions