<wens>
i'd like to think we're close to the point where olimex can ditch the old 3.4 kernel
<plaes>
yup, close.. but no cigar, yet
staplr has quit [Remote host closed the connection]
akaizen_ has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
<tkaiser>
wens: According to the blog post Tsvetan thinks there exist good 3.4 kernels and bad ones.
<tkaiser>
"Fortunately we use Linux-Sunxi community kernel which is 100% open source and no binary blobs!" is referring to 3.4.103
<KotCzarny>
so, no 2d/3d accel?
<tkaiser>
KotCzarny: What? The point is that he differentiates between 'Android 3.4' kernel and 'linux-sunxi 3.4' kernel. But they're both based on Allwinner's BSP and only mainline kernel would be '100% open source' or better from a security point of view
<KotCzarny>
tkaiser, i was joking
<tkaiser>
I'm a bit concerned since such a local privileges escalation might be possible with the other 3.4 kernels too. It took over a year since you discovered it by accident in sun8i BSP kernel sources.
<MoeIcenowy>
mripard: for DRM-enabled devices the simplefb should be disabled?
<wens>
mripard: won't the fb still be registered with the kernel
<mripard>
hmm, yeah, right
<wens>
someone clueless could try to use /dev/fb* and the whole display breaks :p
<mripard>
it won't break
<wens>
hmm... no it won't break
<wens>
but it won't do anything either
<mripard>
it will write to a buffer sitting in memory
<mripard>
and that's it
<wens>
a black hole
cnxsoft has quit [Ping timeout: 240 seconds]
<wens>
i guess we can live with that
<MoeIcenowy>
But the fb memory is wasted...
<wens>
MoeIcenowy: it's unrecoverable anyway
<wens>
it's placed at the end of DRAM, and excluded from the memory space passed from u-boot to the kernel
cnxsoft has joined #linux-sunxi
<ssvb>
wens: this can be probably handled in U-Boot, we can have an env option to shut down the framebuffer and release all the resources before booting the kernel
cnxsoft1 has joined #linux-sunxi
<ssvb>
the blackhole /dev/fb is an extremely ugly thing, because it breaks the software relying on the fbdev API
<wens>
ssvb: should be doable just by looking for drm nodes in the dt
<oneinsect>
KotCzarny: do you the legacy u-boot-sunxi-with-spl.bin file for orange pi pc? can you share it with me...
cnxsoft has quit [Ping timeout: 276 seconds]
cnxsoft1 is now known as cnxsoft
<ssvb>
oneinsect: what are you trying to do?
<mripard>
wens: it could be handled actually
<mripard>
wens: the proper way to deal with this would be to mark the memory area in the DT as reserved
<oneinsect>
ssvb: legacy u-boot loads faster than mainline u-boot for orange pi boards
<mripard>
and then linux would be able to claim it
<jelle>
oneinsect: because usb support
<wens>
mripard: that's what i had in mind
<oneinsect>
with microsd
<mripard>
I suggested that back when u-boot support was added
<speakman>
mripard: Can't find anything regarding LVDS on linux-sunxi.org. Do you have any good entrance points?
<mripard>
but it was discarded for obscure reasons
<oneinsect>
so wanted to know if anyone had any bin file
<jelle>
oneinsect: don't you see usb scanning when booting?
<mripard>
that would not make us reclaim the lost memory though
<ssvb>
this is not too bad in the short term, what's the plan for getting it back?
<MoeIcenowy>
wens: I think some regulators in my dt is wrong
<MoeIcenowy>
as after "dc1sw: disabling" the LCD became wholly white
jbrown has quit [Quit: Leaving]
Nyuutwo has joined #linux-sunxi
Amit_T has joined #linux-sunxi
<wens>
i guess looking how reserved-memory ties in with fbdev would be one way
<MoeIcenowy>
(maybe DE or the LCD Panel is shut down?)
<wens>
MoeIcenowy: likely the LCD panel and maybe the LVDS bridge (if there is one)
<MoeIcenowy>
wens: there's no bridge
<MoeIcenowy>
A31s natively supports it
<wens>
see Primo81 dts for an example on how to add regulators to simplefb
<MoeIcenowy>
What's the equal for port:power2 in dt?
<MoeIcenowy>
wens: I started my work on Primo81...
<wens>
MoeIcenowy: there are panels that include a bridge in the assembly
<MoeIcenowy>
port: power2
<wens>
dc1sw
<oliv3r>
speakman: I2C :) we are using an ssd1307 device, but will use some simple framebuffer in the future on hdmi
dlan has joined #linux-sunxi
<speakman>
oliv3r: :D
<MoeIcenowy>
wens: the code of dc1sw is directly copied from primo81
<KotCzarny>
oneinsect: you can simply recompile mainline uboot with usb disabled, but in case of anything happening you wont be able to use keyboard in uboot
<oliv3r>
oneinsect: i noticed the same thing, but haven't investigated yet. it seems that loading data from sd is very slow (in terms of bandwith)
<mripard>
ssvb: pass the memory region allocated in the DT instead of removing it from the memory Linux can use, so that Linux is now aware of it
<mripard>
tie it to simplefb
<plaes>
oliv3r: ftbtft?
<oneinsect>
yess oliv3r: same here
<oneinsect>
its very slow loaded data from sdcard
<mripard>
and make simplefb free the region when we remove it
<oneinsect>
loading*
<KotCzarny>
tkaiser: i would be worried about bsp code quality, because even without 'debug' it could be full of exploitable bugs
<KotCzarny>
oneinsect: but seriously, how long is long? even with ~1MB/s its quick enough (unless you make big ramdisks, then it can be an issue)
<oliv3r>
plaes: i haven't forgotten about you yet :p
<MoeIcenowy>
wens: I used to remove the code of dc1sw
<MoeIcenowy>
after they're put back
<plaes>
well, fbtft is dead end ;)
<MoeIcenowy>
vcc-lcd: failed to get the current voltage(-22)
<MoeIcenowy>
axp20x-regulator axp20x-regulator: Failed to register dc1sw
<oneinsect>
took 1 second to load initramfs into RAM with legacy u-boot where with new U-boot it takes almost 50 seconds.
<oliv3r>
wens: have you noticed this as well? loading data from (e)MMC is quite slow on the latest u-boot
<oneinsect>
from microsdcard
<oneinsect>
KotCzarny:
<oliv3r>
well it depends how large your initramfs is
<oliv3r>
but my kernel also takes a good 20 seconds to load
<oliv3r>
where as with the older u-boots it was a second or less :)
<oneinsect>
exactly
<oneinsect>
wonder why its like that
<oneinsect>
becoz of allwinner patchs?
<KotCzarny>
oneinsect, i suspect usb1 vs usb2
<KotCzarny>
because i've never seen speeds higher than ~1MB/s
<oneinsect>
but we use microsd card KotCzarny: and its the same board and same kernels all the times...just different u-boot thats all
<oliv3r>
oneinsect: i haven't checked the git history
<KotCzarny>
and mostly in ~500-800kB/s
<KotCzarny>
ahm, sorry
<oliv3r>
KotCzarny: na even with usb completly disabled it's slow like that
<KotCzarny>
i would try posting on uboot bugtracker
<oneinsect>
oliv3r: do you the legacy u-boot spl bin file? can you share?
fredy has quit [Excess Flood]
<plaes>
montjoie: fixed few typos
<wens>
oliv3r: not really
<wens>
oliv3r: haven't updated yet
<wens>
MoeIcenowy: right, there was a fix for it
<MoeIcenowy>
wens: ?
<MoeIcenowy>
the kernel is still dead
<KotCzarny>
oneinsect: another thing that comes to mind is only very basic sd support
<MoeIcenowy>
and it cannot even switch console to fbcon on simplefb!
<oneinsect>
hmmm
<KotCzarny>
oneinsect: which also is in those speeds range
<oneinsect>
could be...
<KotCzarny>
as for the uboot, you can extract it from android image for opipc probably
<wens>
MoeIcenowy: remove the constrains (min/max) in the dc1sw node and try again
<Dev_184>
I grabbed the rtl8723bs driver form hadess (https://github.com/hadess/rtl8723bs) compiled it and tried to load the issue is that I get a EBUSY from drivers/mmc/core/core.c __mmc_start_request. I went further and got the card_busy handler from drivers/mmc/host/sunxi-mmc.c and I outputted mmc_readl if that helps
<Dev_184>
I tried to compile and run 3.4 the problem is that the driver will not compile on 3.4
<Dev_184>
to test if on a earlier version the driver worked or the issue was not present (regression)
<speakman>
What bootloader to use when moving from sunxi-3.4 to vanilla kernel?
<mripard>
uboot mainline
<MoeIcenowy>
How can I do if the mainline lradc driver return all KEY_VOLUMNDOWN for two volumn keys?
JohnDoe_71Rus has joined #linux-sunxi
<Shirasaka-Hazumi>
MoeIcenowy, had you tried SDK kernel?
codekipper has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
reev has quit [Ping timeout: 244 seconds]
<MoeIcenowy>
Shirasaka-Hazumi: SDK kernel cannot even boot on this tablet!
<mripard>
MoeIcenowy: then the voltages are probably wrong, and you need to figure tem out
cosm_ has joined #linux-sunxi
codekipper has quit [Quit: Page closed]
<MoeIcenowy>
mripard: howto? just try? or there's something in fex?
<mripard>
look at the schematics
<mripard>
if you don't have them, at the fex file
<mripard>
if you don't have it, use a multimeter
<MoeIcenowy>
mripard: in which section of fex
<Dev_184>
any idea on the sdio card issue ?
<mripard>
MoeIcenowy: keys, or lradc?
<mripard>
I don't know, I'm probably the last guy you want to talk about FEX with
<arete74>
chris2: the root for allwinner device is valid only for last sdk (h3 /A83)
<MoeIcenowy>
mripard: Hmm... Maybe there won't be another people worth asking...
<libv>
MoeIcenowy: there is code to read the fex values sprinkled all over the kernel
<libv>
the sdk kernel(s) even
<libv>
MoeIcenowy: when in doubt, go read up there
<speakman>
are "machid=10bb" still required?
<tkaiser>
speakman: Only for legacy kernels
<ssvb>
speakman: iirc, "machid=10bb" was never required for a20
IgorPec has joined #linux-sunxi
<speakman>
tkaiser: ssvb: ok, thanks, then I can finally get rid of it :)
<speakman>
I was working with A13 prior to A20, maybe it's from A13.
<MoeIcenowy>
how can I enable a sdio mmc controller?
montjoie has joined #linux-sunxi
<pitillo>
hello, does someone know if a nokia ca-42 can be used to get serial access to the pine64?
<plaes>
pitillo: I guess so
<KotCzarny>
CA-42: It is replacing the DKU-5 for most newer compatible handsets. It eliminates the software emulation but doing the Pop-port to USB conversion right at chip inside the cable
IgorPec has joined #linux-sunxi
<pitillo>
plaes: thank you, yesterday I saw some info using another type (3.3v) and if I'm right, the ca-42 uses 3.3v too (not sure if dku used more V)
<plaes>
well, you only need GND, RX, TX
<plaes>
(if you provide power from somewhere else)
<pitillo>
yeah plaes
<pitillo>
it gets from usb if I'm right
<pitillo>
btw, I'd like to congrat all people working in this toy too (I know there are more toys and a lot of work behind them) but specially now to longsleep for the effort into pine device (really amazed with linux sunxi community, congrats all)
<plaes>
well, they are no use without proper frontend/backend support anyway
<mripard>
yep
cosm has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
tkaiser has joined #linux-sunxi
<tkaiser>
longsleep: Did you realize that there is someone who should follow a simple '6 steps instructions' and just got confused after step 4 and simply stops instead of doing the last 2 steps that will lead to Plexmediaserver:armhf being installed successfully?