**** BEGIN LOGGING AT Sat Jan 24 02:59:59 2015 Jan 24 03:25:35 ugh, wtf Jan 24 03:25:44 no wonder the default camera application is so laggy. Jan 24 03:26:10 it reads images and other application resources when you take a picture? Jan 24 03:55:29 How does fcam do it? Jan 24 04:06:15 does maemo5 run on n800? Jan 24 08:38:57 ~packages Jan 24 08:39:16 ~maemo-pgks Jan 24 08:39:20 meh Jan 24 09:03:50 * Maxdamantus wonders how the camera-ui decides to produce the "Memory Full" error. Jan 24 09:04:00 * Maxdamantus wonders if it has to do with ke-recv. Jan 24 09:56:13 maemo is full of stupid shit Jan 24 09:56:22 because user interface simplification Jan 24 10:05:28 Indeed. Jan 24 10:06:21 UI simplification vs. modularity Jan 24 10:06:51 I'd go with modularity, but phone producers probably don't usually care about me. Jan 24 10:22:21 Yay. Got it to stop trying to mount /dev/mmcblk0p1 without recompiling ke-recv, and the camera still works. Jan 24 10:22:54 Will use it as a boot partition instead. Jan 24 10:27:35 * Maxdamantus wonders if anyone's tried GRUB on u-boot on the N900. Jan 24 10:28:22 why bother? Jan 24 10:28:25 uboot is pretty good Jan 24 10:28:37 isn't ke-recv just some shell scripts Jan 24 10:28:42 It seems tedious to configure. Jan 24 10:28:49 No. It's a program written in C. Jan 24 10:28:57 but it comes with some shell scripts. Jan 24 10:29:06 also what i'd like is to be able to open the back panel without forcibly cutting off the uSD Jan 24 10:29:14 Done. Jan 24 10:29:20 pls giff solution Jan 24 10:29:28 http://talk.maemo.org/showthread.php?t=94463 Jan 24 10:29:53 hacky solution, but it seems better than no solution. Jan 24 10:30:05 I think I'm meant to be using kernel-power, rather than the cssu1 thing. Jan 24 10:32:16 better for me anyway, as I don't have much interest in swapping SD cards. Jan 24 10:32:39 why even bother with the "if" Jan 24 10:32:43 just to keep the patch small? Jan 24 10:33:22 What would you do? Comment it out? Delete the line? Jan 24 10:33:31 delete it Jan 24 10:33:43 the source is not the place for removed code Jan 24 10:33:48 that's the VCS' job Jan 24 10:33:50 Then it's not obvious what the original code was. Jan 24 10:34:07 who gives a shit Jan 24 10:34:12 Exactly. Jan 24 10:34:14 it's right there in the history Jan 24 10:34:27 you're one of *those* aren't you Jan 24 10:34:31 My text editor doesn't show the history. Jan 24 10:35:00 you comment huge blocks of code and put "// maybe we'll need this later" Jan 24 10:35:26 * Maxdamantus would rather use a /* */ comment Jan 24 10:35:36 /* */ doesn't work with nested comments Jan 24 10:35:37 but that requires insertions in two places. Jan 24 10:35:45 you should use #if 0/#endif Jan 24 10:35:47 and even then Jan 24 10:36:11 the source code isn't meant for storing old text Jan 24 10:36:31 that's the VCS' responsibility Jan 24 10:36:54 but it's not really old. Jan 24 10:37:08 Since the rest of the code that uses that mechanism is still there. Jan 24 10:37:18 That code essentially becomes dead too. Jan 24 10:37:35 you can remove that too i guess Jan 24 10:37:38 if it's not in the API Jan 24 10:37:41 That's difficult. Jan 24 10:38:29 what's gpio_is_valid? Jan 24 10:38:33 i don't have the source handy Jan 24 10:39:15 It's part of the current mainline tree. Jan 24 10:39:26 * Maxdamantus doesn't want to switch branches atm Jan 24 11:10:53 yeah but Jan 24 11:10:56 can we just make the gpio invalid Jan 24 11:10:58 somehow Jan 24 11:21:24 It's not particular to the mmc driver. Jan 24 11:22:10 but yes, you could probably just modify the gpio_is_valid function and say no when given the identifier for the cover. Jan 24 11:22:30 that might have negative effects on the OS. Jan 24 11:23:18 It wouldn't indicate that the cover is closed. It would say the GPIO indicating whether or not it's closed no longer exists. Jan 24 12:15:27 (this is why I don't publish patches) Jan 24 13:20:03 hi, Jan 24 13:20:32 my n900 battery is empty and I can't start the n900 at all, so I've succedded to boot it trough an external battery: Jan 24 13:20:48 I keep the nokia battery in and trough wires I also connect an external battery Jan 24 13:20:54 and I monitor voltage trough a DMM Jan 24 13:21:23 now if I remove the external battery power source it shuts down Jan 24 13:21:43 I guess the proprietary charger daemon/script doesn't like the external battery Jan 24 13:21:48 If I put the charger Jan 24 13:21:50 it keep beeing on Jan 24 13:21:55 but it won't charge either Jan 24 13:22:02 so I wonder what the best strategy is Jan 24 13:22:20 I've at my disposal (beside the hardware that I just mentioned): Jan 24 13:22:38 a) a setup to compile mainline kenrel, I've a black screen when I launch it Jan 24 13:22:46 b) a setup to compile uboot Jan 24 13:22:53 c) an SHR image but no setup to compile it Jan 24 13:23:02 (my toolchain is an arm-none-*) Jan 24 13:23:43 I see nothing on lsusb Jan 24 13:24:14 I mean: I see nothing on usb once the kernel is "booted" but 0xFFFF does work with nolo Jan 24 13:24:53 ahh ok the kernel panics Jan 24 13:25:02 hmmm Jan 24 13:25:08 maybe bad microsd partition Jan 24 13:25:20 Sounds to me like the battery is dead? Jan 24 13:25:27 not totally dead Jan 24 13:25:29 it's not 0v Jan 24 13:25:37 I want to jumpstart it Jan 24 13:25:49 let me explain a bit more background Jan 24 13:26:03 less than one week ago I used this very same battery to jumpstart another phone Jan 24 13:26:16 and I didn't charge it after Jan 24 13:26:29 and now I'm ending up trying to jumpstart this n900 battery... Jan 24 13:27:01 first the jumpstart was to save my C155 battery (an osmocombb compatible featurephone) Jan 24 13:27:10 and the n900 battery isn't flat at all Jan 24 13:27:21 Since the mainline kenrel now has charging and so on Jan 24 13:27:32 would it charge the battery during a kernel panic? Jan 24 13:27:45 or while waiting for a rootfs Jan 24 13:27:51 what's the voltage of the batteries involved? Jan 24 13:28:14 here the total voltage is 3.58 with a nexus s battery and the n900 battery Jan 24 13:28:19 they're both in parallel Jan 24 13:28:28 the + is connected to both batteries's + Jan 24 13:28:30 that's in the low end Jan 24 13:28:31 and same for the GND Jan 24 13:28:37 ? Jan 24 13:28:44 what do you mean by that's in the low end? Jan 24 13:28:47 ah ok Jan 24 13:28:55 3.7v required I guess Jan 24 13:29:55 close to shutdown. Jan 24 13:29:56 If the nokia batery is very old and worn, it might drop too low once the other battery is disconnected Jan 24 13:29:58 that's when connected to the n900 Jan 24 13:29:59 ok Jan 24 13:29:59 as for charging, you'll see for yourself if voltage rises or not Jan 24 13:30:05 it does Jan 24 13:30:07 ok Jan 24 13:30:14 0.93v Jan 24 13:30:18 if that's 3.58 while charging at full rate, the battery is extremely empty Jan 24 13:30:27 that's what it drops too Jan 24 13:30:28 ok Jan 24 13:30:32 yes Jan 24 13:30:39 battery/batteries Jan 24 13:30:56 let me boot under maemo Jan 24 13:31:19 I connected the charger Jan 24 13:31:24 and I'll let it bot Jan 24 13:32:12 what happens if nolo charges the battery? Jan 24 13:32:22 is there some light emmited? Jan 24 13:32:33 If the two are very far apart in voltage when you parallell them, there could be large amount of current flowing between them, which could trigger the battery's protection circuit, effectively disabling one of them Jan 24 13:32:50 yes Jan 24 13:32:56 now I've a light under nolo Jan 24 13:33:23 and the voltage is at 3.50v Jan 24 13:33:28 so I'll keep it there Jan 24 13:33:29 right? Jan 24 13:33:44 orange light Jan 24 13:34:00 the voltage is at 3.50v with the charger and only the nokia battery Jan 24 13:35:10 beside the DMM I didn't succeed at knowing if the internal battery is connected Jan 24 13:37:46 (I've prevented it to boot from nolo) Jan 24 13:38:23 .93 is too low, in the sense that the protrction circuit kicks in at 2.8 or so Jan 24 13:38:38 ShadowJK: ok Jan 24 13:39:04 now the led is orange in nolo with only nokia battery and charger Jan 24 13:39:14 and that li-ion batteries get severely worn for every day at 2.8V already, let alone lower voltages Jan 24 13:39:40 since the wiki is down I've no idea of what it means (the orange led) Jan 24 13:39:59 recharging li-ion that's dropped to .9V could be dangerous, so dont leave it unattended (ever) Jan 24 13:40:05 ok Jan 24 13:40:07 I did once Jan 24 13:40:12 it didn't charge at all Jan 24 13:40:13 ok Jan 24 13:40:19 I left it in maemo Jan 24 13:40:23 with the battery and the charger Jan 24 13:40:34 now it's in nolo Jan 24 13:40:43 I keep monitoriing but still 3.50/3.51 Jan 24 13:40:53 I guess I need linux, and an initramfs Jan 24 13:41:09 I didn't succeed to boot something else than maemo Jan 24 13:41:24 I'm not sure what mainline does, if it needs software to turn on charging or not Jan 24 13:41:32 ok Jan 24 13:41:36 else there is SHR Jan 24 13:41:42 but I didn't succeed either Jan 24 13:41:47 Mainline works for me. Jan 24 13:41:49 it bet it didn't find mmc Jan 24 13:41:49 ok Jan 24 13:41:56 Maxdamantus: how do you boot it? Jan 24 13:42:04 combined kernel+uboot? Jan 24 13:42:14 I can give you a kernel you should be able to use to load the shell from ubifs, if you want. Jan 24 13:42:15 if so how to produce that, the python script that did it is done Jan 24 13:42:17 (no modules needed) Jan 24 13:42:19 Yes, uboot. Jan 24 13:42:22 I have that Jan 24 13:42:26 I have mainline too Jan 24 13:42:31 but I need to make them boot Jan 24 13:42:39 Oh, wait, my kernels have Dvorak hardcoded. Jan 24 13:42:41 I have that working: Jan 24 13:42:50 nolo->kernel->nothing on display Jan 24 13:43:07 nolo->uboot->2.6.37 on mmc Jan 24 13:43:11 and doesn't find rootfs Jan 24 13:43:14 so I need: Jan 24 13:43:17 does mainline have Pali's modules for bq24150? Jan 24 13:43:20 nolo->uboot->mainline-> Jan 24 13:43:24 I know how to compile mainline Jan 24 13:43:29 I did it in fact Jan 24 13:43:31 I lack: Jan 24 13:43:41 1) the script to assemble the mainline+uboot image Jan 24 13:43:42 kerio: yes: http://elinux.org/N900 Jan 24 13:43:48 2) good cmdline args Jan 24 13:43:57 I have that currently: Jan 24 13:44:16 CONFIG_CMDLINE="omapfb.vram=0:2M,1:2M,2:2M snd-soc-rx51.hp_lim=42 snd-soc-tlv320aic3x.hp_dac_lim=6 root=/dev/mmcblk1p1 rw console=tty0 panic=1" Jan 24 13:44:17 I copied the cmdline from 2.6.28.10 Jan 24 13:44:23 with CONFIG_CMDLINE_FORCE=y Jan 24 13:44:27 and I boot with DT Jan 24 13:44:34 so I've the combined zImage Jan 24 13:44:44 can't you get emergency charging from just nolo or uboot? Jan 24 13:44:47 are you sure the mmc device is right? Jan 24 13:44:50 any idea on what keystroke to make the bootloader boot maemo? Jan 24 13:44:57 Maxdamantus: of course not Jan 24 13:45:00 GNUtoo-irssi: 1) script is part of u-boot-tools extras package (/usr/bin/u-boot-gen-combined) Jan 24 13:45:06 lol Jan 24 13:45:07 ok thanks a lot!!!! Jan 24 13:45:09 I've noticed with 3.14–3.18, mmcblk0 is SD Jan 24 13:45:16 GNUtoo-irssi: any reason why you're not booting rescueOS? Jan 24 13:45:20 I've tried both mmcblk0 and mmcblk1 Jan 24 13:45:30 kerio: yes, I've not ever eared of it Jan 24 13:45:32 mmcblk0 is SD if there's a SD Jan 24 13:45:34 ok Jan 24 13:45:37 ~rescueos Jan 24 13:45:37 i guess rescueos is http://n900.quitesimple.org/rescueOS/ Jan 24 13:45:39 ok Jan 24 13:45:41 GNUtoo-irssi: you can use my linux-n900.git branch which contains patches which are not in mainline Jan 24 13:45:46 loadable via usb Jan 24 13:45:56 flasher-3.5 -k 2.6.37 -n initrd.img -l -b"rootdelay root=/dev/ram0" Jan 24 13:45:56 https://gitorious.org/linux-n900/linux-n900 Jan 24 13:47:01 Maxdamantus: mmc0 device is always uSD card, but mapping mmc0 to mmcblk0 or mmcblkd1 is not race free Jan 24 13:47:42 for that reason there is udev rule in maemo which maps eMMC (mmc1) to mmcblk0 and uSD (mmc0) to mmcblk1 Jan 24 13:47:43 nice Jan 24 13:47:46 thanks a lot Jan 24 13:47:49 Ah. Jan 24 13:47:53 let me try it Jan 24 13:48:08 btw I use 0xFFFF and the new features are so nice Jan 24 13:48:14 thanks a lot for them Jan 24 13:48:22 there is even coldflashing now Jan 24 13:49:38 GNUtoo-irssi: on linux-n900 there is branch v3.19-rc5-n900 Jan 24 13:49:42 which I updated *now* Jan 24 13:49:59 ok Jan 24 13:50:00 but I (auto)tested it only in qemu Jan 24 13:50:04 I was on 3.18 Jan 24 13:50:09 3.18.* Jan 24 13:50:25 it boots to busybox shell Jan 24 13:52:28 * Maxdamantus has had problems with 3.18, relative to 3.14 Jan 24 13:52:42 looks like ones people are aware of though. Jan 24 13:54:35 (USB not working, doesn't seem to shut down properly—screen goes blank and have to just take out the battery) Jan 24 13:55:13 in my git repo is some hack patch which could fix usb problems Jan 24 13:56:52 I think it happened in your repo too. Jan 24 13:56:59 something about musb core not ready. Dunno. Jan 24 13:57:59 (n900 repo, 3.18-rc6) Jan 24 14:02:04 ok, networking problem, since the n900 is 192.168.2.15 Jan 24 14:02:07 I'll fix that later Jan 24 14:02:49 I found that: ./rescueOS/charge21.bash Jan 24 14:03:37 Jan 24 14:03:39 if that's over usb, ifconfig usb0 10.0.0.123 Jan 24 14:03:48 (the networking problem) Jan 24 14:03:48 yes Jan 24 14:05:00 done anyway Jan 24 14:05:02 (or 10.123 for short) Jan 24 14:05:27 yes, here's what I have: Jan 24 14:06:12 Status: 0x10 Mode: CHARGING Full: 0 Wall: 0 Voltage: 3668 NAC: 0 level: 0 % Rate: 0 System: -950 Ch: 950 Jan 24 14:06:17 NAC means? Jan 24 14:06:29 I guess NAC != NAK Jan 24 14:06:31 nominal available charge Jan 24 14:06:34 ok Jan 24 14:06:40 I'll check sysfs Jan 24 14:07:12 status discharging Jan 24 14:07:14 hmmm Jan 24 14:07:26 present 1 Jan 24 14:07:32 I'll look if I can get an ID Jan 24 14:08:11 Status: 0x10 Mode: CHARGING Full: 0 Wall: 0 Voltage: 4118 NAC: 0 level: 0 % Rate: 0 System: -625 Ch: 625 Jan 24 14:08:15 maybe it still charges? Jan 24 14:08:25 beside wat the battery gauge driver says Jan 24 14:10:13 let me look Jan 24 14:10:17 I forgott the other battery on Jan 24 14:18:26 where's the . on the keyboard? Jan 24 14:28:37 charge script probably interacts badly if there's kernel charging modules Jan 24 14:29:19 or kernel battery gauge module Jan 24 14:29:52 middle row third last key, my guess Jan 24 14:31:19 it's weird that it shows somewhat credible voltage, but everything else is 0 Jan 24 14:32:03 ... and where the hell did 625 come from D: Jan 24 14:33:12 Oh, I see Jan 24 14:39:20 ShadowJK: ok Jan 24 14:39:28 hmmm Jan 24 14:39:30 I boot Jan 24 14:39:39 oops Jan 24 14:39:52 is there a way to setup the rescueOS to boot directly from flash Jan 24 14:40:05 (with reguard to kernel parameters) Jan 24 14:40:47 btw, I booted trough dual-batteries Jan 24 14:41:01 enabled charging Jan 24 14:41:10 switched to charger cable after enabling wifi Jan 24 14:41:16 then stopped charging Jan 24 14:41:21 it powered off Jan 24 14:41:35 I didn't restart charging fast enough to keep it on Jan 24 14:42:55 I'll tr again Jan 24 15:01:24 hmmm Jan 24 15:01:43 I guess the bootargs are in nolo, right? Jan 24 15:15:32 is it problematic if the charger script stays in 0x10? Jan 24 15:15:46 if I remember well 0x10 is usb charging trough a computer Jan 24 15:16:56 can I try to force 0x90? Jan 24 15:16:59 like by i2cset? Jan 24 15:17:03 what for Jan 24 15:17:07 i would have said other way around Jan 24 15:17:10 ok Jan 24 15:17:18 right, safer Jan 24 15:17:29 afaik the charge21.bash script in rescueOS assumes you're using a wallcharger Jan 24 15:17:40 ok Jan 24 15:17:48 I don't remember well the status values Jan 24 15:17:52 it's been years... Jan 24 15:18:23 Status: 0x10 Mode: CHARGING Full: 0 Wall: 0 Voltage: 4172 NAC: 0 level: 0 % Rate: 0 System: -213 Ch: 213 Jan 24 15:18:34 the DMM says 4.17/4.18 Jan 24 15:18:46 and the screen says something about stfu Jan 24 15:18:53 I've not yet looked at stfu Jan 24 15:18:57 rate 0 is weird. Jan 24 15:18:58 beside the fact that it disables the message Jan 24 15:19:00 ok Jan 24 15:19:25 right now after booting it trough a second battery, it now has only the charger and the internal battery Jan 24 15:19:32 and it's available trough wifi Jan 24 15:19:33 If there's battery gauge kernel module loaded, the script wouldn't be able to get that data Jan 24 15:19:36 (the shell)( Jan 24 15:19:38 ) Jan 24 15:20:03 what's voltage with one batt? with two battery? Jan 24 15:20:38 one batt: the ones that I just gave (4.16/4.17/1.18) Jan 24 15:21:19 03:39:47 < GNUtoo-irssi> is there a way to setup the rescueOS to boot directly from flash Jan 24 15:21:43 Maxdamantus: should I recompile the kenrel or should I instead boot trough uboot? Jan 24 15:21:44 using mkimage from u-boot-tools, yes. Jan 24 15:21:46 ok Jan 24 15:21:50 uboot then Jan 24 15:21:53 Don't need to recompile the kernel. Jan 24 15:22:03 well the fastest boot way would be better Jan 24 15:22:08 but that can work too Jan 24 15:22:33 if your uboot menu has something like "run emmcboot" in it, that looks for boot.scr on ext2 partitions on the eMMC. Jan 24 15:22:47 yes Jan 24 15:24:06 To make the uboot kernel image: mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n rescueOS -d 2.6.37 rescue.u Jan 24 15:24:15 yes Jan 24 15:25:10 and the commands to boot it, I think: ext2load mmc 1:2 $loadaddr /rescue.u; setenv bootargs 'init=..'; bootm Jan 24 15:25:15 it also often disconnect wifi-wise Jan 24 15:25:49 I could also modify the initramfs to have some more automatic boot Jan 24 15:25:54 like connect to wifi Jan 24 15:26:12 You write those commands into a file, say, foo, then: mkimage -A arm -O linux -T script -C none -n boot -d foo boot.scr Jan 24 15:26:21 * Maxdamantus wonders why it has to be so tedious. Jan 24 15:26:57 (the 1:2 above is assuming the ext partition with /resue.u is the second one) Jan 24 15:27:04 /rescue.u* Jan 24 15:27:26 compressed rom fs is CRAMFS? Jan 24 15:27:53 I think "compressed rom fs" refers to something other than cramfs. Jan 24 15:27:57 but will be conceptually similar. Jan 24 15:28:19 type cramfs Jan 24 15:28:20 indeed Jan 24 15:28:20 Yeah, cromfs, not cramfs. Jan 24 15:28:24 ok Jan 24 15:28:29 it says cramfs Jan 24 15:28:31 strange Jan 24 15:28:40 if I do mkcramfs and so on, would it work? Jan 24 15:29:14 Does the kernel have cramfs built-in? Jan 24 15:29:15 to be more precise: Jan 24 15:29:29 .../initramfs/rescueOS-1.1.img on .../initramfs/tmp type cramfs (ro,relatime) Jan 24 15:29:33 that's what mount shows Jan 24 15:29:47 CONFIG_CRAMFS=y Jan 24 15:29:48 yes Jan 24 15:29:55 Yeah, that should work then. Jan 24 15:30:00 anyway I'm recompiling it, souds more simple than uboot Jan 24 15:30:08 because uboot is yet one more interaction/hop Jan 24 15:30:43 What does recompiling it achieve? Jan 24 15:30:59 Oh, you mean recreating the cramfs? Jan 24 15:33:01 yes Jan 24 15:33:08 and hardcoding the CMDLINE Jan 24 15:33:21 I'm doing both Jan 24 15:33:36 for the compilation I've just to wait it to finish Jan 24 15:33:49 I'll see if it didn't finish in time for uboot Jan 24 15:35:20 hmmm Jan 24 15:35:21 autostart_script=`grep -q autostart /proc/cmdline && cat /proc/cmdline | sed -e 's/.*autostart=$.*$/\1/'` Jan 24 15:36:17 so I could just put some commands in the cmdline? Jan 24 15:40:03 and it's cramfs Jan 24 15:40:11 the images looks the same under file Jan 24 15:51:04 ok my cramfs work Jan 24 15:51:06 but not my kernel Jan 24 15:51:10 let me relook Jan 24 15:53:03 anyway, while a cramfs is read only, it's way easier than a classic initramfs to repack Jan 24 15:53:23 classic initramfs is gunzip + cpio -idv < ./the_image + cpio somestuff Jan 24 15:54:08 find . | cpio -o -H newc | gzip -9 >foo.gz Jan 24 15:54:12 I think. Jan 24 15:54:16 yes Jan 24 15:54:21 but I often have issues Jan 24 15:54:24 even if I do newc Jan 24 15:54:37 like I never remember how it works when including it inside the kernel Jan 24 15:54:43 but that's another story Jan 24 15:55:18 I'm not sure you're going to be able to include the cramfs in your kernel. Jan 24 15:55:24 if you're intending to flash the kernel. Jan 24 15:55:27 now I have: Jan 24 15:55:27 Status: 0x10 Mode: CHARGING Full: 0 Wall: 0 Voltage: 4172 NAC: 0 level: 0 % Rate: 0 System: -213 Ch: 213 Jan 24 15:55:31 yes Jan 24 15:55:42 I was talking about the usual way of doing repack Jan 24 15:55:52 and I was praising the easyness of this way Jan 24 15:55:57 I think it has to be less than somewhere around 4 MiB. Jan 24 15:58:18 ok Jan 24 16:05:08 Pali: is your bootmenu thing able to be reused? Jan 24 16:05:24 reused for what? Jan 24 16:05:50 eg, from the default menu, loading a script using the eMMC entry that does something like: bootmenu_0=foo=bar; bootmenu Jan 24 16:06:10 That would at least not clear the other entries, I'd imagine. Jan 24 16:06:30 sorry, some router issues Jan 24 16:06:41 anyway I'll use uboot Jan 24 16:06:56 the compiled kernel didn't boot... Jan 24 16:07:21 Maxdamantus: if you overwrite uboot env then it should work Jan 24 16:07:48 just run command bootmenu again Jan 24 16:08:05 uboot env? Jan 24 16:08:23 bootmenu_X is uboot env Jan 24 16:08:32 Oh, right, each one. Jan 24 16:08:48 Hm. Jan 24 16:09:05 * Maxdamantus wonders why he didn't put an underscore in his uboot keyboard layout. Jan 24 16:10:31 * GNUtoo-irssi wonder where the dot is in the rescueOS Jan 24 16:11:35 Oh. I probably do have an underscore, in the usual position. Jan 24 16:13:07 btw, I didn't find /usr/bin/u-boot-gen-combined Jan 24 16:13:12 is that a package of maemo? Jan 24 16:13:18 I looked in uboot source Jan 24 16:13:25 (upstream uboot) Jan 24 16:13:54 it is only in maemo extras u-boot-tools package Jan 24 16:14:19 it is shell script (busybox enabled :-)) Jan 24 16:14:57 Ahah. I've been doing it completely wrong. Jan 24 16:15:39 ok Jan 24 16:15:51 busybox shell is fine Jan 24 16:15:55 Mk, that does work. Jan 24 16:16:00 I've busybox on the rescueOS anyway Jan 24 16:16:14 where are the CSSU repos so I can download it? Jan 24 16:16:23 ~packages Jan 24 16:16:23