<libv>
btw, cubieboard.org now has a subtitle "a series of open source hardware"
montjoie[home] has quit [Quit: leaving]
<Turl>
libv: for some reason that site keeps shrinking
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<libv>
i somehow feel that we shouldn't be expecting too much support anymore from that side
montjoie[home] has joined #linux-sunxi
netlynx has quit [Quit: Leaving]
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
popolon has quit [Quit: Quitte]
kivutar has quit [Quit: Ex-Chat]
paulk-collins has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
rz2k has quit [Read error: Connection reset by peer]
<BorgCuba>
hi, has somebody experience using "mdev"?
<BorgCuba>
libv, I have to ask, whats going on with lima/limare/mesa/compiler?
<libv>
nothing.
<BorgCuba>
too bad
<BorgCuba>
you need any help?
Black_Horseman has joined #linux-sunxi
<libv>
heh
<libv>
ssvb: uboot and graphics is pretty broken
<libv>
the lcd display driver "interface" is only for displaying a splashscreen as i can tell, and there is no way of telling it "no, we didn't find a monitor, so we should not be used"
<libv>
the edid code is braindead
<libv>
it's like X up until 2005
<libv>
(which is when i fixed X to use edid)
<libv>
so that's dead weight too
<libv>
my best bet now is to see if i can get any use out of the cfbconsole driver
<libv>
perhaps get the serial output showing properly, as it only shows the denx logo and then prints uboot info and then nothing
<libv>
sunxi-3.4 fucks up the dotclock, and i cannot seem to find the access to the dotclock register that does it, suggesting that a more general ccmu change resets the dotclock behind our backs, giving us no sane way of reinstating it
<libv>
so there will need to be a full disabling of the display engine in our platform code
Quarx|2 has joined #linux-sunxi
Quarx has quit [Ping timeout: 250 seconds]
wingrime has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
deasy has joined #linux-sunxi
<ssvb>
libv: is it perhaps just a minor configuration tweak missing? something like changing the log output target from the serial to the display (or mirror the output to both)?
<libv>
for cfb, yeah, i guess so, i was about to look into that
<ssvb>
as for the platform code update in sunxi-3.4, it should not be a big problem (as long as you know what needs to be done)
<ssvb>
the right solution is probably to just invent new machine id numbers and use them both in the updated u-boot and in the new sunxi-3.4 kernel
<ssvb>
it means that the old sunxi-3.4 kernel will refuse to boot with the new u-boot, telling that the machine id is wrong
<libv>
in the pll5 case, my engines seem happy at 300MHz
<libv>
although, i am not sure whether i tested all of them
<libv>
i think that debe has code where it halves if higher than 300MHz
<ssvb>
the code in sunxi-3.4 deals with the divisors quite poorly
<libv>
i really dislike refusing to boot
<ssvb>
it is better than exhibiting obscure bugs at runtime, or clocking the hardware way too high
<libv>
right
<libv>
ah, only debe in my sunxi_kms code needs pll5
<libv>
everything else is pll3/7 which is reserved for graphics anyway
<libv>
ssvb: could the debe bandwidth/caching issue you have been seeing be related to the pll5 setting?
<ssvb>
unlikely, I already have the sunxi-3.4 pll5 related fixes, and experimented with the pll5 divisor in debe
<libv>
ok
<ssvb>
have you tried to boot the mainline kernel?
<libv>
nope
<ssvb>
ok, I guess it should work fine with minimal changes
<libv>
s/fine/just as badly as sunxi-3.4/
<libv>
i need to find out what resets the dotclock pll
<ssvb>
well, for the mainline kernel we need to ensure that the right information is passed via DT (but this already works for PSCI, so should not be a problem)
<ssvb>
about the pll reset, maybe mripard_ or Turl can help
<ssvb>
libv: what happens if you just disable PLL3/7 by clearing bit 31 in PLL3_CFG_REG and PLL7_CFG_REG?
<libv>
ssvb: for display engine reset, you mean?
<libv>
i will be a tiny bit smarter about that, involve ahb1, dram and the engines on their own as well
<ssvb>
ok
<ssvb>
as long as it works
<libv>
won't be more than a dozen or so register writes and just a few reads (only ahb1 really)
<ssvb>
if you have some preliminary code, I could test it
<libv>
s/if/when/
<libv>
currently still thinking things through
afaerber_ is now known as afaerber
<libv>
heh, true color is the only dependable option for simplefb it seems, why did they chose to only think about 32bit colour afterwards?
<libv>
it's not as if it would've required much more thinking or infrastructure.
<libv>
hah, rpi
<ssvb>
32bit color is ok
<ssvb>
and btw, the raspbian distro is afaik using 16bpp by default :)
paulk-collins has quit [Ping timeout: 240 seconds]
<libv>
right, it seems to be overwritten
<Turl>
it doesn't probe if you leave it out
paulk-collins has joined #linux-sunxi
<ssvb>
libv: in any case, if you can initialize the display hardware good enough for showing a logo in u-boot, then simplefb might be already half-way ready
<ssvb>
does anyone have any idea where the simplefb framebuffer memory is getting reserved in the kernel?
<ssvb>
ok, it's IORESOURCE_MEM
<libv>
aha, i have input over serial, but output over hdmi
<libv>
this cfbconsole stuff is really only meant for ancient pc based hw
<libv>
it will not play well with usb keyboards.
<libv>
ah, this should be defined by config
kivutar has joined #linux-sunxi
<wingrime>
ssvb: how your one week challenge?
<ssvb>
wingrime: if you have not noticed, libv is working on the u-boot video driver :)
<wingrime>
Cool
<libv>
s/working on/complaining about/
ricardocrudo has joined #linux-sunxi
<wingrime>
libv: thats realy task critical for sunxi
<ssvb>
wingrime: I still have to take care of the dram controller and the unified single u-boot binary support for sun4i/sun5i/sun7i devices during the remaining week :)
<wingrime>
*mission critical
<libv>
wingrime: why so?
<wingrime>
ssvb: you intend make some dram auto detect?
<ssvb>
wingrime: dram auto detect already works
<libv>
wingrime: most platforms get by without display, as it seems that the other display driver is only about showing a splash screen
<wingrime>
libv: video , it's major thing that make use trash aw kernel
<wingrime>
*user
<wingrime>
ssvb: with timings?
<ssvb>
wingrime: the DDR3 standard from JEDEC specifies speed bins and the timings for these speed bins
<ssvb>
wingrime: the DDR3 chip manufacturers are surely allowed to provide better timings than mandated by the spec, but targeting the timings of the slowest standard speed bin should work everywhere
<wingrime>
ssvb: i mostly about , if some trace length differs from others, bit can be recived inverted
<wingrime>
Thats can limit dram clocks
<wingrime>
And about optimal dram clock
<ssvb>
all the dram settings for sunxi devices are very poorly configured, one can hardly do a worse job :)
<wingrime>
Code must do as well
<wingrime>
Not manualy
<wingrime>
Ssvb: we have some better dramc docs than from rockchip?
<ssvb>
wingrime: yes, linux-sunxi wiki
<wingrime>
)
<wingrime>
ssvb: are you detect bus width and chip count?
<libv>
now wonder that they are using switch statements pointlessly
<libv>
it should have multiple consoles though, so cfb_console must have messed up somewhere, or my config is off
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<libv>
aha, CONFIG_CONSOLE_MUX
jemk has quit [Quit: Lost terminal]
<libv>
heh, so much for that.
<libv>
as this of course can only be set from env
issue_ has joined #linux-sunxi
Nazcafan has joined #linux-sunxi
Nazcafan has quit [Quit: Quitte]
T0mW has joined #linux-sunxi
<T0mW>
I'm having trouble using the framebuffer on an A20. The LCD (LVDS) is 18bit, the fex has fb0_format set to 9 (RGB888). The framebuffer comes up as 24bit (appears to be RGBA8888). What is really bugging me is that the colors are not correct. Red will intensify until I give it 0x3c, then it goes to a dim RED.
<T0mW>
anybody do any direct frame buffer manipulation via /dev/fb0?
<T0mW>
I cannot find info on this RGB888 format with regards to 18bit LCDs. I thought that since the framebuffer is organized as 4 bytes per pixel, it must not be RGB888 but ABGR8888, which it seems to behave as such (the latter).
<T0mW>
understood.
<T0mW>
However, you seem to be saying that the A20 chip is not a standard device, that there are derivatives?
<T0mW>
It says "ALLWINNER" on the device, I'm using the linux-sunxi kernel sources.
<libv>
did you follow that link that i just pasted?
<T0mW>
libv: yes, ..., what is your point? I've 16 years experience with ARM linux, and the last few years been working with LCD (ttl). This thing has me googling like mad, trying all sorts of configurations, etc. So, what was your point again?
<libv>
oh, too good to ndh
<libv>
understood.
<T0mW>
It's not like I'm some newbie crying to IRC when "it don't work". I'm looking for professionals to assist another pro in resolving an issue.
* libv
resumes what he was doing
<T0mW>
libv: not get lambasted by some hobbist with an ego.
<libv>
oh?
<libv>
T0mW: good luck with your issue.
<Turl>
T0mW: A20 is a SoC, and as such it's the same everywhere. But devices are not the same
<Turl>
T0mW: so you should go through http://linux-sunxi.org/New_Device_howto and add support to uboot and submit patches for that and the fex (config) file to the community
<Turl>
so the next guy with whatever that device is can just get it running quickly
<libv>
Turl: apparently only professionals are allowed to tell him anything
<libv>
on a sunday afternoon
<Turl>
libv: let's call Jon Masters :)
<libv>
Turl: i don't see him paying a graphics driver developer by the hour, so i guess he doesn't want help
<T0mW>
Turl: I understand that boards will vary, however I've the schematic for this and wired the LCD up myself. All I was asking is if someone has any documentation on the A20 framebuffer byte format. This is not my first time on IRC, many years of IRC, but the first time I've been "shown the door" on a linux kernel site. I do a lot of kernel work, if I have to, I'll run up kgdboc and delve into the whatever framebuffer source there is.
<T0mW>
I've gone through the sunxi site and there isn't any info on the framebuffer other than the FEX config info.
T0mW has quit [Quit: Leaving]
<libv>
it's nice to know that professionals also look to the wiki first.
<Turl>
such patience. I didn't even finish reading :|
<libv>
and he never answered my first question either
<libv>
this console muxing is also pretty hairy undocumented stuff
<bonbons>
libv: if stuff was documented properly it would all be boring!
<libv>
in that case, u-boot is very exciting :p
akaizen has joined #linux-sunxi
<libv>
there are just too many things awkwardly packed onto eachother, and too few people actually go and test things
<libv>
it is the nature of the beast i guess, being an embedded bootloader
<Turl>
libv: is barebox any better in that regard?