hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
naobsd has quit [Quit: Page closed]
ganbold has joined #linux-sunxi
hramrach_ has quit [Ping timeout: 240 seconds]
hramrach_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<drachensun> well it looks like the A31 can play 720 video without any hardware acceleration
<drachensun> gotta love 4 cores
wingrime has joined #linux-sunxi
eebrah|away is now known as eebrah
jelly-home has quit [Quit: ZNC -]
<oliv3r> if only it didn't have that very stupid power VR
hurtigbuffer has joined #linux-sunxi
<oliv3r> hno: yeah it's no9t a little different, it's a completly 'new design'
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<rm> no worries, it will work just fine as a server :D
<oliv3r> sure, but it's not sending a clear single
<oliv3r> 'we buy powerVR anyway'
<oliv3r> 'here powerVR, have some money for this shit GPU, even though I don't even use it'
hurtigbuffer is now known as jelly-home
rellla has joined #linux-sunxi
Soru has quit [Ping timeout: 246 seconds]
Soru has joined #linux-sunxi
jukivili has quit [Remote host closed the connection]
rellla has quit [Remote host closed the connection]
n01 has joined #linux-sunxi
rellla has joined #linux-sunxi
jukivili has joined #linux-sunxi
arete74 has joined #linux-sunxi
<mripard_> oliv3r: honestly, while I understand your stand on the PowerVR, I really don't see any difference regarding the openness of the company that backs both GPU
<mripard_> they're both closed, period.
jelly-home has quit [Quit: ZNC -]
arete74 has quit [Ping timeout: 264 seconds]
hurtigbuffer has joined #linux-sunxi
hurtigbuffer is now known as jelly-home
n01 has quit [Ping timeout: 248 seconds]
n01 has joined #linux-sunxi
<oliv3r> mripard_: ask libv :)
Tartarus has quit [Ping timeout: 256 seconds]
<oliv3r> mripard_: there's atleast efforts for mali and ardreno
<oliv3r> nothing as of yet for powervr; also libv says powervr is a horrible mess :)
<oliv3r> and those efforts for mali and ardreno are progressing very nicely. We can do 3D now with opensource drivers
<oliv3r> mripard_: what did you do all this weekend? :)
n01 has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
n01 has quit [Read error: Connection reset by peer]
hansg has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
n01 has joined #linux-sunxi
arete74 has joined #linux-sunxi
n01 has quit [Read error: Connection reset by peer]
Tartarus has joined #linux-sunxi
n01 has joined #linux-sunxi
<mripard_> oliv3r: yeah, but they're not backed by or at least supported by either ARM or AMD
<mripard_> if you wanted to really take that stand, I guess tegra is the only alternative
<oliv3r> mripard_: no, but arm knows what libv is doing, and it annoys them; sot hat's worth it
Tsvetan has joined #linux-sunxi
<oliv3r> yeah but nvidia in itself is again very much not a big opensource friend. It was a huge huge supprise that the tegra is so friendly
_BJFreeman has joined #linux-sunxi
<oliv3r> also adreno is owned by qualcomm wasn't it? it used to be amd
_BJFreeman is now known as BJfreeman
n01 has quit [Ping timeout: 246 seconds]
<mripard_> oliv3r: yet, they fully back the tegra GPU effort
<mripard_> (and the guy behind it is even a nvidia employee now)
_BJFreeman has joined #linux-sunxi
BJfreeman is now known as Guest13223
_BJFreeman is now known as BJfreeman
Guest13223 has quit [Ping timeout: 252 seconds]
Tartarus has quit [Ping timeout: 256 seconds]
<mripard_> and this week end, I improved the timers used in the kernel
<mripard_> and I have some patches that boots the A31
<mripard_> but it really slow
<mripard_> like it takes hours to boot :)
<mripard_> so it still needs some work :)
jelly-home has quit [Quit: ZNC -]
hurtigbuffer has joined #linux-sunxi
hurtigbuffer is now known as jelly-home
Tartarus has joined #linux-sunxi
paulk-desktop has joined #linux-sunxi
vicenteH has joined #linux-sunxi
<oliv3r> hours? wow
<oliv3r> mripard_: what happened to a20 :p
<oliv3r> mripard_: so you haven't had time to look at greg's comment? :)
eebrah is now known as eebrah|away
n01 has joined #linux-sunxi
eebrah|away is now known as eebrah
Soru has quit [Ping timeout: 248 seconds]
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
<oliv3r> hno: those two patches i've sent you, finish the a20 work before merging it back imo, unless sun5i doesn't work with it. Sun7i works just fine and sun4i works equally aswell :)
<oliv3r> hno: if you take all mails from me from sunxi and delete those that I replied to to be ignored; you should have all that needs merging
<oliv3r> 2 for a20 branch, a few for sunxi-current
<mripard_> oliv3r: yes, something like 5-6 hourss
egbert_ is now known as egbert
jinzo has joined #linux-sunxi
<oliv3r> mripard_: just to boot; lol that's really slow :)
<oliv3r> 0.5 MHz
<mripard_> no kidding :)
<mripard_> oliv3r: and for greg's comment, have you considered just asking him what he meant ? :)
<oliv3r> rellla: cna you test rudi's patch?
<oliv3r> mripard_: of course, many times, but .. it's greg, one does not just ask greg!
<oliv3r> i'll reply now then :)
<rellla> oliv3r: not atm, but soon surely.
<oliv3r> rellla: the one that fixes some offset thing
<oliv3r> would be great to merge it asap if it fixes things
<rellla> how can crashing cedarx be reproduced based on this issue?
<oliv3r> rellla: overflow :D
<oliv3r> i'm not very sure this happens much at all
<mripard_> oliv3r: I'll do it if you want.
<mripard_> I'm interested in how can it race anyway
<oliv3r> mripard_: nah, i'll mail him, i'll have to get over my fear at some point ;)
<oliv3r> mripard_: okay then :)
<oliv3r> my only guess is, that he overlooked the 'binary' bit
<oliv3r> and then i agree, using the default attributes is smarter
<oliv3r> mripard_: thanks, atleast I don't look even more dumber then usual ;)
<oliv3r> mripard_: also, i really really intend to start a31 dram init looking into now
<oliv3r> mripard_: spent all weekend on a20 stuff and getting sun4i to boot from the same codebase
<oliv3r> so all ready to look at sun6i now
jukivili has quit [Ping timeout: 255 seconds]
<hramrach_> mripard_: last time I looked tegra opensource drivers were a mess and nVidia only comitted to making a framebuffer driver - like vesa without the bios
<ssvb> oliv3r: have you introduced any changes to sun4i dram code or was that just assigning names to magic constants?
<oliv3r> ssvb: sun4i dram code remains the same, only names
<oliv3r> ssvb: sun7i dram code has been changed
<oliv3r> so it's time to add sun6i code if possible and to start merging stuff
<oliv3r> e.g. some order changes if they work; tons of cleanup, it's kind of messy
<oliv3r> and figuring out if certain changes really are needed or not
rz2k has joined #linux-sunxi
<ssvb> oliv3r: good, so the resulting dram.o file remains the same before/after patch for sun4i?
hramrach__ has joined #linux-sunxi
<oliv3r> it should
<oliv3r> if you use CONFIG_SUN4I it should be identical
<ssvb> somebody needs to verify this, just in case :)
<oliv3r> i did split the patch in
<oliv3r> so that it's very easily verifiyable
hramrach_ has quit [Ping timeout: 240 seconds]
<oliv3r> ssvb: feel free to comment on the patch series :)
[hawk] has joined #linux-sunxi
vincenzo has quit [Ping timeout: 248 seconds]
<libv> mripard_: what, kusma now works for nvidia?
<libv> he never told me :(
<mripard_> libv: I was thinking about Thierry Redding
<libv> mripard_: erik faye-lund started the work several months before
jukivili has joined #linux-sunxi
<libv> after i got him to steer clear of pvr (like i did with the etnaviv guy)
<wingrime> oliv3r: what do you think about jpg
<wingrime> oliv3r: where it can be used
<libv> kusma, as a former falanx engineer, spent his first 7-8 months in the lima channel telling cwabbot and flatmush to "look at this shader, it might be interesting"
<oliv3r> in android? tons of places
<libv> and then decided somewhere in the summer to go do it himself
<oliv3r> wingrime: ideally, we'd want to patch libjpeg(-turbo) to use it and see if there's a performance gain
<wingrime> oliv3r: it will be like full repace
<oliv3r> wingrime: think of all those thumbnail generation tools, if that can be sped up; *win*
<wingrime> oliv3r: becode cedar take care whole decoding
<wingrime> oliv3r: I mean, cedar do wholl jpeg after proper config
<wingrime> oliv3r: PoC are workable
bfree has quit [Quit: Konversation terminated!]
jemk has joined #linux-sunxi
<oliv3r> wingrime: partial, but yeah, thing is, libjpeg is 'standard' so by replacing; every product on the planet can use an accelerated libjpeg :)
<oliv3r> which is a win :)
<oliv3r> nothing needed to port etc
<oliv3r> libv: mripard_ needs some convincing that powerVR is more evil then any of the others ;)
<wingrime> oliv3r: libjpeg have no simple API. not so simple as I remeber
tzafrir has joined #linux-sunxi
<wingrime> oliv3r: it do it row by row
Quarx has joined #linux-sunxi
<oliv3r> wingrime: well we can invent our own lib, but then you have to rewrite all userspace applications
<oliv3r> if you rewrite libjpeg; you just replace libjpeg and it's accelerated :)
<oliv3r> but that's for later i think anyway
<oliv3r> first we need to decide, will we do mpeg1 first (and after that mpeg2)
<oliv3r> since the kernel driver will need to be re-written aswell to be cleaner and interface with libjpeg or libjpeg -> libcedero -> kernel
<oliv3r> so patching libjpeg isn't probably a todo right now
<oliv3r> i'll try to do the tables today/tomorrow on the wiki
<jemk> oliv3r: im working on mpeg1+2, they are nearly identical
BJfreeman has quit [Ping timeout: 252 seconds]
<jemk> and yes, the kernel driver needs to be rewritten
<jemk> handling physical addresses in userspace is very bad
<libv> oliv3r: then mripard never worked with pvr before.
<wingrime> jemk: any result with mpeg?
<oliv3r> yeah, mpeg1 is just mjpeg (or jpeg) with new P frames (and B?) and mpeg2 adds motion estimation/compensation?
<oliv3r> so it's "flows" nicely from one format to the next :)
<jemk> wingrime: not really, having some problems figuring out contents of reg 0x100 (mphr)
<oliv3r> jemk: the biggest problem is 'how does the new cedar kernel driver look like' since there's no kernel framework for this yet afaik
<oliv3r> jemk: but i think that's all for later; first we want to know how everything works so we can mold it as we want
<jemk> oliv3r: full ack
_BJFreeman has joined #linux-sunxi
<wingrime> jemk: mphr - must be mpeg header
<oliv3r> name does make it sound like it
<oliv3r> wingrime: cubie2 yet?
_BJFreeman is now known as BJfreeman
<wingrime> wingrime not uet
<jemk> yes, it contains some data from headers, but i cant figure out the format and where some data comes from
<wingrime> jmek: it must be block size
<wingrime> jmek: I think
<wingrime> jmek: witch function use mphr?
<wingrime> I can take a look with disassembler
tzafrir has quit [Ping timeout: 246 seconds]
<oliv3r> hno: mbus is almost definitaly memory bus
tzafrir has joined #linux-sunxi
<oliv3r> hno: a31 has 2, the ccm suggests 1 just like a1* @ 0x15c, second @ 0x160c
<wingrime> jmek: ping
<jemk> wingrime: dont know, turned off logging functions to not use any direct information from original binary
<wingrime> jemk: ok,
Quarx has quit []
<jemk> wingrime: but bits 31..28 are frame type, so its not blocksize
<oliv3r> lkcl lkcl lkcl!
<wingrime> jemp: have you tryed write ~0 to reg ?
<wingrime> after mpeg init
<wingrime> jemp: that header constain some types
<jemk> wingrime: without correct data there nothing works
<rellla> wingrime, jemk: fyi, here are the newest cedarx-files we got from allwinner:
<wingrime> jemk: also, according traces
<wingrime> jemk: also, there is two types frames
<wingrime> jemk: "long" config and small config between "Wait"
<wingrime> jemk: so according that header : CEDARV_RESULT_FRAME_DECODED = 0x1, CEDARV_RESULT_KEYFRAME_DECODED = 0x3,
<jemk> wingrime: that must be something else
<jemk> frame type means I,P or B
<wingrime> jemk: only I are "full frame"
<wingrime> jemk: like jpeg
<jemk> bits 27..12 seem to be f_code[][] for mpeg2
<jemk> but rest i have no idea
BJfreeman has quit [Quit: had a good time]
<wingrime> jemk: I just checked mpeg4, case
<wingrime> MPEG+0 are not used
<wingrime> MPEG+0x4 look like used for mpeg4 instead
<wingrime> but it 0
<wingrime> f_code are data for VLD?
Soru has joined #linux-sunxi
tinti has joined #linux-sunxi
rzk has joined #linux-sunxi
rz2k has quit [Ping timeout: 264 seconds]
bfree has joined #linux-sunxi
<wingrime> saw this
jukivili has quit [Ping timeout: 264 seconds]
rzk has quit [Ping timeout: 264 seconds]
<jemk> wingrime: thats all only software interface, i cant see any relation with allready known hardware
wingrime has quit [Ping timeout: 246 seconds]
jemk has quit [Ping timeout: 246 seconds]
jukivili has joined #linux-sunxi
naobsd has joined #linux-sunxi
vicenteH has quit [Ping timeout: 246 seconds]
jemk has joined #linux-sunxi
\\Mr_C\\ has quit []
\\Mr_C\\ has joined #linux-sunxi
Soru has quit [Ping timeout: 248 seconds]
vicenteH has joined #linux-sunxi
Soru has joined #linux-sunxi
eebrah is now known as eebrah|away
<hramrach__> hmm, nand driver on a20 cannot be unloaded :/
Soru has quit [Remote host closed the connection]
rz2k has joined #linux-sunxi
<hramrach__> hmm, it crashe in del_gendisk so it might be something I broke :/
Soru has joined #linux-sunxi
hansg has joined #linux-sunxi
<oliv3r> jemk: wingrime: as per request. i think i got most of the info in a table now. didn't move any of the ??? stuff where there's really nothing known.
<oliv3r> Though I have a feeling way know a little more then the RE page shows
<jemk> oliv3r: shouldn't we split up this for the different sub-engines, it'll get very big otherwise
<oliv3r> it is
<oliv3r> but it's also one really big register
<oliv3r> normally we have 1k or 4k of register space
<oliv3r> with only partial use
<oliv3r> now we have 4k of nearly full usage
<oliv3r> though per engine 'split' doesn't sound bad per say
<oliv3r> but once we get some more info entered, we can always split/move it
<oliv3r> erm oops
<ssvb> jemk, oliv3r: probably one page with a short summary for all cedar registers is fine, individual sub-engines may get their own pages with more details
tinti has quit [Quit: Leaving]
<ssvb> I think the PDF documentation for various hardware is typically structured this way
<oliv3r> ssvb: i just went with how I did all the other pages so far
<oliv3r> once we have more info, we can split it up more
<oliv3r> splitting is easy
<oliv3r> writing the shit, is a pain :)
<ssvb> sure :)
<oliv3r> so feel free to split it as you see fit ;)
hglm has joined #linux-sunxi
<hglm> ssvb: I have been looking at the kernel ARM memcpy functions recently...they are slightly out-of-date to put it mildly
<oliv3r> isn't the arm kernel we use slightly out-of-date?
<oliv3r> i mean, we are on 3.0 and 3.4
<hglm> Yeah but upstream there isn't much improvement I believe
<hglm> Some critical functions are still optimized for a 15 year old ARM chip.
<ssvb> hglm: the optimal implementations of memcpy tend to be SoC specific (not even ARM core specific)
<ssvb> hglm: it's hard to make something that is universally good everywhere
<hglm> ssvb: I understand, but there is a lot of room for improvement.
<hglm> For example on the RPi I saw an almost doubling of performance with a few tweaks to memcpy/copy_page, on allwinner memcpy also can go somewhat faster
<ssvb> hglm: to put it mildly, the RPi hardware has a lot of weird quirks, so it is not a very good example
<hglm> And then there is the bug in memset that be the reason newer versions of gcc can't be used to compile ARM kernels like linux-sunxi.
<hglm> ssvb: Yeah I know, the RPi is odd-ball probably because it was never designed to have a general purpose CPU
<ssvb> hglm: to add an insult to injury, RPi was a bit misconfigured originally to have write-allocate enabled for L2 cache (which is not a very good idea because it has different cache line size than ARM core)
tzafrir has quit [Ping timeout: 246 seconds]
<hglm> Did they fix that?
<ssvb> hglm: I kinda saved a guy from tuning optimizations for misconfigured hardware - :)
<ssvb> yes, now L2 write-allocate is disabled by default on Raspberry Pi, but you still can enable it to see how it behaves
<hglm> Regarding the kernel memset bug, that could be worth investigation to see whether it is the reason gcc 4.8+ can't be used to compile linux-sunxi and other ARM kernels. I already fixed it but haven't tried new gcc yet.
<ssvb> in any case, you can already see that any memset implementation performs the same on Cortex-A8 and anything newer (unless you write one byte at a time and CPU itself becomes a bottleneck)
tinti has joined #linux-sunxi
<hglm> Yeah memset easily reaches the maximum unless the code is really dumb.
<ssvb> for memcpy implementations, newer ARM cores also show more consistent performance without the need for special tricks in order not to hit some severe bottleneck
<ssvb> but still you might get some 10% or 20% performance extra
<hglm> ssvb: yeah, the newer ARM cores do automatic predictive prefetching I think.
<ssvb> still Cortex-A7 seems to be an odd ball :-/
<hglm> Yeah that's what I see, you can get 15-20% over standard (glibc for example) memcpy on Cortex.
<hglm> Is Cortex-A7 the dual core used in the A20 and Rockip 3166?
<ssvb> yes, it's the dual core from A20
<hglm> I saw some of your banwidth numbers and at least it doesn't seem to be crippled (some improvement with smae DRAM bus and speed as the A10)
<ssvb> unfortunately I see some problems in pixman microbenchmarks, the difference from memcpy there is that you may want to read from multiple source buffers at a time and write to a different destination
wingrime has joined #linux-sunxi
<wingrime> oliv3r: we not have reverse buffer we have "reconstruct"
<oliv3r> what is 'reconstruct' :)
<oliv3r> it just sounded like a typo, fwd and reconvstruct
<oliv3r> but please do rename if you find an error :)
<oliv3r> i have to go home now :)
<oliv3r> $work is over now
<ssvb> hglm: and the automatic prefetcher in A7 seems to track only a single data stream, based on the description -
<hglm> ssvb: I understand, when the source stride is bigger than the width of the image, the A7 will constantly prefetch data that isn't used...I guess preload instructions won't help to counter that.
<wingrime> oliv3r: bad idea take all regs to one table
<wingrime> oliv3r: we have general regs + engine regs
<oliv3r> wingrime: that is the register LIST
<oliv3r> the register table is below :p
<oliv3r> think of it as an index
<ssvb> hglm: the preload instructions are necessary to get good performance on A7 as the automatic prefetcher seems to be of limited use
<ssvb> hglm: the effectively available memory bandwidth in A20 seems to be much worse than for A10, maybe some special tricks are needed, but I have not figured it out yet
<ssvb> hglm: the cache in Cortex-A7 is write-allocate by default, but can switch to read-allocate mode automatically
<hglm> ssvb: I guess the L2 cache is the main reason (different method due to multiple cores) for the reduction in peak memory bandwidth.
<ssvb> hglm: yes, A20 needs to use SCU, which adds a bit to the latency and makes memory subsystem somewhat more complex
<hglm> ssvb: Still, the dual cores should still make it a lot faster in practical use compared to A10.
<ssvb> sure
<hglm> It helps the X server too (the X server process gets run in parallel and becomes sort of CPU-based accelerator).
<hglm> Does anyone know what the current situation is with respect to the gcc version (linaro for example) used to compile linux-sunxi? gcc-4.8+ doesn't work?
<hglm> What is the reason gcc 4.8+ cannot be used? Is there a known problem?
<ssvb> I believe it is some not quite C standard conforming code in the older kernel code, which gets botched by more aggressive optimizations in gcc 4.8
<ssvb> I may try to fish out some links from the arm-kernel mailing list
<hglm> I was think it might have to do with the ARM memset bug which is related to C-compiler optimizations...
<hglm> The problem is that the assembler memset function has a C prototype returning a void * (not void) that gcc expects to hold the destination address of the memset call following memset specifications.
<hglm> But the assembler memset function doesn't return any sane value.
jemk has quit [Ping timeout: 276 seconds]
<hramrach__> I am using gcc 4.7 from emdebian and it works
<hramrach__> ideally latest gcc should work too but I guess it's OK to use old gcc for old kernel and bother about incompatibility only if such code slips into 3.11
hansg has quit [Remote host closed the connection]
<hramrach__> hmm, linaro seems to be pushing forward gcc versions
<hglm> I will try experiment with compiling the kernel with a newer gcc version -- I have already fixed the memset bug so maybe it will work.
<hramrach__> and 4.8 does not seem to work with as recent kernel as 3.10
jemk has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<hramrach__> hmm, the latter one is supposedly fixed.
<hramrach__> but latter comments speak about kernel code breakage
<hramrach__> seems we should not worry about this until upstream kernel maintainers make the mainline kernel work with gcc 4.8
<hglm> I am now trying to compile the kernel with gcc-4.8, there seems to be a problem with drivers/gpu/mali...but running make again fixes it.
<ssvb> hglm: I think the mali module might be not parallel build friendly and may trigger spurious failures (don't remember if I have seen this information somewhere or it was just my guess)
<ssvb> I never tried to really investigate this issue though
<hglm> hglm: Yeah it seems to be some kind of dependency issue.
<hglm> ssvb: BTW, I used your OProfile patch wih good results on the RPi platform. I do get a "sample buffer overflow" warning now and then.
<ssvb> hglm: oprofile is out of fashion nowadays :) everyone is supposed to use perf
<hglm> ssvb: Well perf only supports hardware performance counters, and OProfile does also support hardware performance counters. But the ARM hardware apparently doesn't.
<ssvb> hglm: adding "-e cpu-clock" option will make perf use the generic timer
mnemoc has joined #linux-sunxi
<ssvb> hi mnemoc!
<hglm> ssvb: Ah, didn't know that about perf.
<bfree> wb mnemoc, hope you're doing well! take care of yourself
<hglm> The zImage produced by gcc 4.8 is 5K smaller than gcc 4.7, proof of better optimization?
<ssvb> it does not mean anything
<hglm> I guess there are a lot of variables in the toolchain etc, and a trivial alignment change would make a big difference, but still zImage is supposed to be pure code.
BJfreeman has quit [Ping timeout: 252 seconds]
<ssvb> it may be just using less aggressive inlining, which could be improving performance or it could be degrading performance
<ssvb> but in any case, my limited tests show that gcc 4.8 is a generally good release for ARM, which brings some nice speedups
<ssvb> (at least for userland code)
<hglm> ssvb: That's good, when I looked at it a few versions back it seemed gcc was broken in performing some trivial loop optimizations etc.
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
tzafrir has joined #linux-sunxi
<Turl> mnemoc: hey! welcome back! :)
jemk has quit [Ping timeout: 246 seconds]
rellla has quit [Ping timeout: 248 seconds]
Superpelican_ has joined #linux-sunxi
<Superpelican_> Hello I have a rebranded Point of View Protab 2 XXL tablet and I'm trying to boot Mer on it
<Superpelican_> As it's a ICS tablet it loads Android with U-Boot
<Superpelican_> So I thought I could let the U-Boot on the NAND also load Mer (or every GNU/Linux distribution)
<Superpelican_> Without building Uboot-sunxi and putting uboot on my sd card
<Superpelican_> However the tablet still boots Android instead of my kernel
<Superpelican_> I've got the linux.ini file that came with the tablet and it cleary says that it boots u-boot.bin, not an bImage
<oliv3r> mnemoc: Hey mnemoc !! welcome!
<Superpelican_> So could someone explain to me whether or not I should add U-Boot to my bootable SD card?
<oliv3r> mnemoc: feeling a little better yet?
<mripard_> mnemoc: welcome back, I hope that you're feeling better :)
<oliv3r> mripard_: see, i'm telling you, he overlooked the binary bit
<mripard_> oliv3r: I don't know, I'm digging in the code right now to figure out how it's actually registered, to get if we can pass the flag that makes it binary anyway
<hramrach__> Superpelican_: technically you can do without making abootable SD card but it's easier that way
<Superpelican_> hramrach__:I've checked uboot-sunxi on Github but it doesn't seem to support the Protab 2 XXL
<oliv3r> mripard_: i did a little poking back then, (mostly because I had to figure out how to write it) but didn't find much
<Superpelican_> hramrach__:Only the Protab 2 IPS
<oliv3r> Superpelican_: i higly higly doubt that
<oliv3r> u-boot is very easy to suport
<hramrach__> Superpelican_: just buil u-boot for random similar tablet
<Superpelican_> hramrach__:I've checked the dram file of the protab 2 ips and the values there are different from those on
<hramrach__> it only needs to get uart and mmc correct
<hramrach__> since you have dram file u-boot can read that and adjust for your tablet
<Superpelican_> what's the dram file
<hramrach__> you just said it's different so you surely have one ;-)
<Superpelican_> actually I just say the values on the page I just linked to above
<hramrach__> but u-boot reads drma parameters from script.bin
<hramrach__> *dram
<Superpelican_> Oh, I do have a script.bin
<Superpelican_> which I extracted with adb from my tablet
<hramrach__> that's probably broken
<Superpelican_> you mean script..bin?
<hramrach__> you need to update the dram parameters in there with values obtained from a10_meminfo
<Superpelican_> the dram parameters in what?
<Superpelican_> in script.fex?
<Superpelican_> My tablet didn't come with a script.fex
<Superpelican_> only script.bin
<hramrach__> the dram parameters are usually incomplete in factory script.bin
<Superpelican_> And I couldn't the fexc program to work
<hramrach__> bin2fex from sunxi-tools
<oliv3r> Superpelican_: PoV_ProTab2_IPS9 is 100% compatible with your tablet
<hramrach__> it works for me both on amd54 and arm
<oliv3r> Superpelican_: use that for u-boot
<Superpelican_> It said "data must follow a section"
<Superpelican_> oliv3r but the meminfo values of the protab 2 ips 9 are different
<hramrach__> maybe it's more broken than usual
<oliv3r> the only different is chip_density
<hramrach__> and that does not matter anyway. u-boot reads that from script.bin
<oliv3r> e.g. protab XXL is 512 MiB; protab 2 is 1024 MiB
<Superpelican_> but you just said that the script.bin is broken
<oliv3r> hramrach__: u-boot reads nothing from script.bin
<hramrach__> how does it set up memory then?
<oliv3r> Superpelican_: ok you may have to add a section for the protab2
<Superpelican_> xxl
<oliv3r> xxl :p
<Superpelican_> So I should create a new dram_pov_protab2xxl.c ?
<Superpelican_> Is that all that is device specific in U-Boot?
<oliv3r> copy dram_pov_protab2.c to dram_pov_protab_xxl.c
<oliv3r> change 'size' to yours and density
<Superpelican_> oliv3r:And aside from a new dram .c file I don't have to add anything device specific?
<hramrach__> there is source for each memory config? /o\
<oliv3r> edit Makefile, add it
<oliv3r> and edit boards.cfg
<oliv3r> add it there too
<oliv3r> for u-boot; that is EVERYthing
<oliv3r> :)
jemk has joined #linux-sunxi
<oliv3r> u-boot only needs dram setup
<Turl> hramrach__: yeah, generated with fexc from script.fex :P
<Turl> (or bin, it doesn't care)
<Superpelican_> Do you mean I should add dram_pov_protab2xxl.c to boards.cfg?
<Superpelican_> and what should I do with script.bin?
<Superpelican_> Do I don't have to put it on the sd card at all?
<Superpelican_> I was able to boot the tinycorelinux image for allwinner a10 just by replacing the script.bin with the script.bin I copied from my tablet
<Superpelican_> So maybe the meminfo is not incomplete in my script.bin
<oliv3r> you generate dram_board.c by hand/from fexc
tzafrir has quit [Ping timeout: 264 seconds]
<oliv3r> but you write have to manually enter the parameters in the script.bin; based ona 10meminfo
<Superpelican_> oliv3r:But what does "data must follow a section" mean
<Superpelican_> I couldn't convert my script.bin to a script.fex
<Superpelican_> I've also tried
<Superpelican_> but that also threw an error
<oliv3r> Superpelican_: check mailing list
<Superpelican_> oliv3r:I might have found the cause of the error
<Superpelican_> oliv3r: it looks like fexc defaults to a .fex file as input
<Superpelican_> oliv3r:And I didn't set the -I and -O flags
<Superpelican_> oliv3r:So fexc probably thought I was giving it a .bin
<oliv3r> probably :)
<oliv3r> you can always use fex2bin and bin2fex
<oliv3r> they are frontends but are assume the appropiate files
<Superpelican_> oliv3r:The name is Protab 2 XXL ;)
<Superpelican_> oliv3r:I've succesfully generated the script.fex
<Superpelican_> oliv3r:Thanks a lot for adding the support
<oliv3r> Superpelican_: renamed and pushed to github; i'll resend to ml
<Superpelican_> oliv3r:Thanks, so I can just clone sunxi-current and make like on the FirstSteps page on
<oliv3r> eah
<oliv3r> Superpelican_: kernel is even less picky
<Superpelican_> oliv3r:I've already compiled a kernel and have an uImage
<Superpelican_> oliv3r: I just used sun4i_defconfig
<Superpelican_> That should work, right?
<Superpelican_> I've changed the screen resolutions in make menuconfig to 1024*600 (res of my tablet)
<oliv3r> might, but the rhombus-tech wiki might be outdated
<oliv3r> linux-sunxi should, in theory be more accurate
<Superpelican_> oliv3r:I followed the rhombus tech page's instructions but compiled from linux-sunxi 3.0 sources :)
<Superpelican_> oliv3r:The script.fex that I generated from the script.bin that came with my tablet indeed has incomplete dram values
<Superpelican_> oliv3r:Should I add the correct values from the Protab 2 XXL page?
<Superpelican_> And generate a new script.bin?
<Superpelican_> for example bus_width, rank_num and density are missing
<oliv3r> Superpelican_: when you extract the script.bin from a device, dram_para is never filled in
<oliv3r> so yeah, you have to fill it in , based on the data from a10-meminfo
<oliv3r> but note, that dram_para, is only used for u-oot
<oliv3r> and that's allready commited to sunxi-current :)
<Superpelican_> oliv3r: what should I set dram_size to?
<Superpelican_> Is that in mb or kb or b
<oliv3r> *facepalm*
<oliv3r> look at the other entries
<oliv3r> but look what i just pushed to github, the values are right there
<oliv3r> mripard_: i really don't follow greg anymore now
<hramrach__> what's the difference between binary and text file?
<hramrach__> for text you use sprintf, for binary you don't
<oliv3r> binary files can have any value for a each byte and strings do not need to end in \0
<hramrach__> but file io is the same
Superpelican has joined #linux-sunxi
<oliv3r> text files require \0 and should only have dec(20) - dec('Z')
<hramrach__> don't you return the number of bytes or something?
<oliv3r> hramrach__: yeah
<hramrach__> so there is no difference. the 0 is just something that you happen to generate with sprintf
Superpelican_ has quit [Ping timeout: 255 seconds]
<hramrach__> actually many text files have tandom junk the vendor filled out as product name
<hramrach__> randome
<oliv3r> anyway, a text file is a special binary file in essence
<oliv3r> :)
<oliv3r> mripard_: the sysfs.txt file says use DEVICE_ATTR; but that takes as attributes _store and _show, the text version
Superpelican_ has joined #linux-sunxi
<hramrach__> oliv3r: how is that text version?
<hramrach__> it becomes text by interpretation - sprintf
<oliv3r> #define DEVICE_ATTR(name,mode,show,store)
<oliv3r> show - store make it textual no?
<hramrach__> but if you use memcpy in show/store it becomes binary
<oliv3r> how does that macro know otherwise?
<hramrach__> the macro does not know
<Superpelican_> oli3vr:It isn't a that weird question, right? After frequency is also set in Hz instead of mHz: "1008000000"
<hramrach__> you return/get the data length
<Superpelican_> *After all
<hramrach__> it can be all 0
<oliv3r> Superpelican_: yeah but we haev many examples :)
<oliv3r> hramrach__: nothing makes me think that way
<Superpelican_> oliv3r:Oh, didn't think of looking up an example ;)
<oliv3r> Superpelican_: but it's on the wiki; the values you need are all there :)
<hramrach__> then memset the page to 0 and return some random number of 0 and see how that works ;-)
<Superpelican_> the dram_size isn't
<oliv3r> hramrach__: we're talkinng about the same sysfs interface right?
<Superpelican_> yeah, 512 mb
<hramrach__> yeah
<Superpelican_> but it doesn't tell me whether I should set the dram_size in mbs, kbs or bytes
<hramrach__> static ssize_t store_name(struct device *dev, struct device_attribute *attr,
<hramrach__> const char *buf, size_t count)
<Superpelican_> 512 mb = 512000000 bytes
<hramrach__> ^^^^^
<hramrach__> count
<oliv3r> hramrach__: i'm looking into the function right now
<hramrach__> that function is *example*
<hramrach__> s/sprintf/memcpy/
<oliv3r> doesn't mention anything int hat sense
sanka has joined #linux-sunxi
<hramrach__> it doe not say anything at all
<mripard_> oliv3r: he seems to imply that it doesn't change anything, if you want binary, memcpy it, if you want string, use sprintf
<oliv3r> so _show magically knows what it has to do
<oliv3r> HIGHLY confusing
<mripard_> "what it has to do" ?
<mripard_> you're the one that implements it
<hramrach__> you *write* show
<mripard_> do whatever you want in it
<oliv3r> well yeah
<oliv3r> but why is there a different between create_sysfs_file and create_sysfs_bin_file if it doesn't matter
<hramrach__> thje latter is undocumented so use the code if you want to know
<oliv3r> i'm searching allready :p
<Superpelican_> oliv3r:It complains with: "fatal: not found: did you run git update-server-info on the server?"
<hramrach__> remove tree
<hramrach__> and later
<oliv3r> Superpelican_: try :)
<oliv3r> Superpelican_: try
<oliv3r> if you use the sunxi-bsp; just git pull
<oliv3r> or cd u-booot and git pull
<mripard_> oliv3r: looking at the implementation, it makes no difference.
<Superpelican_> oliv3r:I've now used hramrach__'s link and added -b sunxi-current flag
<Superpelican_> oliv3r:for Protab 2 XXL support
<oliv3r> mripard_: well it's HIGHYL confusing
<oliv3r> Superpelican_: should work :)
<Superpelican_> oliv3r:Which branch should work?
<Superpelican_> I assume you mean sunxi-current?
<Superpelican_> at least "PoV_ProTab2_XXL" is in boards.cfg
<Superpelican_> so I've got the right branch
<Superpelican_> need to love
<Superpelican_> *leave ;)
<mripard_> oliv3r: well, maybe it's for futureproofness, or for historical reasons.
<Superpelican_> thanks for all the help
<oliv3r> mripard_: I guess ;)
<mripard_> if you feel like it's confusing, send a patch, and see the comments :)
<oliv3r> must be historyical
Superpelican_ has quit [Quit: Quassel was closed]
<oliv3r> mripard_: i hope that it doesn't really 'scan' for memcpy/sprintf, but does some other checks somehow to identify bin/text versions? because I don't need memcpy (nor sprintf)
<mripard_> "scan for memcpy" ?
<mripard_> what are you talking about?
sanka has quit [Quit: Leaving]
tzafrir has joined #linux-sunxi
sanka has joined #linux-sunxi
Superpelican has quit [Quit: Leaving]
<oliv3r> i'm searching through the sources on how it decides which type it is
<techn_> oliv3r: why you commited only sunxi-current?
<techn_> sunxi and sunxi-current has almost same content nowadays
<oliv3r> can do
<oliv3r> i'll cherry pick and commit that one too
<techn_> hmm.. we should rebase sunxi-bsp to point latest sunxi
<techn_> It is working atleast for me :p
<techn_> I have some felboot stuff done for sunxi-bsp, but it starts to be too ugly :(
<oliv3r> hehehe
<oliv3r> i have done some 'mainline' stuff on the bsp
<oliv3r> but that needs heavily commented on :)
<techn_> It starts to require better/wider configuration system.. or something
<oliv3r> yeah
<oliv3r> thanks for voulenteering :)
<techn_> yeah.. I already did some study of bash dialog :p
<oliv3r> :p
paulk-desktop has quit [Quit: Ex-Chat]
<techn_> but then again.. if we add everything there, we could be using bb/yocto
<oliv3r> well we want a system that only setups the proper files
<oliv3r> which crosscompiler, which config file; build all
<oliv3r> i think the bsp does what it needs to do atm quite well
<oliv3r> i'll push my WIP
<oliv3r> (to my personal github)
<oliv3r> hmm, maybe tomorrow; need to do a little to much for it now :)
rz2k has quit []
<oliv3r> mripard_: so if I use DEVICE_ATTR, the .store function can be NULL i hope; but the .show function, can I use exactly the same one? If I use the regular .show function attributes, i miss the rather important 'size' and 'pos' parameters
jemk has quit [Ping timeout: 248 seconds]
<mripard_> are they?
<mripard_> (important)
<oliv3r> well
<oliv3r> yeah
<oliv3r> :p
<oliv3r> pos is what we ask for
<oliv3r> i mean, pos + size is the requested bytes from the eeprom
<mripard_> we're talking about 16 bytes here, right ? :)
<oliv3r> that's hardly the point!
<oliv3r> but yeah :(
<mripard_> anyway, you shouldn't discuss this with me, but with gkh
notmart has quit [Quit: notmart terminated!]
[hawk] has quit [Read error: Operation timed out]
[hawk] has joined #linux-sunxi
<oliv3r> mripard_: also true, but i'll only ask stupid questions
<oliv3r> i feel comfterable with you :)
luka has joined #linux-sunxi
gzamboni has quit [Ping timeout: 240 seconds]
hramrach__ has quit [Ping timeout: 240 seconds]
hramrach__ has joined #linux-sunxi
sanka has quit [Quit: Leaving]
wingrime has quit [Ping timeout: 248 seconds]
andoma has quit [Ping timeout: 264 seconds]
andoma has joined #linux-sunxi
hglm has quit [Quit: leaving]
gzamboni has joined #linux-sunxi