**** BEGIN LOGGING AT Fri Jul 29 02:59:56 2022 Jul 29 07:23:08 Morning! Jul 29 07:27:15 Morning! Jul 29 12:07:30 morning Jul 29 13:11:23 Tofe: I've cherry picked your moboot commit to my branch. Seems you PR-ed it to yourself ;) Jul 29 13:22:47 ahah, oops :) Jul 29 13:32:13 It was late, the code works anyway though so that's good Jul 29 18:56:06 Herrie: where does the current 4.20 tenderloin defconfig come from? Jul 29 18:59:10 because from what I can see, mbd's 5.7 mainline defconfig looks better (namespace is active, CONFIG_ARCH_MSM is more precisely targetted, etc Jul 29 19:22:42 Tofe: 4.20 defconfig was from QCom Dragonboar which shares CPU Jul 29 19:22:48 So might not be that great Jul 29 19:23:10 We better use the one from mdb98 or lopsided98 Jul 29 19:24:29 Since it differs quite a bit from our TP for some components Jul 29 19:24:56 Also, I've changed UBOOT_ENTRYPOINT = "40208000" and same for loadadress Jul 29 19:25:07 that was the value we had in previous working kernels Jul 29 19:25:37 ah, it doesn't crash at least... but no log, when using mem:// Jul 29 19:25:47 I'll flash it on /boot and retry with moboot Jul 29 19:27:02 Tofe: Yeah we need moboot for logging via serial Jul 29 19:27:23 too bad we can't send something to moboot directly via usb Jul 29 19:29:27 damn ! I get a "[2410] data abort" when checking uImage Jul 29 19:29:41 let's see what this means on GH Jul 29 19:33:47 somehow moboot crashes in there https://github.com/Tofee/moboot/blob/herrie/go/lib/uimage/uimage.c#L234 Jul 29 19:34:07 but it's an exception raised by the CPU, so it's hard to guess what happens... Jul 29 19:35:40 probably an invalid pointer somewhere Jul 29 19:36:36 Tofe: Yeah it would be nice to do that Jul 29 19:36:46 Also a pity they disabled the GPIO from Bootie for TP Jul 29 19:37:43 I wonder, can I build moboot on x86 ? I'd like to run check_image on my uImage... Jul 29 19:39:28 Tofe: No idea really Jul 29 19:39:42 You could add debugging to moboot? Jul 29 19:39:47 Moboot is easy to build in general Jul 29 19:40:04 What about the toolchain ? do I need a gcc-4 ? Jul 29 19:40:09 Tofe: https://github.com/gsora/moboot-pre3 Jul 29 19:40:21 Basically: Download and install: https://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 Jul 29 19:40:27 Puth it in your path and ready to go Jul 29 19:40:43 Ah and apply this patch I guess: https://github.com/gsora/moboot-pre3/commit/cf58c048460379f5b57d199dbc7554ce4904072b Jul 29 19:40:48 Or I did that already, let me see Jul 29 19:41:17 And then simply "make apq-touchpad" Jul 29 19:41:28 I think I'll first try to build a little custom executable that just does check_image Jul 29 19:41:47 should be fairly straightforward, I hope Jul 29 19:42:01 Tofe: Well I got this arm toolchain working on first try too :P Jul 29 19:42:13 And that says something with my "toolchain non-skills" :P Jul 29 19:42:26 Seems I didn't add that patch yet in my branch Jul 29 19:42:35 yes, but then I have to insert traces, build, flash moboot on the TP, reboot, etc Jul 29 19:42:56 though maybe it's faster anyway :p Jul 29 19:43:07 ok, you win, I'll do that first Jul 29 19:44:08 It could be moboot doesn't like the uBoot with DTB in there somehow Jul 29 19:44:10 That's my guess Jul 29 19:44:13 Since it's "too new" Jul 29 19:44:45 well, it shouldn't matter, it should be just a kernel blob for moboot Jul 29 19:47:38 makefile:27: *** No project specified. Use "make projectname" or put "PROJECT := projectname" in local.mk. Jul 29 19:48:05 make apq-touchpad Jul 29 19:48:38 ah, I need the patch, yes Jul 29 19:49:05 Yes I found that in the Pre version of Moboot Jul 29 19:49:08 Pre3 version Jul 29 19:49:11 Seems useful Jul 29 19:49:20 To use a more "standard" toolchain Jul 29 19:49:33 BTW this toolchain is also used for the legacy apps in Preware feeds Jul 29 19:50:07 ok, it builds Jul 29 19:50:39 nope, doesn't link, it doesn't like the space in my pwd :p Jul 29 19:51:34 Tofe: LOL Jul 29 19:51:48 It should be quick Jul 29 19:51:54 It's done here in a few seconds Jul 29 19:52:03 So on your builder should also be quick Jul 29 19:52:48 This is my build log: https://bpa.st/NAVQ Jul 29 19:53:16 yes, it just the space in "/mnt/ubuntu/home/chris/HP TouchPad Tinkering/moboot/moboot" that's driving it crazy Jul 29 19:53:37 ah, diner time, bbl Jul 29 19:53:40 The output uImage is in build-apq-touchpad and called lk.uIamge Jul 29 19:53:44 lk.uImage Jul 29 19:53:48 Late dinner :D Jul 29 19:55:39 Tofe: Easiest solution: Rename the folder ;P Jul 29 20:15:51 looks like my tp is completely dead, after 24 hours of charging still nothing and even the white glow under home button stopped at some point Jul 29 20:19:23 JaMa: Use a 500mAh charger Jul 29 20:19:38 It should bring it back at some point Jul 29 20:20:17 I'm using the original one (which used to work before), but will try to find 500mAh as well Jul 29 20:22:15 found some old suspicious 500mAh, either it will help to charge it or completely destroy it (hopefully without much fire) Jul 29 20:31:36 JaMa: They should be close to indestructable really Jul 29 20:31:50 Deeply discharged sometimes start to behave after some days on trickle charger Jul 29 20:32:03 The old Palm chargers provide 500mAh too Jul 29 20:32:16 There's also a TPDebrick tool, but you need some charge for that I think Jul 29 20:35:05 220V over usb cable will destroy it I think :) Jul 29 20:35:50 JaMa: Yes LOL Jul 29 20:38:01 https://youtu.be/w-p3GXXFfQw?t=780 and my charger I just found looks even more dodgy :) Jul 29 20:41:56 have you tried kirkstone build on qemux86-64 recently? Now it boots with the first-time wizard windowed and I can start more cards, but I cannot switch between them Jul 29 20:42:10 I thought it was my debug build, but now after rebuilding regular build I see the same Jul 29 20:42:42 JaMa: I had mine windowed too Jul 29 20:42:49 I contributed it to waydroid Jul 29 20:42:54 But might be something else Jul 29 20:43:10 I.e. it appeared after some recent changes on Tofe's side Jul 29 20:43:25 https://ibb.co/5nZFm09 Jul 29 20:44:01 I think I started seeing it after https://github.com/webOS-ports/meta-webos-ports/commit/da5eb7385277051897d4cec93d6928a06a57e92a somehow Jul 29 20:45:27 that's the one I've just reverted for test Jul 29 20:46:58 There's nothing really in this commit that should cause it but well Jul 29 20:47:05 Maybe some unwanted side effect Jul 29 21:08:29 I might have made a mistake with the cardshell, of course Jul 29 21:10:27 ok I get a uImage for moboot Jul 29 21:10:33 now let's insert many traces Jul 29 21:14:07 it's not windowed after this revert Jul 29 21:14:50 in first boot it still doesn't work well, but in 2nd and later build it seems to work as before Jul 29 21:15:35 I see some of these in the image with issues in the logs: file:///usr/lib/qml/WebOSCompositor/qml/CardView/CardView.qml:49: ReferenceError: WindowState is not defined Jul 29 21:18:08 Herrie: I think moboot crashes when validating the magic header of the second image in the uImage, i.e. the ramdisk Jul 29 21:18:42 Tofe: We could also let moboot ignore the validation for now? Jul 29 21:19:00 And just boot regardless to see if we get some logs Jul 29 21:19:07 And then fix it when needed later? Jul 29 21:19:09 well if the pointer to the second header isn't valid, it won't be able to unpack it anyway Jul 29 21:24:20 ok, the length of the kernel image is incorrect Jul 29 21:24:37 must be the dtb, I guess Jul 29 21:25:20 moboot sees 7107445, my computer's mkimage sees 7107381 Jul 29 21:25:54 Hmmz weird Jul 29 21:26:06 yes, something is amiss Jul 29 21:26:54 Did you make the uImage with the instructions from Ben? Jul 29 21:27:08 yes, it does the same steps Jul 29 21:27:33 and when I check it with my computer's mkimage and dumpimage, it's all fine Jul 29 21:28:11 I'll double check I have the same uImage on the device and on desktop... Jul 29 21:29:18 same md5sum... Jul 29 21:32:33 Well the DTB should be about 13kb Jul 29 21:32:41 The difference you're seeing is a few bytes Jul 29 21:32:49 yes, it doesn't match Jul 29 21:32:54 64 bytes Jul 29 21:32:58 To be exact Jul 29 21:33:07 Which is a suspicious amounts really Jul 29 21:33:14 looks like some padding Jul 29 21:35:20 maybe there is a padding, and moboot includes it in the size Jul 29 21:35:42 because the second header doesn't looks so wrong, actually. Jul 29 21:36:15 with a length of 4295030, it's exactly the size of my *previous* ramdisk uImage Jul 29 21:36:37 "4295030 29 juil. 20:17 image1" Jul 29 21:40:05 Tofe: Mine is quite close in terms of size: 4.298.660 Jul 29 21:40:17 in my kernel build folder, I have: "chris users 7107445 Jul 29 18:22 uImage" and "chris users 7107381 Jul 29 18:22 zImage-dtb" Jul 29 21:40:26 so, I'm to blame, I guess Jul 29 21:42:02 ooh I'm just stupid Jul 29 21:42:03 Tofe: Well there you have your 64 bytes :P Jul 29 21:42:13 Easy enough to fix then :D Jul 29 21:42:15 64 bytes is just the size of the uImage header Jul 29 21:43:02 yep, file size do match moboot Jul 29 21:43:19 ok so moboot seems actually fine Jul 29 21:43:36 but it still crashes when checking the ramdisk uImage magic header Jul 29 21:48:01 so the size of the ramdisk is fine, but the pointer to the memory content is not valid Jul 29 21:48:26 So is the image corrupt of moboot doesn't know how to deal with it? Jul 29 21:48:50 md5sum did match, so the file in /boot seems correct Jul 29 21:49:11 and my computer's dumpimage did output a correct ramdisk image Jul 29 21:49:22 so it's moboot, somehow Jul 29 21:49:46 must be the "uimage_multi_image" method Jul 29 21:50:37 Tofe: https://code.google.com/archive/p/moboot/issues/20 Jul 29 21:50:41 Sounds similar? Jul 29 21:52:49 well yes, but it's what I do... Jul 29 22:06:31 damn ! the number output by moboot are correct... Jul 29 22:19:43 oh, wait: the pointer is actually invalid: it should be aligned on an uint32 (4 bytes) Jul 29 22:32:23 Tofe: That means you might have a possible fix :P ? Jul 29 22:32:37 Or at least a clue where to look? Jul 29 22:34:23 yes, it now tries to boot the kernel Jul 29 22:38:30 On regular TP or Go? Jul 29 22:38:34 Go I expect issues Jul 29 22:38:44 https://github.com/Herrie82/moboot/pull/1 I left a bit of debug info Jul 29 22:38:49 TP here Jul 29 22:39:28 OK good Jul 29 22:40:54 In general shortloin is quite similar in terms of defconfig: https://tinypic.host/i/shortloin.jT5Tx Jul 29 22:41:12 I put the defconfig extracted from 2.6.35 for tenderloin and shortloin side by side Jul 29 22:41:38 makes sense yes Jul 29 22:41:57 Differences shouldn't be very critical really Jul 29 22:42:36 damn, nothing on serial cable :/ Jul 29 22:42:53 Well Bootie outputs logs to screen as well Jul 29 22:42:56 At least on my Go Jul 29 22:44:24 I'll stop here for today Jul 29 22:44:34 it was an interesting debug :) Jul 29 22:44:38 Tofe: Yeah Jul 29 22:44:46 Well important step :D Jul 29 22:45:10 it's just unbelievable that this alignment issue never occurred before Jul 29 22:45:31 I guess it's because of DTB somehow Jul 29 22:45:35 And it wasn't used before Jul 29 22:46:12 yes, or maybe when we generated the android kernel image, it was always 4-bytes aligned itself Jul 29 22:46:35 Or it's the armhf stuff somehow Jul 29 22:46:45 I recall they used some "older" stuff there for TP previously Jul 29 22:47:11 anyway, moboot was actually incorrect Jul 29 22:48:36 I'll have to double check tomorrow if the uImage I produce is actually correct, i.e. if ramdisk actually begins where it should Jul 29 22:49:07 ok, gn8 ! Jul 29 22:49:39 Tofe: Yeah good it's fixed now Jul 29 22:49:42 Gn8 **** ENDING LOGGING AT Sat Jul 30 02:59:57 2022