≡
[01:29:07] <malina> ah ok. cheers.
[01:29:46] <malina> I see that the a20 has a hw bug, which seems like ti won't be fixed. or was that the 64 bit perhaps. I mean, I think it was the 64 bit, which I was interested in, so would it be better to just go for the 32 bit?
[01:30:31] <malina> I build my own linux images so as such it won't matter, apart from being on 64 bit would make it for easier transitions on future upgrades
[01:47:35] <nedko> what a20 hw bug you are referring to?
[02:21:55] <malina> I see on forums that erm either the a20 or the a64 rather? has a time skew bug which jumps to 2115 or something, which can redner several time sync services unusable
[02:22:29] <malina> making it potentially onlyfixable by physical access, and can be rather bad when using as a server
[02:22:36] <malina> sorry, I didn't see yoru reply
[02:25:46] <malina> these things aren't too different from when I ran linux off repurposed arm phones a few years back? I would prefer, as the perfomance is humble, that such bugs aren't around. So the question was more if 32 bit a 20 would be better. the issue was with the 64 bit I thin, right?
[02:26:26] <malina> (ping my nick if you don't mind if you are around, as else I will probably miss the message).
[09:56:45] <leon-anavi> hi
[12:37:46] <jo0nas> Asara: I am very happy to hear that you found use of my image!
[12:38:37] <jo0nas> yes, the image should be perfectly fine to upgrade to newer releases of Debian - and there's also a bullseye image to skip one step :-)
[17:07:19] <Asara> everything worked great jo0nas thanks!
[17:09:30] <jo0nas> ohh, that is nice the hear :-D
[17:11:31] <jo0nas> Asara: what is your use-case (if not secret)? Could some improvements to my images be more helpful for you? If you feel it is too off-topic for this irc channel, then you are wlecome to join #tinker on OFTC.net where I hang out with a few others also using those images
[17:12:15] <Asara> honestly just using it as a linux server
[17:12:25] <Asara> i liked the idea of running a bitcoin + lnd node on open hardware
[17:12:40] <Asara> and have been doing so for like a year on the debian image but a while back it broke and i finally got some time to get that running again
[17:13:03] <Asara> so its a full bitcoin node with lnd running over tor nothing secret but nothing too fancy either
[17:16:45] <jo0nas> I don't know what "lnd" is, but I maintain the bitcoin package in Debian so I am curious if you might have some experience in running it that might be sensible to adopt into the Debian package
[17:18:47] <jo0nas> again, if you prefer discussing such details off of this channel, you are most welcome to file a bugreport as described at the top of https://bugs.debian.org/src:bitcoin
[17:23:34] <jo0nas> ah, found it: https://github.com/lightningnetwork/lnd
[22:06:32] <ro__> Happy new year everybody :)
[22:07:17] <ro__> Is there a ARM SoC available which is free from binary blobs? Free is the sense of freedom?
[22:08:08] <ro__> free in* the sense of freedom
[22:47:20] <jo0nas> ro__: yes, in the most common interpretation (and the logic that FSF "RYF" is about): That no binaries-without-source needs to be loaded into the board for the board to function
[22:48:42] <ro__> jo0nas: does that refer to the OLinuXino products?
[22:48:59] <jo0nas> the Allwinner A20 SoC used e.g. in the OSHW-certified board LIME2 requires no binary blobs loaded to function
[22:50:36] <ro__> sounds good
[22:50:38] <jo0nas> the Allwinner A64 SoC used e.g. in the OSHW-certified board OLinuXino-A64 and the TERES-I laptop DIY kit also requires no binary blobs loaded to function
[22:51:22] <jo0nas> ...but other components in some boards do require binary blobs, most notably wifi chips
[22:53:37] <ro__> ah yes; thanks for pointing that out. indeed, the peripheral devices need them usually
[22:54:51] <jo0nas> (there are other more strict interpretations that are not possible to achieve with *any* SoC of decent speed: That all functionality must be open and freely licensed - not even RiscV chips are fully open and freely licensed, some parts are non-free)
[22:56:24] <jo0nas> why do you ask? Just commonly curious, or do you consider building some system that you want RYF certified, or something else?
[22:57:31] <jo0nas> ACTION owns several OLinuXino LIME2 and A64 boards used as servers and test desktop systems, and a TERES-I used for an experimental desktop system
[22:58:17] <jo0nas> ...and works as a systems administrator using purely Debian systems, and maintains packages for Debian and Purism
[22:59:09] <jo0nas> perfectly fine if you don't want to answer - I was just curious :-)
[23:17:56] <ro__> jo0nas: I'd like to write a short guide on using open SoC's
IRC #olimex 2021-01-08
[01:28:47] <nedko> malina: T2 is industrial temperature grade while A20 is commercial temperature range grade version of same SoC[01:29:07] <malina> ah ok. cheers.
[01:29:46] <malina> I see that the a20 has a hw bug, which seems like ti won't be fixed. or was that the 64 bit perhaps. I mean, I think it was the 64 bit, which I was interested in, so would it be better to just go for the 32 bit?
[01:30:31] <malina> I build my own linux images so as such it won't matter, apart from being on 64 bit would make it for easier transitions on future upgrades
[01:47:35] <nedko> what a20 hw bug you are referring to?
[02:21:55] <malina> I see on forums that erm either the a20 or the a64 rather? has a time skew bug which jumps to 2115 or something, which can redner several time sync services unusable
[02:22:29] <malina> making it potentially onlyfixable by physical access, and can be rather bad when using as a server
[02:22:36] <malina> sorry, I didn't see yoru reply
[02:25:46] <malina> these things aren't too different from when I ran linux off repurposed arm phones a few years back? I would prefer, as the perfomance is humble, that such bugs aren't around. So the question was more if 32 bit a 20 would be better. the issue was with the 64 bit I thin, right?
[02:26:26] <malina> (ping my nick if you don't mind if you are around, as else I will probably miss the message).
[09:56:45] <leon-anavi> hi
[12:37:46] <jo0nas> Asara: I am very happy to hear that you found use of my image!
[12:38:37] <jo0nas> yes, the image should be perfectly fine to upgrade to newer releases of Debian - and there's also a bullseye image to skip one step :-)
[17:07:19] <Asara> everything worked great jo0nas thanks!
[17:09:30] <jo0nas> ohh, that is nice the hear :-D
[17:11:31] <jo0nas> Asara: what is your use-case (if not secret)? Could some improvements to my images be more helpful for you? If you feel it is too off-topic for this irc channel, then you are wlecome to join #tinker on OFTC.net where I hang out with a few others also using those images
[17:12:15] <Asara> honestly just using it as a linux server
[17:12:25] <Asara> i liked the idea of running a bitcoin + lnd node on open hardware
[17:12:40] <Asara> and have been doing so for like a year on the debian image but a while back it broke and i finally got some time to get that running again
[17:13:03] <Asara> so its a full bitcoin node with lnd running over tor nothing secret but nothing too fancy either
[17:16:45] <jo0nas> I don't know what "lnd" is, but I maintain the bitcoin package in Debian so I am curious if you might have some experience in running it that might be sensible to adopt into the Debian package
[17:18:47] <jo0nas> again, if you prefer discussing such details off of this channel, you are most welcome to file a bugreport as described at the top of https://bugs.debian.org/src:bitcoin
[17:23:34] <jo0nas> ah, found it: https://github.com/lightningnetwork/lnd
[22:06:32] <ro__> Happy new year everybody :)
[22:07:17] <ro__> Is there a ARM SoC available which is free from binary blobs? Free is the sense of freedom?
[22:08:08] <ro__> free in* the sense of freedom
[22:47:20] <jo0nas> ro__: yes, in the most common interpretation (and the logic that FSF "RYF" is about): That no binaries-without-source needs to be loaded into the board for the board to function
[22:48:42] <ro__> jo0nas: does that refer to the OLinuXino products?
[22:48:59] <jo0nas> the Allwinner A20 SoC used e.g. in the OSHW-certified board LIME2 requires no binary blobs loaded to function
[22:50:36] <ro__> sounds good
[22:50:38] <jo0nas> the Allwinner A64 SoC used e.g. in the OSHW-certified board OLinuXino-A64 and the TERES-I laptop DIY kit also requires no binary blobs loaded to function
[22:51:22] <jo0nas> ...but other components in some boards do require binary blobs, most notably wifi chips
[22:53:37] <ro__> ah yes; thanks for pointing that out. indeed, the peripheral devices need them usually
[22:54:51] <jo0nas> (there are other more strict interpretations that are not possible to achieve with *any* SoC of decent speed: That all functionality must be open and freely licensed - not even RiscV chips are fully open and freely licensed, some parts are non-free)
[22:56:24] <jo0nas> why do you ask? Just commonly curious, or do you consider building some system that you want RYF certified, or something else?
[22:57:31] <jo0nas> ACTION owns several OLinuXino LIME2 and A64 boards used as servers and test desktop systems, and a TERES-I used for an experimental desktop system
[22:58:17] <jo0nas> ...and works as a systems administrator using purely Debian systems, and maintains packages for Debian and Purism
[22:59:09] <jo0nas> perfectly fine if you don't want to answer - I was just curious :-)
[23:17:56] <ro__> jo0nas: I'd like to write a short guide on using open SoC's
