≡
[08:27:42] <codefree> xcko: i found out the reason 3.10 is used is because build is dependent on proprietary, GPL violating blobs Allwinner released for 3.10 kernel
[08:28:37] <codefree> though (ignoring for the moment the bootloader) I believe there is actually only one of the blobs in the TERES-1 linux-a64 tree
[08:29:16] <codefree> libschw blob
[08:29:50] <codefree> perhaps that blob will work in a 3.16 kernel, not sure
[08:32:55] <xcko> well, going off of the sunxi page for the a64, there are several more: https://linux-sunxi.org/A64
[09:12:27] <codefree> xcko: I did see that page, but I could only find one of those five binaries in the olimex linux-a64 tree
[09:13:32] <onre> isn't the process roughly like this: first you get something working with a bunch of OEM blobs and then, in due time, community will write open-source equivalents of those blobs, one by one
[09:13:46] <onre> ("will" as in "it probably happens sooner or later")
[09:17:24] <xcko> It seems that way. I wish I was a proficient enough developer to contribute to that work
[09:28:54] <codefree> onre: leastways, until the next release of hardware with a new hardware revision and a new round of blobs
[09:30:52] <onre> indeed
[09:31:37] <onre> I first hit this phenomenon in 2005
[09:31:57] <onre> in my naivete I tried hard to contact the OEM as they said in the manual that "all source code will be made availale at ftp.whatever.com"
[09:32:06] <onre> never happened, also they were really bad at answering phone
[09:32:48] <codefree> yeah, if you define source code to mean: binary blobs without source code
[09:33:04] <onre> well these guys never made either available
[09:33:05] <codefree> a recursive contradiction!
[09:33:27] <onre> I had to use their kernel as the base for my OS image
[09:33:58] <onre> can't remember the manufacturer name anymore, they were from Taiwan. the device was a handheld computer with barcode scanner etc, meant for usage in shipping terminals
[09:36:00] <codefree> goodnight all, off to bed
[11:46:01] <dddddd> hi
[19:20:39] <dddddd> jo0nas, now that I got the ubuntu image, I can see DT files in the first partition too, inside a64/
[19:34:45] <dddddd> Almost the same as a64-teres.dts in the github repo. Only diff (apart from a couple of whitespace changes, and the name!) is:
[19:35:06] <dddddd> - pmu_battery_cap = <0x251c>;
[19:35:06] <dddddd> + pmu_battery_cap = <0x1b58>;
[20:40:36] <adj__> hi, anyone here running the mainline NAND driver with MLC chips?
[20:42:28] <adj__> specially on the A20-OLinuXino-LIME2-n8GB
IRC #olimex 2018-01-14
[08:25:56] <xcko> codefree: I'm not sure, but you could check out the git repo on github to find out: github.com/olimex/diy-laptop[08:27:42] <codefree> xcko: i found out the reason 3.10 is used is because build is dependent on proprietary, GPL violating blobs Allwinner released for 3.10 kernel
[08:28:37] <codefree> though (ignoring for the moment the bootloader) I believe there is actually only one of the blobs in the TERES-1 linux-a64 tree
[08:29:16] <codefree> libschw blob
[08:29:50] <codefree> perhaps that blob will work in a 3.16 kernel, not sure
[08:32:55] <xcko> well, going off of the sunxi page for the a64, there are several more: https://linux-sunxi.org/A64
[09:12:27] <codefree> xcko: I did see that page, but I could only find one of those five binaries in the olimex linux-a64 tree
[09:13:32] <onre> isn't the process roughly like this: first you get something working with a bunch of OEM blobs and then, in due time, community will write open-source equivalents of those blobs, one by one
[09:13:46] <onre> ("will" as in "it probably happens sooner or later")
[09:17:24] <xcko> It seems that way. I wish I was a proficient enough developer to contribute to that work
[09:28:54] <codefree> onre: leastways, until the next release of hardware with a new hardware revision and a new round of blobs
[09:30:52] <onre> indeed
[09:31:37] <onre> I first hit this phenomenon in 2005
[09:31:57] <onre> in my naivete I tried hard to contact the OEM as they said in the manual that "all source code will be made availale at ftp.whatever.com"
[09:32:06] <onre> never happened, also they were really bad at answering phone
[09:32:48] <codefree> yeah, if you define source code to mean: binary blobs without source code
[09:33:04] <onre> well these guys never made either available
[09:33:05] <codefree> a recursive contradiction!
[09:33:27] <onre> I had to use their kernel as the base for my OS image
[09:33:58] <onre> can't remember the manufacturer name anymore, they were from Taiwan. the device was a handheld computer with barcode scanner etc, meant for usage in shipping terminals
[09:36:00] <codefree> goodnight all, off to bed
[11:46:01] <dddddd> hi
[19:20:39] <dddddd> jo0nas, now that I got the ubuntu image, I can see DT files in the first partition too, inside a64/
[19:34:45] <dddddd> Almost the same as a64-teres.dts in the github repo. Only diff (apart from a couple of whitespace changes, and the name!) is:
[19:35:06] <dddddd> - pmu_battery_cap = <0x251c>;
[19:35:06] <dddddd> + pmu_battery_cap = <0x1b58>;
[20:40:36] <adj__> hi, anyone here running the mainline NAND driver with MLC chips?
[20:42:28] <adj__> specially on the A20-OLinuXino-LIME2-n8GB
