mossroy has quit [Read error: Connection reset by peer]
<plaes>
I guess only reason they use 3.4 kernel is NAND support :P
<tkaiser>
plaes: It seems they looked at RPi, then Banana Pi and might simply just used any of LeMaker's OS images without even thinking about the kernel version?
<duangduang>
Have anyone of you hacked ViewSonic 133Q ?
<tkaiser>
plaes: They also feature an uncompressed Linux OS image with 7.2 GB in size. And people in their forum do not trust in longsleep's images since they're 'too small' (compared to the unnecessary blown up 7.2GB image)
<NiteHawk>
much inflate. so wow.
<duangduang>
Does anyone know the boot sequence of the original A31s SDK?
<ssvb>
plaes: I wonder if this can fix the reliability problems at 672MHz for you
<longsleep>
ahah "too small" seriously?
<tkaiser>
longsleep: Yeah, something like 'there's something wrong since the image from the Wiki is 7.2GB'. Don't remember exactly since looking through the forum makes me too sad
<longsleep>
i see, well i sign all my images for that reason
<longsleep>
everyone can check the signature and choose to trust that nothing is wrong when the signature is valid :)
<ssvb>
tkaiser: yeah, it's also good that there are no separate pine and pine+ images available for download
<ssvb>
tkaiser: some small fraction of users is expected to believe that the differentiation is purely on the software side and they can upgrade their hardware by simply using a different firmware :)
<ssvb>
tkaiser: or they just could click a wrong link
<longsleep>
ssvb: do they now have an image which works on the 512MB model?
<tkaiser>
ssvb: Well, I don't care not that much about _these_ users ;) But it's still sad that they don't provide less images and especially those that are working together with documentation what to expect. But instead they list an outdated Arch OS image with wrong error description instead of updating it
<longsleep>
i mean my arch and ubuntu images work just fine with all models
<ssvb>
longsleep: don't know, wasn't it so that you made unified images based on the RAM size detection?
<longsleep>
ssvb: yes
<longsleep>
tkaiser: well all images in the wiki are outdated now as i released new kernel, u-boot, dtb and ubuntu yesterday :)
<apritzel>
ssvb: Hi, for sunxi-fel on the A64, do you use only SRAM A1? So SRAM C and A2 are free to use? Or do you place any backup buffers in there?
<tkaiser>
longsleep: All Linux images work this way since they're all based on yours (fortunately). But I still don't understand why they do not link to your threads in the Wiki and only feature other images
<longsleep>
tkaiser: i guess they do not want to scare users as i clearly state the images are meant for developers :)
<longsleep>
also, the images i provide have no GUI
<longsleep>
that general GUI installer script from someone looks at least a bit promising
<tkaiser>
longsleep: True, instead they prefer to get negative publicity by not writing what's working and what not.
<ssvb>
apritzel: SRAM C is a continuation of SRAM A1, so we can interpret it as the same thing
<apritzel>
ssvb: right, also just found the part where parts of SRAM C are used for the stack backups
<apritzel>
tried to use SRAM A2 for ATF, but no luck so far
lennyraposo has joined #linux-sunxi
<apritzel>
just wondering if that's due to A2 being secure (as the manual says)
<ssvb>
apritzel: yes FEL boot needs extra ~8K of SRAM somewhere for the backup buffers and we can potentially use 40K for the SPL, so we need something like total 48K starting at 0x10000 for the SPL
<longsleep>
lennyraposo: get in touch with ssvb regarding the mali blob questions/discussion - i have no idea about it and do not understand what you just send me
<ssvb>
apritzel: there is no table for A64 there, but it is pretty much similar
<apritzel>
yeah, only that A2 is 64KB on the A64
<apritzel>
ssvb: I wil try to load it somewhere later into SRAM C now
bwarff__ has quit [Ping timeout: 252 seconds]
<ssvb>
apritzel: this sounds like a good plan
<apritzel>
I thought that SRAM C was the OpenRISC coupled one and wanted to keep this free
<wens>
nope, it's sram a2
jernej has quit [Ping timeout: 240 seconds]
<wens>
the 0x44000 offset gives it away
<wens>
0x40000 ~ 0x43fff is used for openrisc interrupt vectors
<apritzel>
... which is not mentioned in the manual ;-)
<wens>
it was in a31 :)
<longsleep>
tkaiser: do you know supported resolutions in Android for the Pine64? Was it me who decided that 1080p@60Hz was the one to use or was that just by coincidence?
<wens>
and while the memory mapping says sram c is 160 kb, section 3.5.1 (system control \ overview) says it's 172 kb
<apritzel>
wens: appears that they even struggle with copy&paste ;-)
<longsleep>
it sometimes helps to read the chinese manual
* wens
looks at a83 user manual emac section
<wens>
longsleep: is there one?
<longsleep>
wens: there is one for sure, if it is available somethere is another question
<longsleep>
somewhere
<ssvb>
longsleep: some companies prefer to use English for writing the documentation instead of their native language, if this documentation is supposed to be provided to international customers
<lennyraposo>
hey guys
<lennyraposo>
I wil msg ssvb
<ssvb>
longsleep: maintaining the same documentation in more than one language is a PITA
<lennyraposo>
just pm'd you ssvb
<lennyraposo>
and they through some chinese in there too ;)
<lennyraposo>
my understanding is we need the UMP
<lennyraposo>
and DRM
<ssvb>
oh, we are discussing it here after all
<longsleep>
ssvb: yes, i have been in china and i can just say that a lot of developers do not understand english _at all_
<wens>
understandable :p
<lennyraposo>
ya I just sent that blurb over to you
<lennyraposo>
I will get tllim to send me the stuff
<ssvb>
UMP is not strictly necessary, it was an old buffer sharing implementation used by the mali driver
<longsleep>
right, but what has it todo with libdram? how is that related to mali at all?
<longsleep>
not that i know anything about mali :)
<ssvb>
libdram is completely unrelated to mali
<tkaiser>
longsleep: No idea about HDMI resolution with Android/RemixOS. All I did was to verify whether they boot (which they do NOT when Ethernet is connected on 1st boot ;) And IIRC both drove the display with 1080p
<longsleep>
ah i just read it wrong, they are talking about DRM not DRAM - my bad
<ssvb>
except that libdram is critical for being able to boot the system in the first place :-)
<longsleep>
imagined an A
<ssvb>
you are not alone confusing this
<lennyraposo>
btw ssvb
<lennyraposo>
other than the core count what are the differences between mali 400 and the 450?
<ssvb>
lennyraposo: better ask libv, but afaik mali 450 has two vertex processors instead of one
<ssvb>
while mali 400 had one vertex processor and multiple pixel processors (from 1 to 4)
<longsleep>
tkaiser: do you know the reason why it does not boot when ethernet is connected?
<longsleep>
tkaiser: not that i care, but that seems to be quite a fundamental issue for users
<libv>
i have not played with mali-450 yet
<KotCzarny>
maybe scripting b0rkage, if its one time?
<ssvb>
lennyraposo: I don't know if this hardware change really makes the drivers incompatible, but we can't make any assumptions about this
tkaiser has quit [Ping timeout: 252 seconds]
<libv>
is that even a sunxi question?
<ssvb>
well, getting mali binary drivers working on pine64 is a sunxi question
<lennyraposo>
yep
<ssvb>
and also whether trying the mali-450 blob makes any sense is also a sunxi question to some extent
<ssvb>
though I believe that the pine64 people should just provide the right blob
<libv>
it's a mali-400 mp2 in the pine64
<lennyraposo>
yep
jernej has joined #linux-sunxi
<lennyraposo>
was wondering as Arm has the Mali 450 available on their site
<ssvb>
so far even the mali-400 blobs used to be buggy on mali-400 :)
<ssvb>
and by expecting the mali-450 drivers to work on mali-400 hardware, you are raising the bar a bit
apritzel has quit [Ping timeout: 244 seconds]
<lennyraposo>
was wondering ;)
IgorPec has joined #linux-sunxi
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
apritzel has joined #linux-sunxi
<montjoie>
wens: does the a83t emac datasheet is different in english ?
<montjoie>
than chinese
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 246 seconds]
<longsleep>
narf, the rpi image building gear does not work on a luks encrypted mount .. :/
<longsleep>
err fc
vagrantc has joined #linux-sunxi
doppo has quit [Ping timeout: 260 seconds]
doppo has joined #linux-sunxi
SadSmile has quit [Quit: Leaving]
duangduang is now known as MoeIcenowy
MoeIcenowy is now known as duangduang
scream has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
dev1990 has joined #linux-sunxi
<plaes>
ssvb: I'll try it tomorrow...
[7] has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
doppo has quit [Ping timeout: 276 seconds]
doppo has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
apritzel has quit [Ping timeout: 244 seconds]
jernej has quit [Ping timeout: 252 seconds]
jelly has quit [Ping timeout: 260 seconds]
jelly-home has joined #linux-sunxi
tkaiser has joined #linux-sunxi
apritzel has joined #linux-sunxi
tkaiser has quit [Ping timeout: 250 seconds]
Netlynx has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
cptG has joined #linux-sunxi
apritzel has joined #linux-sunxi
cptG_ has quit [Ping timeout: 252 seconds]
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 268 seconds]
doppo has quit [Ping timeout: 276 seconds]
doppo has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
jernej has quit [Quit: Konversation terminated!]
apritzel has joined #linux-sunxi
tkaiser has joined #linux-sunxi
scream has quit [Remote host closed the connection]
mozzwald has quit [Read error: Connection reset by peer]