mnemoc changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at
Renard has quit [Read error: Connection reset by peer]
jinzo has quit [Quit: Leaving]
Faisal has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.0]
Andy-D has quit [Ping timeout: 260 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
mmarker has joined #linux-sunxi
eagles0513875 has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
ccube has quit [Remote host closed the connection]
ccube has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
eagles0513875 has quit [Ping timeout: 246 seconds]
froese has quit [Ping timeout: 252 seconds]
physis_ has joined #linux-sunxi
physis has quit [Ping timeout: 240 seconds]
zeRez has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
zeRez has quit [Ping timeout: 272 seconds]
physis_ has quit [Remote host closed the connection]
bengal has joined #linux-sunxi
zeRez_ has quit []
zeRez has joined #linux-sunxi
sehraf has joined #linux-sunxi
lerc has quit [Ping timeout: 268 seconds]
bertrik has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
zeRez has quit []
lerc has joined #linux-sunxi
cubear has joined #linux-sunxi
bonbons has joined #linux-sunxi
<oliv3r> bbl
oliv3r has left #linux-sunxi [#linux-sunxi]
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
netlynx has joined #linux-sunxi
<hramrach> is there any use for meminfo dump from a23 tablet?
oliv3r has joined #linux-sunxi
<wens> not yet i suppose
<wens> libv made it to dump all the dram related registers, which is a lot
konradoo87 has quit [Ping timeout: 276 seconds]
konradoo77 has joined #linux-sunxi
deasy has joined #linux-sunxi
MY123 has joined #linux-sunxi
Renard has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 252 seconds]
konradoo77 has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
<oliv3r> wens: for a23?
<oliv3r> i made an meminfo-a31 once, but since ha lacked hardware, i gave up on it real quick :)
<oliv3r> it's a branch on my githubs a10-meminfo fork
oliv3r has quit [Quit: Lost terminal]
Faisal has quit [Ping timeout: 246 seconds]
<netlynx> Hi all. Is there more documentation and or information available on the TV IN on the A20? (CVBS inputs on the A20). I have not found it on
Quarx has joined #linux-sunxi
oliv3r has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
konradoo77 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
Andy-D has joined #linux-sunxi
jinzo has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 252 seconds]
konradoo77 has joined #linux-sunxi
Renard has quit [Remote host closed the connection]
froese has joined #linux-sunxi
ganbold_ has quit [Quit: Leaving]
ganbold_ has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
MY123 has quit [Ping timeout: 246 seconds]
physis has joined #linux-sunxi
Andy-D has quit [Ping timeout: 255 seconds]
Andy-D has joined #linux-sunxi
<heffer> libv: thanks for your help on the wiki page. i've added the external photos plus a photo of the remote now as well
quitte_ has joined #linux-sunxi
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
quitte has quit [Ping timeout: 272 seconds]
konradoo77 has quit [Ping timeout: 245 seconds]
jemk has joined #linux-sunxi
MY123 has joined #linux-sunxi
MY123 has joined #linux-sunxi
Renard has joined #linux-sunxi
physis has quit [Remote host closed the connection]
<libv> hramrach: yes, we need the dumps
<libv> hramrach: i will try to send an email in a few h
physis has joined #linux-sunxi
<libv> hrm, no gpio pins needed for usbc1... our sunxi-3.4 hiccups over that
<wens> huh?
<wens> reminds me of my a13 tablet :p
<libv> but that is the same as the pineriver_h25 :(
<libv> both should oops the kernel
<libv> i get round it by disabling the usbc in the .fex
<wens> put an unused gpio in
<wens> like power203
hramrach has quit [Remote host closed the connection]
hramrach has joined #linux-sunxi
physis has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 268 seconds]
Andy-D has joined #linux-sunxi
<libv> yup, looks good
<libv> thanks, i should go and fix the code to not crash and burn on an empty usb_drv_vbus_gpio
<libv> heffer: now for some patches :)
<heffer> libv: yes. working on it :)
<libv> :)
<heffer> i will submit a patch for the 512 MB ram version only because i don't have the 1GB version
<libv> heffer: yeah, sounds like a plan
<libv> but...
<libv> here's a little secret
<libv> uboot detects how much ram is there
<libv> the value is not used
<mnemoc> o_O
<heffer> okay. i won't tell anyone ;)
<libv> so if the layout is the same, and the timing is the same, there is no difference
<libv> but start with no appendix to the names indeed
<heffer> so just submit the patch and fix it later in case the 1GB layout should be different?
<heffer> ah okay
<libv> and add _1g for the 1gb version
<libv> if a change is needed
<libv> mnemoc: take a 512 mb device
<libv> mnemoc: edit the dram para to read 1024
<libv> mnemoc: see uboot detect 512
<libv> code told me that upon the tpr4 changes for meminfo
<libv> and yesterday i messed that up on my new a10s device and uboot did the right thing
lerc has quit [Ping timeout: 260 seconds]
<mnemoc> what if it's the other way around? setting 512 on a 1G?
<libv> should also just work
<libv> the size parameter is never used
<mnemoc> interesting
<libv> just the 1-2GB SOC max define is used
<heffer> libv: patches against mainline u-boot are preferred or no?
<libv> heffer: patches to our sunxi uboot first
<libv> learn to run first
<wens> and then fly? :p
<libv> :)
<heffer> libv: the projects i usually contribute to prefer patches upstream and then pull changes downstream so i was unsure
<mnemoc> mortals walk and then run. libv starts running
<heffer> :D
<libv> i am a theoretical member of a gliding club :)
<libv> i am too fat to fly :)
<heffer> like bumblebees?
<mnemoc> :D
deasy has joined #linux-sunxi
<libv> heffer: u-boot-sunxi is our own tree with all sorts of things that are not upstream
<libv> heffer: like, ~100 devices
<libv> and i really am too fat to fly, 105kg weight limit on the front seat of an ask-21
<heffer> ah, okay :)
<libv> and i am a terrible runner as well :p
<libv> so i should've actually stated the proper proverb :p
<heffer> a friend of mine always wants to take me an a trip on a WT-9 Dynamic but together we wouls also bust the maximum takeoff weight
<libv> :)
<libv> my old man wants to get a ultralight license... 85kg weight limit in .be, and he's really struggling :) If i weighed that much, people just wouldn't recognize me anymore
<heffer> but i from what you say i still could go on the front seat of an ask-21 and take a small dog with me :D
<libv> :)
<libv> you should see the others, they're often middle aged germans with big round bellies, and they are able to fly, it's just not fair :)
konradoo77 has joined #linux-sunxi
<heffer> other than the middle aged thing that description would probably be accurate for me ;)
<libv> :)
deasy has quit [Remote host closed the connection]
wingrime has joined #linux-sunxi
<DagoRed> Ugh... I found out ALARM doensn't have the HDMI support for it out of the box... I think I need to get that set up for the iteaduino's at lease.
<DagoRed> *least
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
moofree has quit [Ping timeout: 245 seconds]
<DagoRed> 0
<wingrime> jemk: are you finaly fixed interlanced?
<jemk> wingrime: yes, it should decode fine now. deinterlace still not possible, disp is very limited there
<ssvb> libv: the size of dram is determined by bus width and chip density, the 'size' parameter works more like a comment in the 'dram_para' struct
<ssvb> libv: and even the bus width and chip density can be runtime detected (in the mainline u-boot but not in u-boot-sunxi)
tgaz has quit [Ping timeout: 268 seconds]
tgaz has joined #linux-sunxi
<wingrime> jemk: cool
<wingrime> jemk: and some news about a80 , it may be possible, but kernel part of cedar are untouched, so thats means we not get any new sub engine
<wingrime> jemk: that means h265 is included to some engine and on other side it can be implemented on top of GPU
<jemk> ssvb: any reason why you fixed ve reserved mem size to 80mb in the cma patch and not use the ve_mem_reserve parameter? because the vdr people have problems with too little ve memory now...
<jemk> wingrime: I'm pretty sure h265 is gpu based, sadly
<ssvb> jemk: because the 80MB hardcoded limit was originally used by the Allwinner kernel
stingray454 has quit [Remote host closed the connection]
<ssvb> jemk: and the kernel cmdline parameters were typically (ab)used to reduce memory footprint, sometimes causing troubles for the users
Quarx has joined #linux-sunxi
<ssvb> jemk: how much would be enough for everyone? can the userland application potentially estimate its memory requirements and communicate this to the kernel?
<jemk> ssvb: well, 80mb should be enough for video decoding, but vdpau gets the memory for g2d from that area too, and thats too much
paulk-aldrin has quit [Quit: Ex-Chat]
<ssvb> jemk: ok, do you have a better estimate for the cedar reservation size?
<ssvb> jemk: I don't quite like these kernel cmdline parameters, because they were a band aid for the absence of flexible memory allocation
deasy has joined #linux-sunxi
<ssvb> jemk: the users should not normally have any need to touch these
<jemk> ssvb: isn't cma meant to be used for allocating memory at runtime?
<ssvb> jemk: yes
<ssvb> jemk: which reminds me that I have a few patches, which I never sent to the mailing list yet
konradoo87 has quit [Ping timeout: 264 seconds]
Andy-D has quit [Ping timeout: 245 seconds]
<wingrime> jemk: don't forget you use that memory only for one frame
<jemk> ssvb: i can't really give a value that suits every need, and if i could it would be that high that i wouldn't want to lose that much memory if i don't need it
konradoo77 has joined #linux-sunxi
<libv> looks like a rename is in order :)
<libv> s/sunchip/easitek/
<wingrime> ssvb: if cedar regs configured right way, cedar hw have special irq code when it out of mem
<jemk> wingrime: ? what do you mean, all decoded reference frames are in that memory
<jemk> wingrime: no?!
<wingrime> jemk: I taking about, that blob can copy stream part to lin-mem
<jemk> wingrime: when the input buffer ends it can trigger an irq, but the main memory usage comes from the decoded pictures
<ssvb> jemk: we can change the driver to have cedar memory allocated only during the time when it is opened/mmapped, and then add a new ioctl to change the allocation size at runtime
<wingrime> jemk: yeax , 80mb is pretty big
<jemk> wingrime: the input buffer is only 1mb, which is enough for everything
<wingrime> jemk: not in 4k case
<ssvb> wingrime: but now jemk complains that 80mb is too small :)
<wingrime> jemk: how much reference planes are required ?
<wingrime> ssvb: on demand are nice, but not in android case, video should not breakes when no mem are free
<jemk> wingrime: depends on stream, up to 16 in h264
<wingrime> if video is 1920 that means frame will require ~1.3 Mb
<wingrime> oh
<wingrime> 1920*720*4
<wingrime> in a8r8g8b8 case
<wingrime> ~7 Mb
<wingrime> 88473600
<wingrime> when it 16
<wingrime> ~88 Mb
<wingrime> allwinner is near
<wingrime> but ARGB is not true )
Andy-D has joined #linux-sunxi
<jemk> ssvb: oh, must have missed that. that could be a solution, after changing it to use cma. but is it a good solution?
<wingrime> ssvb: is not there more one solution for it
<wingrime> ssvb: thre some ion allocator
<ssvb> jemk: right now every driver (cedar, g2d, ...) is implementing its own memory allocator in the sunxi-3.4 kernel, that's a duplicated code
<ssvb> jemk: as you said, the 80mb limit had been exceeded because of the extra memory requirements for g2d
<ssvb> jemk: I'm not sure if it is a good solution (nothing in the sunxi-3.4 kernel is a good solution), but probably could be somewhat usable
<wingrime> ssvb: cma can do memory defrag when it required for allocate?
<ssvb> wingrime: no
<wingrime> sad
<MY123> The KMS memory allocator may be good.
<MY123> (Intel graphics have shared mem and uses that)
<ssvb> wingrime: it can only move away 'normal' pages to free space for the physically contiguous buffers
<ssvb> wingrime: but the already allocated physically contiguous buffers may be fragmented themselves
<libv> MY123: the kms memory allocator is pretty hairy
<ssvb> wingrime: in any case, being able to move the buffers potentially opens a big can of worms
<ssvb> wingrime: for example, how do you communicate to the cedar userland code that the kernel wants to move the buffer under its feet?
<ssvb> wingrime: right now we can just pretend that the fragmentation problem does not exist
<wingrime> ssvb: give kernel side pointers to userland is always bad
<libv> cma
<wingrime> better think about implement mem2mem v4l2 driver
<ssvb> wingrime: yes, please do this :)
<wingrime> jemk: are you tryed some?
<jemk> i thought about that, but it would require parsing video headers in kernel space... I guess thats a bad idea.
<ssvb> cedar support in sunxi-3.4 and cedar support in the mainline kernel are somewhat different topics
<wingrime> jemk: and there DRM way
<ssvb> wingrime: the low level implementation for the physically contiguous memory allocation is CMA, the other frameworks are built on top of it
<wingrime> libv: are you thinked about cedar ?
<MY123> wingrime: I think embedding the full lib in the kernel and using RPC is the ultimate solution. :P
<ssvb> wingrime: at least for ARM hardware and when we have no IOMMU
<wingrime> MY123: scripting in kernel ))
<wingrime> MY123: like ACPI ))
<MY123> wingrime: Or UEFI.
<MY123> (which works on ARM)
<libv> MY123: aren't you the owner of the kurio 7s?
<MY123> libv: Yes.
<MY123> (and a Cubieboard2)
<MY123> Graphics-wise, I don't understand how eglImage should be implemented for Android.
<libv> MY123: did you ever get the kurio going?
nove has joined #linux-sunxi
<nove> (the talk is more interesting when i can't idle)
<nove> jemk: wingrime, just saw last week this
<nove> the last topic at the end of the page
<nove> if i am not mistaken, that discussion was caused because of oliv3r asking in the #v4l maillist
<ssvb> nove: unfortunately the mainline people have no real pressure to deliver any products and can keep bikeshedding forever
<jemk> nove: thats exactly what i feared. for jpeg/mpeg12 it could work, but h264 is too complex
<nove> jemk: wingrime, but what it says instead of using as example V4L2_PIX_FMT_H264 for input, we would create a costum format V4L2_PIX_FMT_CEDAR_H264(original bitstream + preparsed info)
ricardocrudo has quit [Ping timeout: 272 seconds]
<jemk> nove: possible, but v4l2 is a nice, simple to use api. if every soc needs extra pix_fmts it gets a mess
<nove> jemk: then libv4l could have a api to abstract this
<jemk> should != has
Faisal has joined #linux-sunxi
mawe242 has joined #linux-sunxi
<nove> jemk: we are the first, and it looks that discussion was really caused by us
<MY123> For me, V4L should not manage video encoding. That should be managed by ffmpeg.
<wingrime> jemk: heh, but cedar not going change so quickly
<wingrime> jemk: I only figured out that they added direct Yvu decoding (no tiled)
konradoo77 has quit [Ping timeout: 246 seconds]
<wingrime> cedar is realy reqired for best opensource SoC
konradoo77 has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
mawe242 has quit [Quit: Leaving]
eagles0513875 has joined #linux-sunxi
wingrime has quit [Ping timeout: 245 seconds]
naobsd has quit [K-Lined]
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<diego71> ssbv: ping
netlynx has quit [Remote host closed the connection]
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<hramrach> ssvb ...
<diego71> ops
<ssvb> hi diego71
<diego71> ssvb: hi. I'm the one who make experiments with dram settings on a a20-olinuxino-micro
konradoo77 has quit [Ping timeout: 276 seconds]
<diego71> ssvb: I've a spare a2
<diego71> a20 to make test, so if you need some other test, I can make them....
<ssvb> diego71: that's great, thanks
<ssvb> could you paste your current a10-tpr3-html-report to the linux-sunxi wiki and also try different 'emr1' settings?
popolon has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
<diego71> ssvb: ok. Is there some value of emr1 to test first?
<ssvb> diego71: different Rtt_Nom values may result in rather major changes in reliability, "Output driver impedance" is less important
<ssvb> diego71: so you can try to compare 0x0, 0x04 (that's what you have now), 0x40 and 0x44
<ssvb> diego71: 0x0 is less likely to be good, but it's hard to predict anything about the other values
<ssvb> diego71: what is the revision of your board?
<diego71> ssvb: rev E
<diego71> ssvb: actually I have to board rev E, but with different ram chip
<ssvb> diego71: so this is a board with the 330 ohm RZQ resistor (the DDR3 SPEC suggests 240 ohm), maybe larger Rtt_Nom divisors are expected to work better?
<diego71> ssvb: like 0x44?
<ssvb> diego71: or maybe OLIMEX has changed the nominal of this resistor on purpose, specifically to make it work better with the /4 divisor?
<ssvb> diego71: yes, trying 0x44 would be a good test
<diego71> ssvb: ok, I start with 0x44...
Andy-D has quit [Ping timeout: 260 seconds]
<ssvb> diego71: can you upload your current results to the wiki?
<diego71> ssvb: do you prefer a new wiki page or should I use an existing one?
<ssvb> diego71: let's see what kind of structure would best to have
<diego71> nb: at the moment the report.html is 204Kb long... a lot of test, and also dqs_gating_delay randomly changing after some hard reset
<ssvb> diego71: I have created a wiki page here -
Andy-D has joined #linux-sunxi
<ssvb> diego71: you should probably go to the "Olimex A20-OLinuXino-Micro Rev.E" page and create a link to something like "DRAM Calibration Results/Olimex A20-OLinuXino-Micro Rev.E/diego71" and paste your results there
<hramrach> would it work to upload the result file and link to it from the wiki page>?
MY123 has quit [Quit: Quitte]
<hramrach> the mediawiki can store files but not sure if linking to html would work
<ssvb> diego71: about the big html file, you can go to the a10-tpr3-scan results directory and pick the subdirectory with the most interesting results
<diego71> ssvb: like 432Mhz setting that looks stable....
<ssvb> diego71: yes
<ssvb> diego71: and "dqs_gating_delay" indeed may change on every reboot -
<ssvb> diego71: that's why it's a good idea to hardcode it in the dram_para struct to some known reliable/most common value
<ssvb> diego71: but this is only supported in the mainline u-boot
<diego71> ssvb: in my tests seems stable on normal reboot, bu changing after reset...
<diego71> ssvb: also... I'm doing test using the linux-sunxi version of uboot. Should I use mainline one?
<ssvb> diego71: yes, mainline u-boot is better, but it does not work with sunxi-3.4 kernel as-is
<ssvb> diego71: and sunxi-3.4 is needed for lima-memtester
<ssvb> diego71: I'll provide an updated u-boot branch later (maybe today)
<ssvb> diego71: testing 'emr1' should be fine with u-boot-sunxi, except that the random changes of "dqs_gating_delay" may be indeed annoying
<ssvb> hramrach: the mediawiki setup at linux-sunxi supports html markup, so just a html chunk can be pasted into the wiki directly
<ssvb> diego71: naturally, if we want to see the effect of changing 'emr1', everything else but 'emr1' needs to be the same for two different runs of a10-tpr3-scan
<ssvb> diego71: oh, and the 'tpr3' value gets automatically changed, so the initial value from u-boot also does not affect the test results (but the initial 'tpr3' is best to be picked in such a way, that it is stable enough to boot the system)
lerc has joined #linux-sunxi
petr has quit [Ping timeout: 272 seconds]
nove has quit [Quit: nove]
<diego71> ssvb: result.htmlpasted ...
petr has joined #linux-sunxi
<ssvb> diego71: thanks! though it seems to be a bit cut off
<ssvb> diego71: the terminating html tags seem to be missing, maybe this causes it to show "<tbody></tbody>"
<diego71> ssvb: I suspect I had used an old version of your tools
<ssvb> diego71: ok
<diego71> ssvb: I'm going to fix it later. atm is good enough :)
<ssvb> diego71: yeah, it's fine
<ssvb> diego71: we will figure out how to best structure the data after we have more test results :)
<ssvb> diego71: btw, this estimates the performance difference between various dram settings -
<ssvb> diego71: your current setup with 432MHz DRAM / 300 MHz MBUS is the first result in the table :)
<diego71> ssvb: I've not tested FAST_MBUS configuration, because during the first test, with fast mbus is non stable enough
konradoo77 has quit [Ping timeout: 268 seconds]
<diego71> (like crashing gcc while compiling u-boot... doh!)
konradoo77 has joined #linux-sunxi
<ssvb> diego71: increasing the dcdc3 voltage usually helps with the MBUS clock speed, but picking the right 'tpr3' and other settings is also important
<ssvb> diego71: are you compiling u-boot on the board itself?
<diego71> ssvb: yes, so I don't have to change the sd (except when something go very wrong)
<diego71> ssvb: I use a small script that update u-boot on the sd, and then reboot
<ssvb> diego71: ok
<ssvb> diego71: in any case, if you got reliability problems with gcc compilation, then lima-memtester should have been able to detect the problems in that setup too
<diego71> ssvb: i think so, but I didn't even tried. And in that moment, I was not sure what FAST_MBUS was about.
<ssvb> diego71: it would be really bad if gcc is unstable, but lima-memtester can't see any problems (so we need to keep an eye on that too)
<diego71> ssvb: when in the future, I'll try to increase mbus clock again, there is preferred way to do it?
<ssvb> diego71: FAST_MBUS means 400MHz MBUS clock speed in u-boot-sunxi
<ssvb> diego71: and the mainline u-boot just has 'mbus_clock' property in the 'dram_para' struct
jemk has quit [Quit: leaving]
<diego71> ssvb: and atm I can't use mainline uboot, because I need kernel 3.4 for lima-memtest, right?
<diego71> goodnight
yann_s has quit [Quit: ZNC -]
bonbons has quit [Quit: Leaving]
<ssvb> diego71: yes, the mainline u-boot needs a couple of patches
<ssvb> diego71: goodnight, see you around later
cubear has quit [Quit: Leaving]
<ssvb> libv: are any changes needed in the sunxi-3.4 kernel to work nicely with the u-boot display driver?
<libv> ssvb: it's been soo long, i don't really remember :)
<libv> yes
<libv> it needs to know where the memory lives
<libv> so i nastily introduced some logic to see whether < 16MB was missing off the top of ram
<libv> also, sun7i clock early pll setting needed to be neutered
<ssvb> yeah, it probably does not care and just wants to shut down the clocks and reclaim the memory?
<libv> no, it doesn't reclaim the memory
<libv> and no, it does not shut down the clocks either
<libv> on sun7i, some extra fex parsing code was added which set default (fex provided) values for some plls
<ssvb> what would be the expected behavior that we want?
<libv> ...
<libv> please rephrase
<ssvb> we can add some changes to the sunxi-3.4 kernel
<hramrach> well, it's different from what mainline does. on mainline the clocks are supposed to be left alone but 3.4 would set ehm based on fex?
<libv> hramrach: sunxi-3.4 only does so for sun7i
<libv> ssvb: yes, and i have some patches sitting around for myself, as i wanted to try this code on my a10s stick
<ssvb> libv: so I just wonder if we need or want to do anything to make it more u-boot video driver aware?
<ssvb> ok
<libv> ssvb: what is the point of having this on sunxi-3.4?
<libv> ssvb: i wanted it for early printk and uboot console myself
<libv> but it was pointless, i should've used fel booting from the start and oggled the usd
Gerwin_J has joined #linux-sunxi
<ssvb> I mean, I want to have u-boot with the video driver support, and I want to be able to use this u-boot with sunxi-3.4
<libv> you can, but you just lose 8mb
<ssvb> if sunxi-3.4 can shut down the clock and reclaim memory, that would be perfect
<ssvb> and then use the disp driver just like usual
<libv> ssvb: this simplefb stuff really is everything but simple, now is it
<libv> and the reason why there was such a big discussion is the fact that the sunxi code showed very clearly that simplefb is a lie
<libv> it really is denialfb
<ssvb> there is no simplefb in sunxi-3.4, right?
<libv> and people are still in denial
<libv> ssvb: it's trivial to add
<libv> it's simple, remember :p
<ssvb> but we probably don't want to, because we already have the disp driver
<ssvb> and the earlyprintk is probably not worth the efforts
<ssvb> not much further kernel development is expected on the sunxi-3.4 branch (unless somebody starts merging sun6i stuff), and we already have the serial console
<libv> well, the whole thing feels like it was not worth the effort tbh
<libv> u-boot is horribly retarded about anything this millenium
<libv> and on top of that it treats the cfbconsole pretty stepmotherly
<libv> so you don't really get a console early
<libv> you have to load an env before it tries to get you a console
konradoo77 has quit [Ping timeout: 245 seconds]
<libv> so this whole thing is only half as useful as it is supposed to be
<libv> and then this whole useless endless discussion because people got shown that simplefb is a lie
Zboonet has quit [Remote host closed the connection]
<hramrach> at least if u-boot does not fail it should show you kernel messages
<hramrach> and since it should be possible to get known-working u-boot for most devices it's not that bad
bluse_ has quit [Ping timeout: 268 seconds]
mnemoc has quit [Ping timeout: 246 seconds]
Uninstall_ has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 264 seconds]
bluse has joined #linux-sunxi
ccube has quit [Quit: changing servers]
Uninstall has quit [Ping timeout: 268 seconds]
ccube has joined #linux-sunxi
dl9pf has quit [Quit: No Ping reply in 180 seconds.]
dl9pf has joined #linux-sunxi
dl9pf has quit [Changing host]
dl9pf has joined #linux-sunxi
mnemoc has joined #linux-sunxi
kelvan has quit [Ping timeout: 260 seconds]
kelvan has joined #linux-sunxi
rnp has joined #linux-sunxi
mnemoc has quit [Ping timeout: 245 seconds]
mnemoc has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<ssvb> libv: I'm too sleepy now to do anything useful right now, but we need to prepare a usable branch for u-boot v.2014.10
<ssvb> libv: first of all take care of the landmine that I left there - and also neuter the PSCI stuff for sunxi-3.4
<ssvb> libv: we can start even without the u-boot display driver, but IMHO it also should be also added later
bertrik has quit [Remote host closed the connection]
lynxis has quit [Remote host closed the connection]
bluse has quit [Ping timeout: 268 seconds]
RaYmAn has quit [Ping timeout: 245 seconds]
ccube has quit [Quit: changing servers]
kelvan_ has joined #linux-sunxi
kelvan has quit [Ping timeout: 260 seconds]
mnemoc has quit [Ping timeout: 240 seconds]
Uninstall_ has quit [Ping timeout: 272 seconds]
Andy-D has quit [Ping timeout: 255 seconds]
<libv> ssvb: ok
<libv> ssvb: who did the last u-boot backport?
<libv> or whatever that port should be called.
bluse has joined #linux-sunxi
RaYmAn has joined #linux-sunxi
RaYmAn is now known as Guest85650
bengal has quit [Quit: Leaving]
Andy-D has joined #linux-sunxi
mnemoc has joined #linux-sunxi
Uninstall has joined #linux-sunxi
Uninstall has joined #linux-sunxi
andoma has quit [Ping timeout: 245 seconds]
sehraf has quit [Quit: ... be part of it...]
jinzo has quit [Quit: Leaving]
andoma has joined #linux-sunxi
moofree has joined #linux-sunxi
Renard has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
akaizen has joined #linux-sunxi
Guest85650 has quit [Ping timeout: 276 seconds]
quitte_ has quit [Ping timeout: 245 seconds]
naobsd has joined #linux-sunxi
RaYmAn_ has joined #linux-sunxi
quitte has joined #linux-sunxi
akaizen has quit [Ping timeout: 272 seconds]
akaizen has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
rnp has left #linux-sunxi [#linux-sunxi]
FDCX has quit [Ping timeout: 272 seconds]
Andy-D has quit [Ping timeout: 276 seconds]