| sicelo | you are right. sorry about that. | 07:28 |
|---|---|---|
| freemangordon | hmm, on the first reboot after kernel upgrade, wifi connected on the first try | 08:02 |
| freemangordon | dunno if it is because kernel upgrade or icd plugin upgrade, but still :) | 08:02 |
| freemangordon | uvos: "4.582580] of: /cpus/cpu@1: Couldn't find opp node" | 08:04 |
| freemangordon | tmlind: ^^^ | 08:04 |
| Wizzup | which version is this? | 09:44 |
| freemangordon | Wizzup: Linux devuan-droid4 6.1.67 #1 SMP PREEMPT Thu Dec 14 01:53:20 UTC 2023 armv7l GNU/Linux | 11:08 |
| Wizzup | ok | 11:21 |
| uvos__ | hmm yeah i see | 11:26 |
| uvos__ | so i updted omap4 from opp-1 to opp-2, wierd is that despite this warning cpu1 has an opp table (that it shares with cpu0 anyhow since they share a common clock) | 11:27 |
| uvos__ | so i probubly just forgot to mark this fact somehow | 11:28 |
| uvos__ | *has an opp table in sysfs | 11:28 |
| uvos__ | so i need to figure out why its complaining, but it has no practical effect | 11:29 |
| freemangordon | maybe you have to mark cpu0 table as shared or common, or, dunno | 11:30 |
| uvos__ | i thought i did | 11:30 |
| uvos__ | but clearly not correctly | 11:30 |
| freemangordon | yeah | 11:30 |
| freemangordon | uvos__: hmm: "opp-shared: Indicates that device nodes using this OPP Table Node's phandle switch their DVFS state together, i.e. they share clock/voltage/current lines. Missing property means devices have independent clock/voltage/current lines, but they share OPP tables." | 11:37 |
| freemangordon | to me it seems like the opposite | 11:38 |
| freemangordon | look at https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt | 11:39 |
| freemangordon | example is for a9 exactly :) | 11:39 |
| freemangordon | where is the link between cpu0_opp_table0 and cpus? | 11:40 |
| freemangordon | here https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1.y/arch/arm/boot/dts/omap443x.dtsi#L12 | 11:44 |
| freemangordon | it is missing the node for cpu1 | 11:44 |
| freemangordon | uvos__: ^^^ | 11:45 |
| uvos__ | freemangordon: ok yeah | 11:49 |
| uvos__ | interesting that it dident need it for opp-v1 | 11:49 |
| freemangordon | uvos__: will you fix that? | 13:33 |
| Wizzup | sicelo: can you update the readme here ? https://github.com/maemo-leste-extras/maeotp the image links don't work | 13:41 |
| Wizzup | sicelo: any ideas how to use maeotp with pypi? | 13:58 |
| sicelo | pypi? | 14:08 |
| Wizzup | https://pypi.org account | 14:08 |
| Wizzup | They're forcing me to move to 2fa and I would like to use maemo | 14:09 |
| sicelo | ah :-) | 14:09 |
| Wizzup | I don't know how to generate compatible codes | 14:09 |
| Wizzup | I tried time based and event based codes with the key they provide, using 6 digit not hexa and they just reject them | 14:09 |
| sicelo | yes you can ... it's convoluted. get the code pypi gives you | 14:09 |
| Wizzup | sicelo: ok, I have that code | 14:10 |
| sicelo | then, follow https://github.com/jwhitbeck/otpn900/issues/1#issuecomment-408625414 | 14:10 |
| Wizzup | ok | 14:11 |
| Wizzup | this should be fairly easy to add to maeotp right? | 14:11 |
| Wizzup | (testing it now btw) | 14:12 |
| sicelo | yes, in fact i was thinking to use some C library for it. | 14:13 |
| Wizzup | sicelo: that worked | 14:13 |
| sicelo | awesome :-) | 14:13 |
| Wizzup | sicelo: either that or depend on basez and shell :p | 14:13 |
| Wizzup | let me look | 14:14 |
| Wizzup | libbaseencode1 is in apt | 14:15 |
| Wizzup | it seems to suggest to use libcotp | 14:16 |
| Wizzup | but that is only for version 2, and we have 12 (1.2) in debian I guess :) | 14:17 |
| Wizzup | in any case should we detect whether the key is in base32 or not in the app and just do the right thing? or do you want to make it explicit | 14:17 |
| Wizzup | (checkbox for 'this is base32 encoded') | 14:17 |
| Wizzup | sicelo: we can modify return_if_ok and have it check if the key is base32 ? | 14:22 |
| sicelo | i am not able to look at the code yet, but back when i ported it, my C-fu was no-existent. I'm a but better now, and I think I could improve it | 14:25 |
| Wizzup | if you want I can give it a quick try now | 14:25 |
| sicelo | surr, please feel free :-) | 14:25 |
| sicelo | basez and shell are definitely not good options. i think it's that libcotp indeed | 14:26 |
| Wizzup | I will use libbaseencode-dev until we move to a debian that has the newer libcotp | 14:26 |
| Wizzup | it's the same guy, same code, but only from v2 it has base32 in the main lib | 14:27 |
| Wizzup | also, good job on C-fu :) | 14:28 |
| arno11 | sicelo: Wizzup: now with boost (and PA user mode) and if we use 16bpp by default and recent sicelo cmtspeech PR, calls work 100% on n900 with no priority stuff or other tweaks, just need to load cmt_pulse at the right moment | 14:37 |
| arno11 | idealy after pin code | 14:38 |
| arno11 | or as late as possible during boot | 14:41 |
| freemangordon | arno11: did you manage to find what makes it faster on your device? | 14:50 |
| freemangordon | OC? | 14:50 |
| freemangordon | faster == faster scrolling | 14:50 |
| arno11 | probably oc | 14:51 |
| freemangordon | ok, I'll try later on with the new kernel to see if it is better | 14:52 |
| arno11 | and scrolling is @80% good | 14:52 |
| arno11 | ok | 14:52 |
| freemangordon | we shall make 16bpp default | 14:52 |
| arno11 | definitely | 14:52 |
| arno11 | it makes a huge diff | 14:52 |
| freemangordon | hmm, what is the xorg conf key for bpp? | 14:53 |
| freemangordon | anyway, I'll find it later on | 14:53 |
| freemangordon | bbl | 14:53 |
| arno11 | DefaultDepth | 14:54 |
| freemangordon | thanks | 14:55 |
| Wizzup | sicelo: k, shall I make a pr? | 15:05 |
| Wizzup | sicelo: https://github.com/maemo-leste-extras/maeotp/pull/7 | 15:14 |
| Wizzup | freemangordon: I will work on a new year news post | 15:18 |
| freemangordon | it's not that there are no news :) | 15:25 |
| freemangordon | arno11: do you want to make the change? | 15:25 |
| freemangordon | here https://github.com/maemo-leste/leste-config/blob/master/leste-config-n900/usr/share/X11/xorg.conf.d/99-omap.conf.leste | 15:26 |
| uvos__ | freemangordon: yes, but since the opp table is still applied to cpu1, as seen in sysfs there is no extraordinary rush | 15:32 |
| freemangordon | ok | 15:32 |
| arno11 | freemangordon: as you like | 15:43 |
| freemangordon | hmm, I think we shall increase priority of mce | 15:46 |
| freemangordon | at least on n900 it takes several attempts to detect power button clicks | 15:47 |
| freemangordon | systemui as well | 15:47 |
| Wizzup | is that because of priority, and now some sleep/wait/delays in mce? | 15:47 |
| freemangordon | no idea | 15:47 |
| Wizzup | I still have problem with power menu just coming up slowly | 15:47 |
| freemangordon | what sleeps? | 15:47 |
| Wizzup | and/or it coming up when I want to lock | 15:47 |
| freemangordon | how do you lock? double-press? | 15:48 |
| Wizzup | yes | 15:48 |
| freemangordon | on d4 I guess. or on n900? | 15:48 |
| freemangordon | hmm, what? "Dec 15 16:49:19 localhost systemui[2449]: systemui_do_callback:53:Invalid callback" | 15:49 |
| arno11 | freemangordon: not normal you need several attempts for power button clicks | 15:51 |
| freemangordon | maybe because of 125MHz | 15:52 |
| freemangordon | arno11: where is that 'boost' dir? | 15:52 |
| freemangordon | ah, it is disabled now | 15:52 |
| freemangordon | I was wondering why device feels snappier :) | 15:53 |
| freemangordon | found it (boost) | 15:53 |
| freemangordon | arno11: wait, why 850000 | 15:54 |
| freemangordon | I am sure I told you to enable 720 and 805 only, 850 is too high for most of devices | 15:55 |
| arno11 | you told me that we could had 720 805 and 850 | 15:55 |
| freemangordon | anyway | 15:55 |
| arno11 | anyway i is trivial to block it | 15:55 |
| freemangordon | yeah | 15:55 |
| freemangordon | and that's why uvos' device hangs when boost is enabled | 15:56 |
| arno11 | maybe | 15:57 |
| arno11 | the trick is to change governor | 15:57 |
| arno11 | before enabling boost | 15:57 |
| freemangordon | well | 15:57 |
| arno11 | this way no hang | 15:57 |
| freemangordon | could be, but still, 850 shall be disabled | 15:57 |
| arno11 | why do you think it will not work on most devices ? (just to understand) | 15:58 |
| freemangordon | there is a huge thread on TMO, dedicated to OC and undervoltage | 15:59 |
| freemangordon | and my experience with n900 tells me that only about maybe 5 % of the device can go stable up to 850/900 with no issue | 15:59 |
| freemangordon | *devices | 15:59 |
| freemangordon | and we don't know the effects in long term from such OC | 16:00 |
| freemangordon | one can always load dts overlay if she wants to fry her device | 16:00 |
| freemangordon | but I don;t think we as a distro shall allow such extereme OC by default | 16:01 |
| freemangordon | it is like telling the user "it is ok, go ahead, we tested and support this" | 16:01 |
| freemangordon | which is not true | 16:01 |
| arno11 | ok i see | 16:01 |
| freemangordon | 805 is ok on most devices, besides some vary bad ones | 16:02 |
| freemangordon | *very | 16:02 |
| freemangordon | ok, scrolling is still twice as slow compared to fremantle | 16:03 |
| arno11 | (btw i didn't use undervoltage in dts) | 16:03 |
| arno11 | really ? | 16:04 |
| freemangordon | you'd better not | 16:04 |
| freemangordon | yes | 16:04 |
| freemangordon | it is | 16:04 |
| arno11 | weird | 16:04 |
| freemangordon | that's something in gtk | 16:04 |
| freemangordon | I will try to find | 16:04 |
| arno11 | so with 16bpp and boost it's still the same ? | 16:05 |
| freemangordon | it is better | 16:05 |
| freemangordon | but worse than what should be | 16:05 |
| freemangordon | hmm, don't we have statistics time/frequency? | 16:06 |
| arno11 | i remember there was a fremantle script for that | 16:08 |
| freemangordon | no, taht is provided by the kernel | 16:08 |
| freemangordon | IIRC | 16:08 |
| arno11 | btw do you use a u3 card ? | 16:11 |
| freemangordon | don't know | 16:12 |
| arno11 | ah | 16:12 |
| freemangordon | but I think I use fast card | 16:12 |
| freemangordon | hmm, wait, xorg is using allmost all cpu when scrolling on n900 | 16:14 |
| freemangordon | this is not gtk | 16:14 |
| arno11 | seems different on my device, let me check | 16:17 |
| freemangordon | ok, about 45% | 16:17 |
| freemangordon | waccording to top while scrolling up->down... in settings | 16:17 |
| freemangordon | ok, this device has issues with TS | 16:18 |
| freemangordon | but I don;t see the same when scrolling in launcher | 16:18 |
| arno11 | indeed quite the same for me | 16:19 |
| Wizzup | launcher is not a gtk2 app right, that's an opengles app? | 16:19 |
| freemangordon | yes | 16:19 |
| freemangordon | but why should gtk put pressure on xorg? | 16:19 |
| arno11 | even PA put pressure on xorg sometimes | 16:20 |
| arno11 | and most of the time in realtime com | 16:20 |
| freemangordon | Wizzup: hmm is __ARM_ARCH_7A__ defined in CI? | 16:32 |
| freemangordon | for armhf builds that is | 16:32 |
| Wizzup | freemangordon: not sure how to test, but I think it should be | 16:40 |
| arno11 | Wizzup: freemangordon: i made a PR for 16bpp | 17:00 |
| freemangordon | Wizzup: looks like it is ok | 17:01 |
| arno11 | https://github.com/maemo-leste/leste-config/pull/44 | 17:01 |
| freemangordon | arno11: thanks | 17:01 |
| arno11 | no probs | 17:02 |
| freemangordon | did you try it? | 17:02 |
| arno11 | yes ofc | 17:02 |
| freemangordon | ok :) | 17:02 |
| arno11 | :) | 17:02 |
| uvos__ | it is impossible for mce to miss a power button click, no matter how slow the device is | 17:13 |
| uvos__ | at worst it will register a erronious long-press | 17:14 |
| uvos__ | i think there is a stall in systemui | 17:14 |
| uvos__ | the menu with the battery/connui etc also takes way to long to show up sometimes | 17:15 |
| freemangordon | or dbus | 17:18 |
| freemangordon | also, it is not missing it | 17:19 |
| freemangordon | but there is a huge lag\like more than a second | 17:19 |
| uvos__ | yeah | 17:19 |
| uvos__ | same on d4 | 17:19 |
| freemangordon | no | 17:19 |
| uvos__ | yes | 17:19 |
| freemangordon | ah, yes | 17:19 |
| freemangordon | xorg? | 17:19 |
| uvos__ | like the drop down with connui takes forever | 17:19 |
| uvos__ | no i think its specificly connui stalling systemui | 17:20 |
| uvos__ | the plugin | 17:20 |
| freemangordon | no, dropdown is just fine | 17:20 |
| uvos__ | its not every time | 17:20 |
| freemangordon | here it appears in a split second | 17:20 |
| uvos__ | but often enough it stalls for several seconds | 17:20 |
| uvos__ | even | 17:20 |
| uvos__ | when opening the drop down | 17:20 |
| freemangordon | yeah, but that's not what I am talking about | 17:20 |
| uvos__ | ok | 17:20 |
| uvos__ | then not sure | 17:20 |
| uvos__ | anytow that stall is connui stalling systemui i think | 17:21 |
| freemangordon | pressing power button with device locked (and display off): it takes more than a second for dsplay to be turned on | 17:21 |
| freemangordon | even on d4 | 17:21 |
| uvos__ | i mean just issuing xset dpms force on takes like 500ms | 17:21 |
| freemangordon | right | 17:21 |
| freemangordon | why is that? | 17:21 |
| uvos__ | so this is mostly kernel/xorg | 17:21 |
| uvos__ | not sure | 17:22 |
| freemangordon | half a second to enable backlight? | 17:22 |
| freemangordon | weird | 17:22 |
| freemangordon | but well | 17:22 |
| uvos__ | i mean it has to clear the display framebuffer | 17:22 |
| uvos__ | and setup dsi again | 17:22 |
| uvos__ | since it sleeps it | 17:22 |
| uvos__ | but still | 17:22 |
| uvos__ | im not sure why it takes so long | 17:22 |
| uvos__ | to be fair it takes pretty long on android too | 17:22 |
| uvos__ | not quite as long | 17:22 |
| uvos__ | but long | 17:22 |
| freemangordon | ok, but n900 with fremantle turns display on in couple of ms | 17:23 |
| freemangordon | umm... | 17:23 |
| freemangordon | couple hundreds | 17:23 |
| freemangordon | the same takes 1-2 seconds on leste | 17:23 |
| freemangordon | so this is not HW, for sure | 17:23 |
| uvos__ | so is xset just as slow on n900? | 17:24 |
| freemangordon | no idea | 17:24 |
| uvos__ | ok | 17:24 |
| freemangordon | just powered the device off :) | 17:24 |
| freemangordon | will test tomorrow | 17:24 |
| uvos__ | well on d4 not using vtllock helps alot | 17:24 |
| uvos__ | so something in that chain | 17:24 |
| uvos__ | is def also pretty slow | 17:24 |
| freemangordon | on n900 ( with fremantle and vtlkock) are those 200-400 ms | 17:25 |
| uvos__ | thres several dbus systemui mce round trips in there | 17:25 |
| uvos__ | so any one of those | 17:25 |
| freemangordon | maybe dbus roudtrip | 17:25 |
| freemangordon | will do some timing | 17:25 |
| freemangordon | when it comes to it | 17:25 |
| arno11 | freemangordon: when you have time, plz check 2023-10-16 irc log, 18:19, 18:20 :P | 17:43 |
| freemangordon | arno11: yeah, sorry abou tthat | 17:45 |
| freemangordon | however, back then we were thinking max boost frequency is not automatically enabled | 17:45 |
| arno11 | indeed | 17:45 |
| arno11 | i'll have a look and try to find a trick in cpufreq | 17:49 |
| arno11 | ok so for devices not able to run @850MHz the trick is to run powersave governor, enable boost, choose min and max freq in cpufreq and then back to ondemand/conservative mode | 18:24 |
| freemangordon | how are you sure powersave will not switch to 850 in the meanwhile? | 18:25 |
| freemangordon | esp during boot | 18:25 |
| arno11 | impossible | 18:25 |
| freemangordon | what is impossible? | 18:25 |
| arno11 | device is locked @600 max during boot | 18:25 |
| arno11 | and powersave locked @250 | 18:26 |
| arno11 | boost or not | 18:26 |
| arno11 | and remember, boost is available but not enable on boot | 18:26 |
| freemangordon | ok, maybe I don;t know how powersave works | 18:27 |
| freemangordon | does it lock the lowest freq? | 18:27 |
| arno11 | yes exactly | 18:27 |
| freemangordon | ok | 18:27 |
| arno11 | currently 250 | 18:27 |
| freemangordon | yeah | 18:28 |
| freemangordon | min 250 makes lots of difference | 18:28 |
| arno11 | indeed | 18:28 |
| arno11 | and 500 a bit more :P | 18:29 |
| freemangordon | that affects battery life | 18:29 |
| freemangordon | the correct way is to implement devfreq in sgx driver | 18:30 |
| arno11 | ok but i didn't notice any inpact, really | 18:30 |
| freemangordon | because it is already bad (battery life) :) | 18:31 |
| arno11 | currently 10-12h in use for me but with polarcell... | 18:33 |
| ac_laptop | hello people, I've looked a bit further about my battery problem, and, as you suggested, swapping batteries is definitely one of the reasons. I thought at first that swapping betteries of the same capacity would be ok, but no, the problem occurs if I swap two batteries of the exact same model. Which is an issue, because maemo-leste is drawing power so fast (a 1600 mAh battery lasts less than a | 19:29 |
| ac_laptop | day, with maemo leste mostly idle) that I will swap batteries often. | 19:29 |
| ac_laptop | So I guess I will mostly use fremantle on my N900 and boot under leste when it's really necessary. Now I have to find a way to make fremantle somewhat enjoyable to use | 19:31 |
| arno11 | ac_laptop: hi, when u say 'less than a day' you mean less than 24 hours idle with a 1600mA bat ? | 19:47 |
| ac_laptop | arno11: yeah, somewhere around 8 hours | 19:57 |
| arno11 | ??? ugh | 19:57 |
| arno11 | idle is around 50mA actually | 19:59 |
| arno11 | 70 with wifi On and Modem | 20:00 |
| arno11 | are you sure 1600mA is the real capacity ? | 20:01 |
| Wizzup | ac_laptop: do you run any particular programs on leste that can drain the battery? | 20:12 |
| ac_laptop | arno11: I'm sure, it's the polarcell battery recommended here | 20:12 |
| ac_laptop | and I have two of them | 20:13 |
| ac_laptop | Wizzup: I usually let it idel with a terminal open and wifi on. the only daemon I can think of is sshd. | 20:14 |
| Wizzup | arno11: building new leste-config | 20:14 |
| ac_laptop | But I'm going to make further tests, I have a question | 20:14 |
| Wizzup | ac_laptop: do you have wifi connected to something all the time, like using mosh? | 20:14 |
| arno11 | Wizzup: ok ty | 20:14 |
| arno11 | 8 hours with a polarcell means 200mA constantly | 20:15 |
| arno11 | that's a lot | 20:15 |
| ac_laptop | suppose I have a new n900 device and I have flashed u-boot on it and put leste on its mSD card, only to realise later that the fremantle on it is PR1.2, not 1.3 | 20:16 |
| ac_laptop | can I flash 1.3 now ? is there a risk that is messes with the bootloader ? | 20:16 |
| Wizzup | I think in general you can always re-flash fremantle, all you need to do from there is to re-enable cssu and set up u-boot again | 20:18 |
| sicelo | ac_laptop: 'nice' to know there's nothing weird about Fremantle. i've looked at the battery and charging drivers quite a bit, and of course, i'm no expect, but they do seem to be really well-written drivers | 20:20 |
| ac_laptop | sicelo: they must be, my n900 easily lasts idle on fremantle for about a week | 20:21 |
| sicelo | sorry, I meant Leste | 20:21 |
| sicelo | :-P | 20:21 |
| sicelo | but yes, Fremantle uses much less on idle, so that explains why you can't get a week out of Leste on the same charge | 20:22 |
| Wizzup | that's the diff between RET/OFF and no RET at all (n900 currently) | 20:23 |
| Wizzup | btw, someone made this issue, I don't know what to say yet but it's cool that someone is thinking about this: https://github.com/maemo-leste/bugtracker/issues/715 | 20:23 |
| * sicelo wishes he could dedicate Wizzup too OFF mode for a week :p | 20:23 | |
| Wizzup | sicelo: even if I did, I don't think I could fix it | 20:23 |
| Wizzup | the random hangs are too hard for me to fix | 20:23 |
| Wizzup | I could fix some drivers with help from people here, but the random reset/oops (if it is still there?) I don't know how tackle | 20:24 |
| Wizzup | sicelo: btw, if you can please check the maeotp pr | 20:29 |
| Wizzup | meanwhile I will look at https://github.com/maemo-leste/libcmtspeechdata/pull/4 | 20:29 |
| Wizzup | sicelo: here https://github.com/maemo-leste-extras/maeotp/pull/7 | 20:31 |
| sicelo | yes i'll look at it as soon as i get a chance. i'm excited about any improvement for maeotp | 20:31 |
| Wizzup | I think it just works and it's a small change | 20:31 |
| Wizzup | brb work mtg | 20:31 |
| ac_laptop | I'm going to flash PR1.3 on n900 n°2 then I will be able to change the boot menu, then I'll be able to compare the two devices to make sure there's isn't a hardware issue | 20:34 |
| Wizzup | sicelo: this change you made: https://github.com/maemo-leste/libcmtspeechdata/pull/4/files#diff-84c0b0616738c2f1a72d03d39de31b78269b0c731c5f9d0da888bdcc81ff98e6L501 | 20:58 |
| Wizzup | maybe that made the improvements that arno spoke about? | 20:58 |
| freemangordon | I was thinking the same | 21:12 |
| freemangordon | that's definitely a nasty bug fixed here, ata first glance | 21:13 |
| Wizzup | yep | 21:13 |
| freemangordon | ugh, please someone to comment on https://github.com/maemo-leste/bugtracker/issues/715, I am bad at design things | 21:17 |
| Wizzup | freemangordon: I also mentioned it earlier | 21:19 |
| freemangordon | ah, yes, didn't see it | 21:19 |
| freemangordon | and yes, I agree its cool | 21:19 |
| Wizzup | honestly my first thought was 'we are not ready for this' but then I also realised that it's great to have someone think about (and potentially work on) these things | 21:22 |
| freemangordon | mhm | 21:23 |
| freemangordon | 'we' will never be ready :p | 21:23 |
| Wizzup | who knows :) | 21:34 |
| * dsc_ pretends he is not here | 21:49 | |
| arno11 | btw 16bpp by default is ok | 22:02 |
| arno11 | i mean after update and reboot | 22:04 |
| Wizzup | :) | 22:10 |
| arno11 | Wizzup: freemangordon: for the cmtspeech improvement, it's over my skills but iirc alsa_test.c is not involved with cmt_pulse. it is just a latency test | 22:14 |
| Wizzup | okay, it was the main thing that I saw clearly changed | 22:23 |
| arno11 | otoh i was pretty sure something was wrong with audio_generate in utils/audio.c but failed to fix it | 22:24 |
| arno11 | iiuc it generates the tone when you call someone | 22:31 |
| arno11 | and it was buggy before sicelo commits | 22:33 |
| ac_laptop | hum I created the file /etc/bootmenu.d/30-maemo-leste.item, I ran u-boot-update-bootmenu under fremantle and I still have to use the flasher to get a boot menu, what did I miss ? | 22:35 |
| arno11 | keyboard was opened ? | 22:55 |
| ac_laptop | arno11: yes, but I think I've found the solution | 22:58 |
| ac_laptop | I installed u-boot-flasher and now it works | 22:58 |
| arno11 | ah ok cool | 23:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!