Open quasar1 opened 9 years ago
My answer is yes, not sure where to start.
I have a branch where I managed to get a newer toolchain compiled which appeared to work but the Boxee would not load XBMC/Kodi it produced. https://github.com/quasar1/boxeebox-xbmc/tree/toolchain1/tools/boxeebox/toolchain I presume the Boxee's outdated loader 'Glibc' is still active so that's the cause. Might be worth investigating the logs it produces when it fails to load, I can provide them for inspection.
It's worth trying, not sure how far we can get.
FYI just pushed https://github.com/quarnster/boxeebox-intel-sdk which builds many of the drivers from the boxeebox's intel sdk, with a gcc 4.9.2 toolchain. Replacing all the intel drivers built by this works fine, but updating to glibc on the boxeebox doesn't appear to work for some reason. I don't know why, but since the new libs works with the old glibc without issue maybe that's not such a big deal?
Haven't tried compiling the full kodi and libs with this version of the toolchain.
@quarnster amazing work, as usual. I had a quick look, you are using kernel 2.6.28, I guess we need that until such times as we can get kexec working with a newer kernel? Will those drivers work with a newer kernel, say 3.x ?
Here's an old bt.2018 output when it crashed loading Kodi with my toolchain changes. http://pastebin.com/5nanxwVF
Don't know what the backwards compatibility is with newer kernels so can't comment on that. Worst case they'll have to be recompiled with the new kernel headers, but now we are getting ahead of ourselves, someone needs to figure out how to boot a custom kernel first.
my chaotic lateral thinking for you... :)
So can someone comment on what we need to be actively pursuing to attain this goal? I presume we need compatible compiled kernel/drivers which need to be loaded on the boxee with kexec? It looks to be a similar setup to what the hackintosh scene are doing. Altering the OSX kernel to boot on other systems. Only in this case jump the altered kernel in front of the existing one some how?
I guess this has gone off the boil now, oh well.. Que Sera ...
quarnster, a ways back you had sent me code for that "verify" script and were doing work on the bootloader - any progress there?
@orizzle Nope, and I'm probably not going to look at it again.
@quarnster where do we move from here or this basically dead?
@orizzle I'd consider it dead until proven otherwise
I was wondering, has there been any updates around this topic?
I've done a bit of digging on the kexec approach recently (after I finally got my hands on a rev A2 box), but I was not able to make it work.
I based my experiments on amonakov/kexec-module and adjusted it for BoxeeBox. I've added debug printouts in kexec.c
and I know it reaches the machine_kexec()
function, but then it just hangs:
# /mnt/3227-7733/run_kexec.sh
+ echo 7
+ readlink -f -- /mnt/3227-7733/run_kexec.sh
+ dirname /tmp/mnt/3227-7733/run_kexec.sh
+ dir=/tmp/mnt/3227-7733
+ insmod /tmp/mnt/3227-7733/kexec-mod.ko
[ 85.472823] kexec module loaded
+ LD_PRELOAD=/tmp/mnt/3227-7733/redir.so /tmp/mnt/3227-7733/kexec -l /tmp/mnt/3227-7733/bzImage --reuse-cmdline
[ 85.711433] kimage_load_normal_segment - result: 0
[ 85.716278] kimage_load_normal_segment - result: 0
[ 85.726349] kimage_load_normal_segment - result: 0
+ LD_PRELOAD=/tmp/mnt/3227-7733/redir.so /tmp/mnt/3227-7733/kexec -e
[ 86.137834] kernel_kexec - 1
[ 86.140941] kernel_kexec - 2
[ 86.143952] kernel_kexec - 4
[ 86.147298] Starting new kernel
[ 86.147816] kernel_kexec - 5 @ cfb05000
I even tried to copy the machine_kexec()
function and make it a static function in my kernel module. Then it hung on relocate_kernel()
somewhere. My x86 assembly is not the best, so I will stop my investigation here.
I tried :slightly_smiling_face:
http://boxeed.in/forums/viewtopic.php?f=13&t=1273 Inviting Orizzle to continue the above thread here as I don't have forum access (by choice).
Orizzle wrote: