<libv>
the led section is another nice example as to why the sunxi wiki is important.
florian_kc is now known as florian
<karlp>
has there been any work on exposing leds attached to phys in device tree?
<karlp>
I know it's been a long time coming on leds on other "extra gpios"
<libv>
these leds are accessible through mdio only, as they are tied to the phy
<mps>
libv: yes, found it there. thanks
<libv>
dt, i did not look into that
<libv>
i just wanted the horrible blue led to stop
<libv>
and i have a pair of "fosdem standard" bpis here, one of which is used to provide the hdmi test signal that we are capturing
<KotCzarny>
lol @ horrible blue led
<libv>
the other is still in the frankenvideobox we had in the graphics/hwe devroom in february
<libv>
fosdem standard, as these were bought before the guys who are in charge of video now took over
<libv>
as we should've just asked tsvetan for some of his devices
<libv>
instead of these horrible $hitpies
<libv>
so disabling the leds is a quick fix, and i do not intend to investigate or write up code to make these configurable through dt :)
<libv>
i was tempted to take out a soldering iron before, and if that failed, it would've been hammer time ;)
<mps>
yes, blueled on bpi is quite annoying, as blue leds everywhere especially when blinks
<libv>
N1teHawks little tool saved a bpi today :)
<libv>
mps: yeah, seems like they popped up in everything from 2005-2015
<libv>
i hope we are beyond that now
<libv>
yes, they are chinese cheap now, but no, you shouldn't
<karlp>
oh, wasnt' suggesting you do the work, just curious if it had even started. I know how outrageously long it has taken to make any progress on DT exposing extra gpios on things like ft23x and cp210x usb devices, let alone actually hooking leds up there.
<karlp>
quick skim through the device tree bindings show that there is no work complete yet on leds on mdio :)
<libv>
:)
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
gediz0x539 has joined #linux-sunxi
<plaes>
libv: black tape :D
<gediz0x539>
libv: it's off-topic but i want to ask while you're there, do you think it may cause a problem to share watermarked allwinner documents on the wiki?
<libv>
gediz0x539: it has not so far
<libv>
gediz0x539: allwinner would seriously bite the hand that feeds it
<libv>
gediz0x539: we're in a grey zone, but... allwinner would've been long dead if it wasn't for us and the cubieboard
<gediz0x539>
no doubt
<libv>
plaes: i would've had to find my isolating tape first
<libv>
gediz0x539: i still have the things you handed me 1-2 years ago
<libv>
perhaps i should take a few mins away from the fosdem work, and do that now
<gediz0x539>
i thought you did not find them valuable
<libv>
(i was getting annoyed by the stupidity and crutchiness of drm leases, so i need to do something useful)
<libv>
gediz0x539: nope, just got interrupted away by other things
<gediz0x539>
i see. they came pretty useful for me. we've developed a som with a64, trying to publish it on the wiki.
<gediz0x539>
i can link to the original source but it's embarrasing to download something from csdn
<gediz0x539>
i better find a .cn site as you said
<libv>
h616 has g2d?
<gediz0x539>
according to the manuals, yes but I could not get my hands on any actual hardware
<libv>
iirc that was a10 and a20 only
<libv>
anyway, strange
<gediz0x539>
i looked at a20 docs to see if there's any difference but g2d is not mentioned there
<libv>
yeah, don't worry about it too much
<libv>
just something that popped out to me
<gediz0x539>
okay :)
<libv>
gediz0x539: is there anything of the a64 stuff that you have already spent time on?
<libv>
so i am not doing double work
<libv>
the mr-wu reference design sdk you handed over last december
<libv>
(not even 11 months ago, my brain remembered this being much longer ago still)
<gediz0x539>
:)
<gediz0x539>
actually it was mostly hardware, as you know. and software side was dependent on legacy kernel.
<libv>
ah, you added a mega link
<gediz0x539>
it was useful while routing DRAM, so not too much
<gediz0x539>
yep
<libv>
it will have some use to someone, so it makes sense for us to carry it
<gediz0x539>
agree
<libv>
especially since this is allwinners own stuff, and allwinner owes the sunxi community big time
<libv>
ok, doing some busywork for an hour, will feel more useful than facepalming from looking at fd.o stuff
<gediz0x539>
thanks again
<gediz0x539>
fd.o? freedesktop?
<libv>
yes, very long and very sordid history, annoys me everytime i run into stupidity. this time it is drm leases, which i will avoid for the fosdem video hw box tool
<libv>
i need to drive 2 display pipelines in as close to realtime as possible for conference use
<gediz0x539>
does not sound easy :)
<libv>
it could be
<libv>
but it isn't
<gediz0x539>
i wish i could help
<libv>
which is what is annoying
<libv>
nah, my own brain and long built up sensibilities
<gediz0x539>
oh ok then
mauz555 has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
victhor has joined #linux-sunxi
mauz555 has quit [Remote host closed the connection]
<vagrantc>
it wasn't quite merged, and there was more work on the kernel side that needed doing
matthias_bgg has quit [Quit: Leaving]
jbrown has quit [Ping timeout: 268 seconds]
<wens>
vagrantc: this seems separate from the actual DTBs having the needed symbols for overlay support
<vagrantc>
wens: having the symbols was referenced in there
eduardas has quit [Quit: Konversation terminated!]
<wens>
right, I also see the proposal of adding -@ to DTC_FLAGS
<wens>
IMO adding -@ when CONFIG_OF_OVERLAY=y is not the right answer. you can use the DTBs with U-boot's overlay support and not enable overlay support in the kernel proper, which is probably how most people use it today
<vagrantc>
if it should be enabled at run time in Debian's kernel packages, a bug/patch/merge request against the kernel packaging is probably the right place to start the conversation
<libv>
gediz0x539: any info is good
<libv>
better to have too much or superfluous info than no info
jbrown has joined #linux-sunxi
<willmore>
libv, I'm still offering you storage and BW if you ever want to backup the wiki offside.
<willmore>
FYI
Thore-Krug has joined #linux-sunxi
<Thore-Krug>
Hi
<Thore-Krug>
So im want to create a Board based on the Allwinner V3s and im looking for a way to implement a FEL pin similar to the one used on the CHIP SBC
<Thore-Krug>
The Documentation talks about " upgrade mode " and " BSP Pin " but there no such pin on the documentation mentioned ever again nor a Boot or u-boot pin
<Thore-Krug>
is there even suc a thing as a FEL pin on the V3s present ?
florian has quit [Quit: Leaving]
gediz0x5391 has joined #linux-sunxi
<libv>
willmore: yeah, i know, i just don't know when/how to get to that
<libv>
we still need https as well
<libv>
and i need to ... and ... and ...
gediz0x5391 has quit [Ping timeout: 240 seconds]
gediz0x5391 has joined #linux-sunxi
gediz0x5391 has quit [Client Quit]
<willmore>
libv, tar? ssh? ;)
<willmore>
Probably rsync would be more efficient.
<willmore>
I understand the priorities. I just appreciate the value of the wiki and would hate for some hardware or hosting error to wipe the whole thing out.
damex_ is now known as damex
iamfrankenstein has quit [Quit: iamfrankenstein]
mauz555 has joined #linux-sunxi
c10ud^ has joined #linux-sunxi
lurchi__ is now known as lurchi_
JohnDoe9 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 258 seconds]
lurchi_ is now known as lurchi__
Thore-Krug has quit [Remote host closed the connection]
lurchi__ is now known as lurchi_
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe9 has quit [Ping timeout: 258 seconds]
<montjoie>
libv: willmore: does password are hashed in the DB ? A first step could be to generate a tar.gz availlable in a vhost restricted by IP/password