<Wizzup>
I think that is the order we built the packages in, over time we usually append packages at the bottom, so dependency wise it should mostly work out
<Wizzup>
oh, shit, parazyd already linked that
<Wizzup>
sorry.
<marex>
parazyd: Wizzup: thanks
stano has joined #maemo-leste
<stano>
anybody know what happened to Oliver McFadden? He presented quake3 on N900 at Maemo Summit Amsterdam, 2009
rafael2k has joined #maemo-leste
<Wizzup>
marex: let us know if you have any questions/problems, happy to help
<uvos>
indeed
<marex>
I will give it a go and ask if I get stuck, not sure when, but at some point I will
rafael2k has quit [Ping timeout: 252 seconds]
mrgeanie8 has joined #maemo-leste
mrgeanie has quit [Ping timeout: 265 seconds]
mrgeanie8 is now known as mrgeanie
sunshavi has quit [Ping timeout: 265 seconds]
sunshavi has joined #maemo-leste
Kabouik_ has joined #maemo-leste
jesster1234_ has joined #maemo-leste
lexik_ has joined #maemo-leste
Kabouik has quit [Ping timeout: 255 seconds]
crab has quit [Ping timeout: 255 seconds]
amk has quit [Ping timeout: 255 seconds]
R0b0t1 has quit [Ping timeout: 255 seconds]
mrkrisprolls has quit [Ping timeout: 255 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
jesster1234 has quit [Ping timeout: 255 seconds]
lexik has quit [Ping timeout: 255 seconds]
crab has joined #maemo-leste
R0b0t1 has joined #maemo-leste
amk has joined #maemo-leste
elastic_dog has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
diejuse has joined #maemo-leste
inetdragon has joined #maemo-leste
R0b0t1 has quit [Ping timeout: 255 seconds]
rafael2k has joined #maemo-leste
rafael2k has quit [Ping timeout: 250 seconds]
inetdragon has quit [Quit: Client closed]
R0b0t1 has joined #maemo-leste
lexik_ has quit [Quit: Bella ciao.]
lexik has joined #maemo-leste
lexik has quit [Client Quit]
lexik has joined #maemo-leste
RedW has quit [Quit: huh upgrades]
<Wizzup>
uvos: so I guess for safestrap, it looks like you need to provide it with your own kexec modules and such
<Wizzup>
uvos: at least looking at the ddroid I linked earlier today
<uvos>
Wizzup: ah yeah
<uvos>
on /system no?
<uvos>
thats really stupid design, this is also why they had to boot the 3.0 kernel on d3
xmn has joined #maemo-leste
<uvos>
because ofc they dont want to have to include a bounch of moudles for various kernels
<uvos>
so just pilfer the modules from los then
<Wizzup>
I installed safestrap 2.10, just now, as it seems to use the android kernel, btw:
<Wizzup>
Linux localhost 2.6.35.7-g5fa4155 #1 SMP PREEMPT Fri Feb 24 22:09:47 CST 2012 armv7l GNU/Linux
<uvos>
yeah thats how safestrap works on d4/bionic with kern 3.0
<uvos>
Wizzup: thats good, since you have to kexec from this kernel in the end
<uvos>
(2.6)
<Wizzup>
yes, so maybe I can make the kexec work this time
<Wizzup>
uvos: do you know when --command-line=string is passed to kexec, when you load the kernel, or when you use kexec -e ?
<Wizzup>
I assume the former
<uvos>
former
<uvos>
kexec -e is just thtat
<uvos>
*that
<Wizzup>
ok
<Wizzup>
hard to debug this kind of tsuff :)
<uvos>
Wizzup: i had to compile a newer version of kexec to boot mainline btw
<Wizzup>
hm, of the binary?
<uvos>
yeah
<Wizzup>
do you have that binary somewhere? clownboot?
<uvos>
clownboot contains the binary yeah
<uvos>
the new kexec cant boot kernel 3.0 either
<uvos>
so it dosent work both ways
<uvos>
kexecboot also contains both for this reason
<Wizzup>
ok, but I want to boot mainline
<Wizzup>
so on my old kernel, I should be able to use your new binary and hopefully have something working?
<uvos>
i hope so
<uvos>
but depending on how i compiled it
<uvos>
it might not run on andoid 2.3
inky has quit [Ping timeout: 250 seconds]
<Wizzup>
it starts at least
<uvos>
nice : ), define starts
<Wizzup>
no, sorry
<Wizzup>
kexec runs
<Wizzup>
the binary
<Wizzup>
working on it
<Wizzup>
really annoying that you have to load uart.ko for the kexec modules to load :/
<uvos>
yes
<Wizzup>
makes it impossible to see if/where it fails
<uvos>
but that was the only way the kexec module could be debugged
<Wizzup>
mhm
<uvos>
well you have to redeirect the output to a file and examine it later
inky has joined #maemo-leste
<uvos>
bu yeah i messed with this a for several hours before clownboot worked
<Wizzup>
does your kexec module support --devtree ?
<Wizzup>
uvos: btw, if you have other ideas if I can't get anything on serial either (why kernel maybe won't boot), wouldn't mind hearing it
<Wizzup>
(getting serial in an hour or so)
<Wizzup>
I think I set up the memory region correctly
<Wizzup>
I could try to have a kernel with powervr too if that's somehow causing trouble
<Wizzup>
although I don't think safestrap sets up pvr
<uvos>
well safestrap on d4 and i guess safestrap 2.x runs after the android userspace has booted part way
<uvos>
so if safestrap dose it or not is a moot point
<Wizzup>
do you think android inits it before then?
<uvos>
i would leave pvr out
<Wizzup>
ok
<uvos>
Wizzup: on bionic yes
<uvos>
anyhow you dont want pvr anyhow
<Wizzup>
for clown boot you mean?
<uvos>
since your trying to create a kernel for clown boot anyhow
<Wizzup>
I was also just trying to get it to boot anything
<uvos>
the kernel you create is never suposed to boot leste anyhow
<uvos>
but kexecboot
<Wizzup>
hm
<Wizzup>
I mean, ultimately, yes, but seeing anything like kernel starting would already be progress
<uvos>
sure
<Wizzup>
the zImage-static is 7.3M btw
<uvos>
if you dont get anything on serial that would be akward, since serial output should start so early that the kernel hasent messed with anything yet except the omap
<Wizzup>
let me check if I have earlyprintk in my cmdline (will check in 30 mins)
<Wizzup>
I took the cmdline from the boot.cfg for the bionic
<uvos>
so i dont really see how the device could fail that early
<Wizzup>
maybe I just missed it on serial
<Wizzup>
we'll know soon
<uvos>
i mean you must at least see the debug output
<uvos>
from kexec.ko
<uvos>
Help im alive!
<Wizzup>
do you mean when safestrap starts, or when I run my kexec attempt?
<uvos>
the kexec attempt
<Wizzup>
ok, let me try to catch that
<uvos>
kexec.ko prints the above line
<uvos>
and some other info
<uvos>
if you dont see that your serial setup or kexec is not working
<Wizzup>
so 'Help I am alive' is from kexec before it does final kexec call?
<uvos>
yes
<Wizzup>
check
<uvos>
or rather thats the first print in the kexec sequence in kexec.ko
<uvos>
you should see all the printascii() commands here
<uvos>
so the last thing should be printascii("Switch stack\n"); i
<Wizzup>
ok
<Wizzup>
the kexec modules I use are pulled from safestrap 3.x' boot mechanism, and they load just fine in safestrap 2 (which makes sense, since it uses the standard kernel)
<Wizzup>
jfyi, that should be fine
<uvos>
yeah
<Wizzup>
ok, back in 20 mins, should have serial then
<uvos>
btw you sould also feal i vibrate on kexec
<uvos>
the litte vibration the d4 makes wen you boot somehting in kexecboot
<uvos>
thats also kexec.ko
<uvos>
somehow
<uvos>
not sure where the code for this is actually
diejuse1 has quit [Ping timeout: 255 seconds]
<tmlind>
we should just go through the pain to strip down the kexec module to bare minimum for the old kernels and leave out the serial port support, it might even make it more reliable for booting..
<Wizzup>
uvos: hm: syscall kexec_file_load not available.
<Wizzup>
so maybe your kexec is too new?
<Wizzup>
ls
<Wizzup>
uvos: do you recall why you had to compile a newer kexec binary for mainline?
<Wizzup>
with the old kexec userspace I see this as last msgs:
<Wizzup>
Switch mm
<Wizzup>
Switch stack
<Wizzup>
ABE
<Wizzup>
and then nothing happens
<Wizzup>
uvos: using your kexec I only see the "Help I'm alive" but never the kexec, so that makes sense, given the kexec_file_load not being available
<Wizzup>
so I guess the next steps would be to debug why the kexec with old userspace kexec fails to do anything, or to load newer safestrap again and try los/cm, to see how their kexec methods work
<Wizzup>
uvos: lol EARLY_PRINTK is not on
<Wizzup>
uvos: anything I need to do besides DEBUG_LL and EARLY_PRINTK ?
<uvos>
Wizzup: i compiled newer kexec using the android 4.0 sdk because the old one dident work for me
<uvos>
bescily
<Wizzup>
(I see something regarding physical base address of debug uart)
<uvos>
its just something i tried
<Wizzup>
uvos: ok, but I mean, how did it not work, did it corrupt the kernel when loading or something?
<uvos>
when it dident want to boot
<Wizzup>
ok
<uvos>
it failed pre final kexec stage
<Wizzup>
because it looks to me like the kexec userspace I have at least seems to load and attempt to boot, not sure if it does it correctly
<uvos>
no sure either
<Wizzup>
too bad
<uvos>
tmlind: ^^^^
<uvos>
he might know
<uvos>
since kexecboot dose the same thing
<uvos>
(different kexec binary for old vs new kernels)
<Wizzup>
uvos: hmm so I think your kexec binary also works (maybe it has a fallback to older syscall)
<Wizzup>
uvos: yeah so both kexec userspace seem to do something (trigger the whole thing)
<uvos>
ABE comes after Switch stack
<uvos>
i just missed it earlyer
<Wizzup>
ok, right
<uvos>
so the sequence on a bionic looks like this:
<Wizzup>
I mean mostly that nothing comes after it :p
<uvos>
Help I'm alive
<uvos>
Disable IRQ's
<uvos>
Kern restart prepare
<uvos>
Machine shutdown
<uvos>
Machine kexec
<uvos>
Disable IRQ's
<uvos>
va: dfb59000
<uvos>
pa: 9fb59000
<uvos>
Bye!
<uvos>
Flush Icache
<uvos>
L2X0 Access
<uvos>
L2X0 Disable
<uvos>
Switch mm
<uvos>
Switch stack
<uvos>
ABE
<uvos>
[ 0.000000] Booting Linux on physical CPU 0x0
<uvos>
so the 2.6 kernel is sucessfully kexecing
<uvos>
and then the mainline kernel fails to take over
<Wizzup>
I see the same, but not the kernel msg
<Wizzup>
yeah
<uvos>
thats not what i saw with old kexec on bionic
<uvos>
it failed somewhere else
<uvos>
before bye!
<Wizzup>
ok
<uvos>
maybe cpacp is connected to a different uart
<uvos>
(the cpcap multiplexer)
<Wizzup>
btw I see the same, except for va/pa, they are different numbers
<Wizzup>
va: da93a000
<Wizzup>
pa: 9a93a000
<uvos>
so the mainline kernel is printing somewhere else
<uvos>
(maybe)
<uvos>
pa is probubly physical / virutal address
<uvos>
for the kernel image
<uvos>
so should not matter
<uvos>
both look like they are in ram
<uvos>
somewhere
<Wizzup>
ok, well, I don't see anything on serial with earlyprintk in cmdline and also enabled in kernel
<uvos>
i wish kernel_kexec_modules had acually usefull commits....
<Wizzup>
your hunch on the kernel writing to the wrong place, I guess that is something that can maybe be verified with the kernel src, or on a running system even?
<Wizzup>
I suppose I could try to kexec the existing kernel just to see what happens, too
<uvos>
thats not it
<uvos>
since the uart.ko module writes to uart3
<uvos>
and so dose mainline
<Wizzup>
ok
<uvos>
so i would go diff the motorla sources now but there are like 3 changes specific to solana total
<uvos>
so that seams not helpfull
<uvos>
so next would be dts
<Wizzup>
as in, three is very few?
<Wizzup>
should I try to boot the existing android kernel via kexec first, just to see if that works / does something?
<uvos>
also they are not in places you would expect boot failure
<uvos>
just periferals
<uvos>
next would be to check stock kernel dts against bionic
<tmlind>
Wizzup: so i've been using three patches for the kexec for the v3.0.8 kernel if you're rebuilding them
<uvos>
but those where decompiled from i think (right tmlind?) idk how to do that tmlind and sre just gave me the dts for both bionic and d4.
<uvos>
*decompiled from dtb on device
<uvos>
for the stock kernel
jk__000 has quit [Ping timeout: 252 seconds]
crab has quit [Quit: WeeChat 3.0]
<Wizzup>
tmlind: I am using the kexec kernel modules from safestrap 3.x for the droid3, from the android kernel (safestrap 2 loaded). I also tried to kexec from safestrap 3, which has the 3.x kernel (probably 3.0.8), but could not find kexec modules for it
<tmlind>
yeah i used to have a patch to do the endian swap for dtc to decompile but lost it..
crab has joined #maemo-leste
<uvos>
yeah i gues we need to repo that next
<uvos>
if nothing else gives
<tmlind>
Wizzup: old kexec did not understand the size at least
crab has quit [Client Quit]
<Wizzup>
tmlind: old kexec binary, that is?
<tmlind>
Wizzup: kernel kexec too, it is now passing the zImage uncompressed size in the image
<Wizzup>
aha, that could cause some issues..
<Wizzup>
does it make sense to pass an uncompressed kernel as a test?
crab has joined #maemo-leste
<Wizzup>
I suppose it's better to just get on the same kernel and patches as what we have working
<tmlind>
notkit did some patches to build the kernel with gcc6 i think, so now it would be possible to in theory to build them with buildroot
<tmlind>
uvos: you are probably passing the imaginary --size parameter to kexec?
<uvos>
let me check
<uvos>
no
<uvos>
hmm
<uvos>
maybe best not to look at it to hard
<tmlind>
uvos: i'd assume at least 0003-Fix-to-support-mainline-kexec-dtb.patch is needed?
<marex>
freemangordon: Pali: you might want to follow up on the u-boot rx51 musb stuff
<tmlind>
uvos: so the patched up buildroot droid4-kexecboot uses has the kernel kexec patches applied, but maybe the kernel Wizzup is building does not
<uvos>
tmlind: yeah i know
<uvos>
but the module in clownboot was built by me
<uvos>
based just on the sources from STS-Dev-Team
<uvos>
and it somehow manages to work
<tmlind>
uvos: hmm weird
<uvos>
i guess ill want to pach it when i upgrade the kernel
<uvos>
lest it explode
<tmlind>
uvos: maybe unpatched it works with some different patched up kexec-tools only?
<tmlind>
lots of time wasted with this locked down bs "security" features forcing us to do kexec :(
<uvos>
tmlind: yeah :(
<tmlind>
fake security for device manufacturer, worse security for device owners
<uvos>
also more device sales
<uvos>
because you cant upgrade your own android version
<uvos>
probubly the real reason for this stupidity
<tmlind>
heh just like the bloating battery with the android kernels if left plugged in :)
<tmlind>
hey it produces more battery sales
<uvos>
i think thats just the battery being old and hvlipos not ageing well
<uvos>
but i mean why dose d3 not get android 4 when bionic did? just market segmentation....
<tmlind>
yeah who knows
<tmlind>
uvos: so what's the version of kexec-tools you're using?
<uvos>
not sure any more
<uvos>
id have to check the binary that is actually in the repo against what i have here
<tmlind>
ok, i'm guessing you're using the safestrap kexec binary and that's why it works, but won't work with mainline kexec-tools
<uvos>
i remember trying lots of binarys from safestrap & compiling various versions from source
<uvos>
im not sure what acctually worked anymore rn
<tmlind>
yeah so if you apply the patches i listed, you should be able to use mainline kexec-tools
<uvos>
tmlind: ok thats nice
<tmlind>
and be able to kexec both legacy android kernels and current mainline kernels
<uvos>
ok
<uvos>
d3 hopefully soon gives me a good reason to update clownboot
<tmlind>
ok
<tmlind>
zzz time here, ttyl
<uvos>
ttyl :)
<Wizzup>
b
<Wizzup>
ok... trying to catch up
<Wizzup>
uvos: how do you suggest I continue?
cockroach has joined #maemo-leste
<uvos>
Wizzup: try and patch the 2.6.x kernel_kexec_modules branch as suggested by tmlind
<uvos>
and find a compiler that will compile it
<uvos>
that should be fun
<Wizzup>
ok, I mean I could also go for 3.0.8 that safestrap uses if that's any easier
<Wizzup>
although I guess that means double kexec would be required
<Wizzup>
I guess that's the case anyway, I mean triple
<uvos>
the kernel only allows you to compile it with gcc version it knows
<Wizzup>
oh, right
<Wizzup>
yeah, this is going to be a proper pain
<Wizzup>
lol
<Wizzup>
hm, I am also not passing the atags file
<uvos>
Wizzup: thats not used by modern kernels
<Wizzup>
ok, going to continue another time, it's def. getting more complicated than I hoped
<Wizzup>
to I need to find gcc 4.5, and build the kernel modules from the STS dev team, with tony's patches on top, and then also find newer kexec userspace, right?
<Wizzup>
find/build
inky has quit [Ping timeout: 250 seconds]
<uvos>
clown boot kexec userspace should be fine
<uvos>
if it works
<uvos>
Wizzup: sec i ll compile the modules for you
<Wizzup>
"if it works" is something I've been thinking for aw hile
<Wizzup>
you have gcc 4.5?
<uvos>
yeah
<uvos>
for clownboot ofc
<Wizzup>
wasn't sure if 3.0.8 wanted an older gcc
<uvos>
oh its the same
<Wizzup>
ok
<uvos>
problem is that tmlinds patches dont apply to 2.6
<Wizzup>
ow
<Wizzup>
might take a bit more time to compile then?
<uvos>
yeah i have to rebase the patches
<Wizzup>
ok, I need to do a work thing, I'll try to be back in half an hour or so, hope that's ok
<Wizzup>
(i can postpone it if you think it'll be done quickly)
<Wizzup>
[ 1.439147] 44000000.ocp:L3 Standard Error: MASTER MPU TARGET AES2 (Read Link): At Address: 0x00101080 : Data Access in User mode during Functional access
<uvos>
oh ok
<uvos>
we had that before
<uvos>
some omap co-processor is not in reset after kexec