<oliv3r>
mrnuke: thanks for the patch! i'll try to test it and merge it
ssvb has quit [Remote host closed the connection]
<oliv3r>
mrnuke: ML is prefered though :)
<mrnuke>
I've heard about the ML
* mrnuke
shrugs
n01 has joined #linux-sunxi
<oliv3r>
mrnuke: i'll do a weget github.patch :p
<oliv3r>
no worries
<oliv3r>
i'm easay
<mrnuke>
thanks. much appreciated
<n01>
'morning
<oliv3r>
the first time
<oliv3r>
after that i'm expensive :p
<mrnuke>
hehe
<oliv3r>
i should look up what USEC_TO_COUNT does
<mrnuke>
it's defined like 10 or 20 lines above
<oliv3r>
i don't see that in the patch!
<oliv3r>
but it's a sunxi thing? i thought it's a u-boot thing
<oliv3r>
ah i see it
<mrnuke>
yeah, it was already defined, just not used
panda84kde has joined #linux-sunxi
<oliv3r>
wait, so the original code was usec * (24 * 1000 * 1000) / 1000 / 1000?
<oliv3r>
why?
<oliv3r>
that's just silly
<oliv3r>
there's better ways to round
<mrnuke>
my favorite is the "repetitive hammer strike" :p
<oliv3r>
mrnuke: i'm inclined to init the timer before gpio
<wens>
it might even overflow
<oliv3r>
wens: i think that was the reason for mrnukes patch; it could overflow :)
<oliv3r>
wens: he did call himself the overflow police!
<wens>
ah yes
<mrnuke>
oliv3r: feel free to init it wherever you want (as long as it's before ram init)
<mrnuke>
wens: it overflowed when I put a 10 second delay
<mrnuke>
that's how I found there was a problem
<mrnuke>
(yeah, printf, then delay, watching console with a stopwatch -- don't tell me you guyse _never_ did that)
n01 has quit [Ping timeout: 246 seconds]
<oliv3r>
mrnuke: well watchdog_init is the m ost important I feel; so it resets the board in case of problems etc; then the clocks obvioulsy as nothing will work without the clocks. so gpio vs timer; timer is internal and more 'core' then gpio :)
<oliv3r>
anyway, that's my take on it, but i'm often wrong
n01 has joined #linux-sunxi
<mrnuke>
yeah, timer is pretty hard-"core". there no clock to ungate for the timer module
Quarx|2 has joined #linux-sunxi
<oliv3r>
i'll swap it when i merge your patch
<mrnuke>
it's a free world :)
<oliv3r>
mrnuke: you did the sdelay -> udelay math?
<mrnuke>
yeah
<mrnuke>
i put a READ_TIMER(); sdelay(1000000000); READ_TIMER()
<mrnuke>
125 million ticks, plus 12 to 14
<oliv3r>
yeah if we can get rid of sdelay all together, that's a good thing
Quarx has quit [Ping timeout: 246 seconds]
vector80 has quit [Read error: Connection reset by peer]
<oliv3r>
so its off by 12-14 clock cycles? that's pretty acceptable :p
<oliv3r>
i'm very happy that we don't depend on clock anymore
vector80 has joined #linux-sunxi
<oliv3r>
cpu clock :p and have a reliable time source for it now
<oliv3r>
i guess the only problem arrises when sdelay is < 0x50 and udelay(1) is actually 'too long' but I don't think anybody will loose any sleep over that
<mrnuke>
I think the 12-14 ticks has to do with branching to sdelay, and a few missed branch predictions
<mrnuke>
you know, the clock at that point is 384 MHz (coiincidence?)
<oliv3r>
i know too little about dram controllers etc, to know wether the dram init is really time dependant, or related to the mbus/cpu-speed
<oliv3r>
mrnuke: what do you mean? the CPU clock is 384 MHz?
jt6562 has quit [Ping timeout: 272 seconds]
<mrnuke>
it's set up from PLL1 at 384 MHz before the PMU is initialized
bbrezillon has joined #linux-sunxi
<oliv3r>
does u-boot init pll1 or the BROM?
<oliv3r>
(I don't know the brom entirely by heart :p)
<oliv3r>
but i assume that there's some default in there too?
<mrnuke>
it's done in clock_init or s_init (uboot side)
<mrnuke>
yeah, in clock_init_safe(). If my bitmath is right, that hardcoded value ends up being 384MHz
<oliv3r>
ok cool
<oliv3r>
i wonder as what the brom runs the CPU at
<oliv3r>
i wouldn't be supprised if the BROM runs at 24 MHz
<mrnuke>
my advice, forget about the BROM. assume it does nothing useful, and leaves no useful defaults
<oliv3r>
oh absolutly
<oliv3r>
but i'm documenting it for 2 reasons
<oliv3r>
a) to learn asm and how it works
<oliv3r>
b) freedom/privacy sakes
<oliv3r>
it'll take 1 blob out of the equation
<oliv3r>
also we know it's a GPL violating one
<oliv3r>
Turl: are you busy?
<mrnuke>
oh, definitely document it, just don't worry about it when writing hardware init code
<mrnuke>
GPL violating? How did that happen?
<oliv3r>
i think u-boot assumes that the chip is in 'prestine shape' e.g. 0.
<oliv3r>
mrnuke: well the BROM is compiled C code turned ROM
<oliv3r>
they used linux libs for certain tasks (linux/u-boot)
<oliv3r>
Turl: don't read it now, just don't forget about it :p
<mrnuke>
so, no source for the BROM?
<oliv3r>
Turl: they jump to this point from various times in the function
<oliv3r>
Turl: how can they popo the stack several times (and why are they passing arguments via r0, that they overwrite anyway
<oliv3r>
mrnuke: so if i steal the linux kerenl, compile it and store the binary in ROM it doesn't violate the GPL?
<oliv3r>
but what if its EEPROM?
<Turl>
restores callee-saves?
<Turl>
it's the exit point I suppose
<oliv3r>
ohh
<oliv3r>
yeah i did see that it never exists
deasy has joined #linux-sunxi
<oliv3r>
or i haven't found any return yet
<oliv3r>
(return as in branch lr or anything)
<oliv3r>
ohh wait
<mrnuke>
oliv3r: That's tivoization. it's forbidden by GPLv3, but GPLv2 permits it (as long as the source code is available, that is)
<oliv3r>
it pops the PC from the stack
<oliv3r>
mrnuke: but if there's no source, then that's a GPL violation i mean
<mrnuke>
well, then yeah, it is
<oliv3r>
mrnuke: we have no BROM source, so it's a violation of the GPL was my understanding
<mrnuke>
what really eats me up about the BROM, is that by trying to make it unbrickable, they introduced a huge security breach
<oliv3r>
Turl: of course! ok i'll have to write that down or I forget ;)
<oliv3r>
Turl: i haven't seen pop used to exit a function before; but makes sense i suppose :)
<oliv3r>
Turl: thanks!! :)
<oliv3r>
mrnuke: how so?
<oliv3r>
i wish it WHERE upgradeable :)
<Turl>
yw :) read about prologue and epilogue on asm
<Turl>
pop on pc sounds like a jump i suppose :p
<oliv3r>
(and still keep it 'safe'
<oliv3r>
Turl: it does indeed, but i'm new to this, i never really done anything with asm :)
<oliv3r>
i mean, they could have made the BROM eeprom, and allow it to be programmed like any flash chip (via special pins if needed)
<oliv3r>
sure that requires special setups and the like, but BROM would never get updated anyway or hardly ever
<oliv3r>
the BROM has some bugs and is kinda messy
<mrnuke>
oliv3r: the thing is, even if you put hardcore crypto verification, and put the firmware in a write-protected SPI chip, I can still just plug in a micro-sd and bypass all that. As far as making it upgradeable, the chip would no lenger be unbrickable
<mrnuke>
(it being the BROM)
<mrnuke>
it could have gone the way of bootstrap pins. Then by shorting those pins, you select the boot source. Harder to bypass in hardware, especially if the shortcircuit is done right under the BGA
<oliv3r>
mrnuke: well if you develop such a system, you simply don't connect mmc0 and mmc2 :p
<oliv3r>
mrnuke: i think if you have such hardcore requirements, you simply don't connect these ports
<oliv3r>
but yeah
<mrnuke>
all I have to do is cut a trace off the firmware chip, and it boots into FEL
<mrnuke>
still a huge security backdoor
<oliv3r>
true
<oliv3r>
well their lack of security, is amazing for us :p
<oliv3r>
it gives us tons of flexibility :)
<mrnuke>
ideally, if an attacker manages to sabotage the boot firmware, the system should just refuse to boot
<oliv3r>
you mean by signing it :p
<oliv3r>
but yeah
<mrnuke>
sure, it's flexible, and unbrickable
<Turl>
A31 does the pin thing
<Turl>
check the wiki
<oliv3r>
i wonder how the A23 does it
<oliv3r>
libv extract the brom! :D
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
<mrnuke>
UARGH!! "go to fel mode if failed" Still a security problem. I short the MISO pin on the SPI chip, and get to FEL. not good
<oliv3r>
but it makes it unbrickable!
<oliv3r>
i guess for simple consumer devices that's more important
<oliv3r>
though yeah, they should have made that behaviour completly optional via pins on the bottom of the package
<oliv3r>
true, security through obscurity
<andoma>
or efuses
<oliv3r>
but then it's not unbrickable anymore
<oliv3r>
hardware you can 'hide' in a box
<oliv3r>
so as long as you can't access it, it is save, but still servicable
<oliv3r>
if an attack has physical access, all bets are off anyway
<andoma>
still, for some type of equipment you'd rather have bricked devices and send new to your customer than having a hackable device
<oliv3r>
i guess you can't have 1 design/chip to please all markets
<oliv3r>
as it is always with security, it is either easy/user friendly, or secure
<oliv3r>
these are inherently always at eachothers opposites
<andoma>
yeah and i don't think AW have focused their engineering effort on the security stuff that much
<oliv3r>
nah; but i think in the market they aim for, it's completly irrelevant
<andoma>
exactly
<oliv3r>
and unbrickability is much more important
<oliv3r>
since this is all about end users, who want a device that works, and some service technician/OEM has to quickly and easily be able to revive the device again
<mrnuke>
"<oliv3r> true, security through obscurity" ? Really. You complain about having no prior assembly experience, yet you managed to almost completely RE the BROM
<mrnuke>
:P
<Turl>
easy flashing by factory >*
<oliv3r>
so yeah, if you want a10 for something moderate secure, fine, hide the hardware; if you want hardcore security, get something else :)
<oliv3r>
mrnuke: not sure how the quote and your statement relate; but yeah, i never written a line of asm
bsdfox has quit [Ping timeout: 264 seconds]
<oliv3r>
mrnuke: never read any really either, maybe 10 lines :p
<Turl>
if your device is empty, it boots to fel
<oliv3r>
mrnuke: but asm is easy, and I have turl :)
<oliv3r>
also good point Turl, factory has to be able to flash it when it comes from the factory -> fel :)
<oliv3r>
this chip is all about ease of OEM integration!
<oliv3r>
*note to self, fosdem point
<mrnuke>
oliv3r: most assembly I ever wrote was asm("nop"): A few times I even did the infamous asm("dmb") :p
<oliv3r>
it's a micro PCB, that allows you to switch between 2 SPI flash devices
<Turl>
btw, will coreboot bring us any practical benefits over uboot?
<oliv3r>
the idea herein is, you plug it into your board, have 1 smd flash device to play with, and have your original bios in the socket
<oliv3r>
Turl: seabios etc
<Turl>
seabios.. sounds familiar
<mrnuke>
Turl: coreboot is supposed to only do hardware init, and launch what we call a "payload"
<Turl>
so it's a SPL in uboot terms
<mrnuke>
so that payload can be anything you want, a BIOS (SeaBIOS), UEFI (Tianocore), GRUB2, etc
<mrnuke>
exactly
<mrnuke>
I'm launching uboot from within coreboot
<mrnuke>
so uboot is the payload, for example
<Turl>
cool :)
<Turl>
the more the merrier, at least until tjere's bugs :p
<Turl>
h*
gzamboni has joined #linux-sunxi
<mrnuke>
so you can even implement crypto verification of payload and later OS
<mrnuke>
chromebooks do this, where coreboot resides on a write-protected part of the flash, and verifies anything from the unprotrcted part before launching it
<mrnuke>
bugs are easy to fix. it's free software in the end
<Turl>
yeah, but triage pain is bigger when only half the people see the bug :)
<Turl>
some people here wanted barebox btw
<n01>
i'd like to have barebox on cb
<oliv3r>
Turl: sleep! sleep now so you can get up early! :)
<oliv3r>
the only reason why i would be against these efforts, is spreading resources thinner; the obvious advantage is, bug squashing (e.g. patches as the dram timer one)
<mrnuke>
once you coreboot, you never go back
* mrnuke
hides
<oliv3r>
heheh
<oliv3r>
i want to get coreboot running on my systems for ages
<oliv3r>
but a) they aren't fully supported yet
<oliv3r>
b) can't afford the downtime in case of trouble (until i have my dspif modules ;)
<oliv3r>
c) to much on my plate for the next century
<oliv3r>
and one of the boards i'd love to have coreboot running on, my HP microserver N36L has a solderd SMD bios chip :S
<oliv3r>
hansg: i'll look; but you are probably far smarter then me anyway :p
wingrime has joined #linux-sunxi
<oliv3r>
hansg: ah you kinda went with the 'old' approach there then
<oliv3r>
hansg: I wonder if he'll accept it, i think the ahci_platform.c integration will have to happen anyway, as more soc will 'join' we need a proper ahci_platform + libahci framework aynway
<oliv3r>
hansg: i'd probably use sunxi_setbits and sunxi_clrbits or the sunxi_ahci_pre_start_engine() though
notmart has joined #linux-sunxi
gzamboni has quit [Ping timeout: 240 seconds]
rellla has quit [Read error: Connection timed out]
gzamboni has joined #linux-sunxi
rellla has joined #linux-sunxi
<mrnuke>
BTW, where does the name "sun" in sunxi come from?
<oliv3r>
mrnuke: china
<oliv3r>
mrnuke: Allwinner's internal name for the a10 platform was 'sun4i'
<oliv3r>
when A13 came, it was bumped to 'sun5i'
<hansg>
oliv3r, have you seen the line numbers? A driver using some sort of generic ahci_platform is not going to be smaller then one doing things itself. All the core functionality is already taken care of by libahci, trying to abstract / generalize the glue is just not going to work well, a generalized glue core is just going to be quite large and ugly and will likely need to be extended for each new platform driver anyways
<oliv3r>
so sunxi, making the 4, 5 variable X, made sense :)
<hansg>
With the actual glue drivers staying aprox as big as they are without a glue core ...
<oliv3r>
hansg: i think it will actually be bigger then 350 lines, probably around 1000 :) but i think it will allow any new platform driver to 'hook in' more easy
<oliv3r>
hansg: but I'll gladly let you pick that fight with the maintainer :D
<hansg>
As for using sunxi_clrsetbits good idea, making that change now
<mrnuke>
oliv3r: ooh, so allwinner, named it "sun[number]i"
<hansg>
oliv3r, ok, so shall I submit my version upstream then (once done testing) ?
<oliv3r>
hansg: i think same for resume/suspend (clrbits) but only glanced there
<oliv3r>
mrnuke: yeah, ironically; the latest sdk, 2 years after we started to name it sunxi, they started to do sunxi-ing it too :)
<mrnuke>
haha
<oliv3r>
what's even more funny; some e-mails hans and I exchange, are in english
<mrnuke>
BTW, is the linux SPI driver functiona;(or existent) I couldn't get a /dev/spi when I last booted
<oliv3r>
while both of us are native dutch :)
<oliv3r>
mrnuke: for mailine, mripard is working on it
<oliv3r>
in 3.4 i'm not sure
<oliv3r>
and i don't think we have it in u-boot
<n01>
hansg where did you get the info for lradc?
<oliv3r>
i did see some duplexing patches pop by the ML for 3.4; so it should work there
<hansg>
oliv3r, yeah, I find that when talking computer stuff English is just more convenient, also I write so much English professionally I need to think harder to write Dutch then English :)
<mrnuke>
I think I tried sunxi-devel, or sunxi-next
<oliv3r>
hansg: i agree ;)
<oliv3r>
mrnuke: that's mainline stuff; mripard is working on it, but i haven't seen any patcehs yet
<oliv3r>
n01: what info?
<hansg>
n01, data-sheet + android driver
<oliv3r>
hansg: btw, i'm not sure i like your lradc patches :p
<hansg>
oliv3r, can you explain ?
<n01>
hansg: ok then I definitely missed something when writing my driver (that's why it didn't work)
<oliv3r>
hansg: technically they are fine, but shouldn't we have a generic (lr)adc driver in the iio? framework, and then have a 'bridgin' thing that would work on any adc? (theoretically even on the TS)?
<mrnuke>
oliv3r: so that would be on top of linux-next, right?
<hansg>
oliv3r, have you read my latest reply to mripard about this ?
<oliv3r>
(as the TS is just an adc too if configured as such)
<oliv3r>
hansg: no, i'm still reading the ML
<oliv3r>
i'm almost caught up though, stupid hollidays
<oliv3r>
310 unread mails left
<hansg>
oliv3r, he was making the exact same argument, but the lradc is specifically designed for input purposes, it has button down and up interrupts, there is no way to map that through IIO
<oliv3r>
hansg: so iio needs to be extended :p
<hansg>
oliv3r, it also does things like debouncing the input. Same for the ts
<oliv3r>
hansg: fiar nuff
<oliv3r>
but still; special iio additions ;)
<oliv3r>
but i admit, i wasn't aware of that
<hansg>
No, just no. The whole lradc driver currently is 200 lines, n01's attempt at an IIO driver is bigger, without the glue + special additions + ...
diego has joined #linux-sunxi
<hansg>
I always greatly prefer KISS when possible. Or to quite Linus: "Perfect is the enemy of good"
panda84kde has quit [Ping timeout: 240 seconds]
<oliv3r>
hehe, I suppose if the need would really arrise, someone should just extend the IIO framework and maybe then we could consider it
<oliv3r>
yeah very true
diego is now known as Guest17272
<oliv3r>
perfectionism is not a positive thing!
<hansg>
n01, any progress on doing a mfd driver for (one of) the axpXXX chips ?
<n01>
hansg: I'm stuck on a nasty problem about irq managing
<n01>
I'm still trying to figure it out
<oliv3r>
hansg: with all this steamrolling; don't forget to update the wiki page :p
<hansg>
oliv3r, erm, can I delegate that to someone? (ie you?)
<oliv3r>
pfew, i'll try to gmane your e-mail + sunxi then and go from there
Guest17272 is now known as panda84kde
<oliv3r>
hansg: lradc, ts, ahci, mmc?/
<hansg>
oliv3r, yes those are all working. If you want to put names to them I did lradc + ts, you did AHCI, David Lanzendörfer did MMC
<oliv3r>
i thought oyu did more!
<hansg>
oliv3r, more in general see my "sunxi-devel branch updated" mails to the list where I try to give status reports of what is happening in the sunxi-devel branch
<oliv3r>
it felt like i saw more patches
<oliv3r>
ah yeah; good point
bob__ has joined #linux-sunxi
<hansg>
I mainly take others work and merge it into sunxi-devel. Granted I did also do some of the mmc and ahci work :)
<oliv3r>
hansg: and USB i think
<oliv3r>
or i think you said you where gonna clean it up a bit?
<oliv3r>
and add ohci?/
<hansg>
EHCI is currently all arokux work, but yes EHCI works in sunxi-devel too
<wens>
i'm thinking of re-doing usb
bsdfox has quit [Ping timeout: 246 seconds]
<wens>
at least the clocks, resets, phy and ohci
<wens>
but i need to get gmac out the door first :(
<hansg>
arokux said he wanted to try and do it himself, but I've just got a go ahead from him to take a shot at doing it myself. So that is my plan for today after pushing out the new ahci patches
<hansg>
wens, as said I plan to work on it today, so please coordinate to avoid doing double work. arokux has already solved the reset bits in the clk register in a cleaner way (but not pushed out the patches anywhere yet) so I'm going to keep using the hackish approach there for now. I plan to focus on writing a phy driver for the phy registers in usbc0 which are shared with usbc1 and usbc2
<oliv3r>
wens: i thought you where hacking on the OTG driver using the invent...something driver?
<hansg>
wens, I'm talking OHCI + EHCI here. Getting usbc0 / otg to work should be feasible to, we've patches in sunxi-3.4 to use musb instead of allwinners own code, those should be a good starting point
<oliv3r>
inventra*
<wens>
oliv3r: i started looking at it, but the shared part should be done in a phy driver
<hansg>
wens, note the otg bits of it likely will be incomplete but it should provide you with a starting point
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
<wens>
I'm looking at both sunxi-3.4 and A23 SDK
<oliv3r>
what was the german guy called working on the Transport Stream driver?
<oliv3r>
and who was working on the security system again?
<oliv3r>
montjoie[home]: I think wasn't it?
<cajg>
Has anyone tried the experimental/sunxi-3.10 kernel? Would it be madness?
<cajg>
(I'd like to try lxc on the MK802)
<wens>
oliv3r: Montjoie on security system
<oliv3r>
cajg: yes, that will be madness
<cajg>
ok, thanks oliv3r
<oliv3r>
cajg: unless you need nothing besides nfs
<cajg>
oliv3r in what sort of time frame do you think it will not be madness?
<oliv3r>
woppr
<oliv3r>
cajg: 12 months
hramrach has quit [Ping timeout: 240 seconds]
<oliv3r>
woprr: Ah you where working on the transport stream driver where you not? :)
panda84kde is now known as diego__
<woprr>
yes
<oliv3r>
woprr: ah Hi! cool i'll write your name down then
<woprr>
down where?
<oliv3r>
on the wiki :)
hramrach has joined #linux-sunxi
<woprr>
k, thx
<oliv3r>
woprr: just so that everybody knows who's working on what etc
<oliv3r>
woprr: weren't you designing your own tunerboard too?
<oliv3r>
just so I know i'm not an idiot, the audio stuff somewhat works like the video stuff right?
<woprr>
was busy with a homebrew DLP-link 3D shutter glasses system but I'll continue the TSC dvb-driver soon, the testing hardware is going to be ready soon, too
<oliv3r>
we have an audio engine, and 4 possible outputs, ac97 -> analog out, i2s for digital out, hdmi for digital out and spdif, each can be clocked and used individually as output?
<wens>
audio stuff?
<oliv3r>
wens: very cool
<oliv3r>
wens: well i know we have 3 sunxi audio drivers right now, do we not? sunxi-codec, i2s, spdif
<wens>
i think you would count them as seperate sound cards
<woprr>
the driver will pass the full ts to the userspace if the TSC allows it
<oliv3r>
i thought sunxi-codec was basically ac97 stuff
panda84kde has joined #linux-sunxi
<wens>
sunxi-codec is the onboard audio codec
<oliv3r>
woprr: that should be cool; i take it the TS driver will require dma?
<wens>
iirc there is no allwinner driver for ac97
<oliv3r>
wens: yeah, i'm looking at the clock register list as to what devices we have, and the i2s, ac97 and spdif are 3 seperate clocks; + hdmi, though that may be i2s or spdif re-routed?
<oliv3r>
wens: i think sunxi-codec is ac97?
<wens>
not sure about hdmi
<oliv3r>
wens: ah no, there's audio_codec_clk
<oliv3r>
i should grep the ac97 clk register
<woprr>
oliv3r, yes the TSC will not work without if the published manual is correct
<wens>
the audio codec driver looks nice
<oliv3r>
but i thought that the ac97 stuff, was to take the digital codec output and make it analog
diego__ has quit [Ping timeout: 240 seconds]
<montjoie[home]>
oliv3r I work on the SS driver, I expect to release this month
<wens>
but i can't wrap my head around alsa soc structure
<oliv3r>
montjoie[home]: no rush; just documenting
<wens>
oliv3r: that's right, but then you'd need another chip
<montjoie[home]>
if someone can write that I will mainline after
<oliv3r>
wens: maybe they integrated this into the SoC though
panda84kde has quit [Client Quit]
<oliv3r>
e.g. sunxi-codec -> i2s; sunxi-codec -> spdif, sunxi-codec->ac97
<wens>
oliv3r: my take is that, the builtin codec only takes 2 channels
<wens>
ac97 can take 6
panda84kde has joined #linux-sunxi
<oliv3r>
wens: maybe they violate the spec!
<wens>
so if an OEM wants to do a STB, they might choose ac97 over the builtin one
<woprr>
the V(B)E(?) has some nice 3D format processing features it seems, but that should be usable if the HDMI transmitter can drive >=100Hz... ?
<oliv3r>
well isn't ac97 codec chips used on motherboard with only 1 headphone jack etfc
<woprr>
...only
<wens>
oliv3r: depends on the codec
<oliv3r>
woprr: i think the display engine can't do 100 Hz at high resolutions, not enough memory bandwith
<woprr>
k
<oliv3r>
woprr: we now advise people to run 50 Hz refresh rates if they want to drive Full HD panels @ 32 bit
<woprr>
k
<oliv3r>
wens: yeah i don't understand how all that fits together anyway :p
<woprr>
^^
<oliv3r>
wens: i just guesstimated :p
<wens>
oliv3r: i would say the audio codec is a complete soundcard
<wens>
whereas the i2s, spdif, hdmi ones are only transports, i.e. no codec
<oliv3r>
so what IS ac97? i thought it was a spec of some sort, and i know there's chips that do that, i just thought they take a digital input and make it analog
paulk-collins has joined #linux-sunxi
<oliv3r>
wens: i probably should first learn what ac97 really is :)
<oliv3r>
paulk-collins: you are attending fosdem right? are you going to the f-droid talk? as it mentions replicant in the notes
<oliv3r>
wens: also isn't audio on hdmi multiplexed with the video data on the same lvds pins?
<paulk-collins>
oliv3r, that depends on whether my talk is accepted or not
<paulk-collins>
but most likely, I'll go
<wens>
oliv3r: iirc AC97 just a transport standard, think maybe i2s + control lines
<paulk-collins>
and yes, I'll be at the F-Droid talk as well as tours
<paulk-collins>
yours*
<oliv3r>
paulk-collins: the sunxi talk is at the same timeslot as the f-droid slot :(
<paulk-collins>
ahhh
<oliv3r>
complain at #fosdem!
<paulk-collins>
lol yeah :)
<oliv3r>
i am actually thinking of asking to reschedule that bit
<oliv3r>
i think sunxi is atleast interesting for android users, and so is f-droid, those two talks kinda relate
<wens>
oliv3r: see the hdmi block diagram, there's a fifo for audio data
<paulk-collins>
oh that would be great, I'd love to attend both
<oliv3r>
paulk-collins: me too
<wens>
so much to do , so little time
<oliv3r>
yeah :(
<oliv3r>
i'm lucky I can do so much during $work hours
<mrnuke>
oliv3r: boss is on vacation?
<oliv3r>
mrnuke: no, lots of 'free' time :p
<wens>
oliv3r: you can take a look at the AC97 section in A20 manual, the link frame format pretty much says what AC97 is about
<oliv3r>
or time i get to use myself, as long as i sit at my desk and answer the phone
<oliv3r>
wens: yeah i was looking at the wikipedia and there it says 'the ac97 codec is the analog component of the arch'
<wens>
home time
<mrnuke>
LOL
<oliv3r>
wens: drive safely
ZetaNeta has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 245 seconds]
<oliv3r>
i think someone started to look at the smartcard reader aswell
FunkyPenguin has joined #linux-sunxi
<hansg>
n01, about the axp support, if you have some code you would like me to take a look at (does not need to be working) just push it somewhere and I can see if I can get it to work. For testing the interrupt the power button is a nice simple test case
<hansg>
See the powerbutton support in my axp152 driver
<hansg>
n01, ah that reminds me, I think I know what your problem might be. I've a hack to get the external interrupt used bu the axp to work somewhere, let me look it up.
<n01>
in the tree you can find: an irqchip for managing NMI and system controller, the mfd driver and the misc-input driver to control the power button
<hansg>
Note that patch is a gross hack, having an irqchip for the NMI sounds right, if you've that your probably already poking the bit ...
<n01>
hansg: yes thank you, already done that.
<hansg>
n01, I'm currently looking into usb stuff, may be a few days before I'm done with that. When I'm done I'll take a look at your code and see if I can get the power button to work.
<n01>
the problem is that when you press the button the IRQ chain is called but when the irq thread is called it looks like the interrupts are disabled and my board hungs
<n01>
hansg: thank you. I'll work on it this we also. I'll push everything on that branch
<hansg>
It sounds to me like your exiting your interrupt without clearing the interrupt source, and it keeps re-entering it
<hansg>
n01, wrt working on it this weekend, if you find a fix before I get around to it please drop me a mail.
<n01>
the nmi is cleared in the NMI irqchip. The problem is that you cannot clear the NMI pending register if you don't clear ahead the pending bits inside the axp
<n01>
hansg: I'll do
<hansg>
n01, right, you must first clear the bits in the axp, that should be done by the interrupt handler in the mfd
<hansg>
Then on exit of the interrupt handler clear the NMI pending in the irqchip
<hansg>
I assume it is possible to do something in the irqchip after calling the handler? (I've never written an irqchip driver myself)
<n01>
uhm, actually the irq thread is called with IRQF_ONESHOT so the line should be cleared after the irq thread
<n01>
my idea is that there is samething wrong in the interaction between my irqchip and GIC
<n01>
btw, the problem is that I cannot clear the bits in axp because when I enter the irq thread for accessing axp, my interrupt are kind of disabled and I cannot get the i2c interrupts -> deadlock
<hansg>
You are not doing irq_reg_writel(mask, gc->reg_base + ct->regs.ack); from handle_irq
hipboi has quit [Quit: Leaving]
<n01>
afaik it is done in handle_level_irq or handle_edge_irq
<n01>
that's why I specify chip.irq_ack
<hansg>
Ah, I see, you're probably right
<oliv3r>
mripard: A20 has a register that lists the Secure JTAG Password, how do you feel on adding that to the SID driver to display it aswell?
<oliv3r>
mripard: actualyl, nvm; it's a write-only register, e.g. to SET the jtag passwword
<hansg>
n01, Ok, so if you look at axp152.c in the sunxi-3.4 sources you'll see the trick to solve this there. Disable the irq in the irq handler, and call schedule_work to schedule a work function which can do i2c read / write transfers
<hansg>
Then in the work function when you're done re-enable the irq, and make sure that the re-enable code in the irqchip first clears the irq before enabling it (which I believe you already do)
<hansg>
Does that help ?
<hansg>
(as in does that help you to continue working on this, I understand that you cannot actually try this in a few seconds_
<libv>
oliv3r: i do not like the fact that the inet patches got squashed.
<libv>
oliv3r: 3.4 has regressed in several ways
<libv>
compared to 3.0
<libv>
this is why we now need these script.bin changes
<oliv3r>
does the previous version work with 3.0?
<n01>
the work is already scheduled with irq_threaded_request() in the mfd driver when I call regmap_add_irq_chip(). Actually I don't know if the irq for NMI is disabled. Have to check on that
<oliv3r>
i thought we stopped supporting 3.0 a while ago
hramrach has quit [Remote host closed the connection]
<libv>
oliv3r: on my hyundai a7hd i now need the same change as well
<libv>
oliv3r: i never needed it on the 3.0 kernel it was running previously
<n01>
hansg: :) yeah, I'm planning a busy we ;)
<oliv3r>
good poitn
hramrach has joined #linux-sunxi
<oliv3r>
libv: i can re-push them splitted then
<libv>
oliv3r: nah, leave it for now
<hansg>
n01, AFAIK (not sure on this at all) threaded irq handlers cannot sleep just like regular irq handlers, iow you really need to use a worker to do the i2c transfers.
bsdfox has quit [Ping timeout: 246 seconds]
<libv>
oliv3r: imho script.bin should be treated as something fixed, which you grab once and which never again needs to be changed (for the same functionality)
<oliv3r>
libv: i guess that'll be impossible for 3.0 vs 3.4 cases though
<libv>
sunxi-3.4 should be fixed to work just as well with the same script.bin
<oliv3r>
i guess since we dropped 3.0 support ...
<n01>
hansg: hooo, ok, I'll check that also. thank you for the pointer
<libv>
oliv3r: we cannot go and fix up _all_ script,bins
<oliv3r>
libv: i think you are right; but then we divert sunxi script.bin from allwinner script.bin
<libv>
oliv3r: and then also tell new board submissions to fix up their script.bin
<libv>
oliv3r: because that is what sunxi-3.4 requires right now
<oliv3r>
libv: i still have the patches so can easily pusht hem splitted
<libv>
oliv3r: we do not require it for development boards
<oliv3r>
yeah
<libv>
oliv3r: that's rather a non-issue
<oliv3r>
but that's an interesting problem
<libv>
oliv3r: the big issue is that we have broken script.bin compatibility with android
<oliv3r>
there's 3.0 script.bin; lichee-3.3/3.4-script.bin and sunxi-3.4 script.bin
<libv>
which puts us, like with the dt stuff, on the same level as other SoCs
<libv>
only good for development boards
<oliv3r>
i think the sunxi-3.4 changes are from lichee-3.3 changes
<libv>
8192cu regressing to no longer work under sunxi-3.4 was not properly dug out
<oliv3r>
i only read the top and bottom; first they where trying to find out what caused the breakage; and the bottom it was noted that it wasn't being powerd, but i saw no real fix yet
<libv>
people have just been using 8188eu
<oliv3r>
ah ok
<libv>
_and_ were then forced to hack their script.bin
FunkyPenguin has quit [Ping timeout: 264 seconds]
FunkyPenguin has joined #linux-sunxi
bsdfox has joined #linux-sunxi
focus has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
netlynx has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 264 seconds]
<andhe>
wens: If I've understood things correctly (which is not very likely), for uarts there's nothing that reserves the (gpio) pins and configures them (like direction).... only pin muxing is done in the pinctrl-sunxi driver based on devicetree information. See mmc (sunxi-mci) driver for an example of a driver which on top of the pin muxing request's the pins and sets their direction. Serial drivers on the other hand only seems
<wens>
andhe: there is a uart driver, which should reserve the pins
<wingrime>
oliv3r: whats is it?
<oliv3r>
wingrime: CAN bus, used in cars etc?
<oliv3r>
wens: welcome home!
<wingrime>
oliv3r: we have any docs for our CAN IP?
<oliv3r>
wingrime: the doc you just linked! and yeah we've put it in dl.linux-sunxi.org/A20 i think
<oliv3r>
lets not ask where he got it from
<andhe>
wens: again, to my understanding: drivers/tty/serial/8250/8250_dw.c is the driver used and I can't spot it doing any gpio/pinctrl related stuff.... also grep gpio drivers/tty/serial/8250/* returns nothing. Also, uart pins are not listed as requested in /debug/gpio
<wingrime>
mnemoc: ^^^
<wingrime>
oliv3r: also, Audio Video Sync are simple timer , why you put it in "Hard" section?
<mnemoc>
didn't the first production batch go on sale already?
<ZetaNeta>
i thinked of buying a GoPro or Sony AS15
gzamboni has joined #linux-sunxi
<ZetaNeta>
But those are action cameras, having alot of feature i dont need
<ZetaNeta>
And cant stream HD in realtime
<ZetaNeta>
And even if they could, i would need to "Spend a month with wireshark"
<ZetaNeta>
to actually find how to get the stream
jinzo has quit [Read error: Connection reset by peer]
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
vector80 has quit [Quit: Konversation terminated!]
<wolfy>
ZetaNeta: I was very happy with Logitech HD WebCam C920 ( on cubie 2 )
<ZetaNeta>
wolfy, Can it be used in portable?
<ZetaNeta>
With all the shaking and etc?
<wolfy>
ZetaNeta: I've also tested a microsoft lifecam hd 3000 but it had a very nasty autofocus feature and we ditched it
<ZetaNeta>
And... i mean the "bigger than my HDTV" picture. Not the "webcamish HD"
shineworld has quit [Quit: Leaving]
<wolfy>
both do autofocus.. otherwise no idea how they behave when shaked.
<ZetaNeta>
wolfy, Thats the main thing
agath_at_work has joined #linux-sunxi
<wolfy>
sorry. our use case involves camera fixed on top a 24" monitor :)
<ZetaNeta>
I am going to attach one either on my shoulder, either in my jacket, in the "camera pocket"
<ZetaNeta>
And walk around, recording for +12 hours
<wolfy>
gopro all the way
<ZetaNeta>
Thats why i been talking about 128gb ssd and a car battery
<ZetaNeta>
gopro doesnt last that long
<ZetaNeta>
and even if i am taking a action camera, it shall be Sony AS15
<ZetaNeta>
its better
<ZetaNeta>
I want Cubie/Olinuxino to manage the recording it down to ssd
<ZetaNeta>
not the camera
<wolfy>
I have colleagues who bought gopros and they are amazing. filmed while biking, bungee jumping, snorkeling ...
<wolfy>
and by biking I mean mountain biking
<ZetaNeta>
wolfy, Gopro: 6 hours in low quality, 64gb card, not considering the battery
<ZetaNeta>
NOT GOOD
<agath_at_work>
I hope I am not asking something already present in a FAQ (even if my searches didn't return any result yet). I'm running Arch Linux on a Cubieboard2 (Allwinner A20), and the watchdog does not work. I am trying to figure out how to update the kernel.
<ZetaNeta>
My construction: +12 hours in "UBER DUPER HD", 128gb ssd, 65ah car battery
<agath_at_work>
I read that 3.12 version should support the A20 natively. Is it possible to use it, or is there still something missing?
<ZetaNeta>
agath_at_work, Change to gentoo
<agath_at_work>
ZetaNeta: it would be an headache because I have already 50+ boards depolyed, however if it's the last chance I will think about it............. but .. why not trying to update Arch Linux?
<ZetaNeta>
+ mp3, ps3 joystick control, and a linux in the pocket
<ZetaNeta>
agath_at_work, Its just my hate of arch. Dont listen to it
<agath_at_work>
:-)
<ZetaNeta>
Atleast dont treat that as only solution
<n01>
agath_at_work: distro is unrelated to the kernel
<ZetaNeta>
What kernel are you using? Is it from arch, or from linux-sunxi?
bbrezillon has quit [Quit: Ex-Chat]
<n01>
he runs a linux-sunxi kernel
<ZetaNeta>
i remember vanilla (or arch) kernels have support for Allwinners by them self
<ZetaNeta>
but ours are better
<agath_at_work>
Actually I am running 3.3.0 (linux-sunxi), but I tried also the 3.4 version... (unsuccessfully)
<ZetaNeta>
if a kernel doesnt work, it means you didnt configure it properly. Believe me, i am a stubborn Gentoo user.
<WarheadsSE>
agath_at_work: that an A20? which one?
* WarheadsSE
read up
<agath_at_work>
it's the Cubieboard2, with the A20
<mnemoc>
3.3.0 is lichee, not linux-sunxi
* WarheadsSE
shrug, we can fix that, it was an early build to get it up.
<agath_at_work>
The Linux Kernel and modules - sun7i
<WarheadsSE>
I know the CT users have been bundling, but since we never got one
<WarheadsSE>
agath_at_work: thats out name .
<WarheadsSE>
thats because that is the SoC name
<ZetaNeta>
wolfy,
<ZetaNeta>
You said you got this camera
<ZetaNeta>
It seems to be VERY CHEAP, considering the camera i been looking at yesterday was 1599 eur
<wolfy>
I have the logitech, yes
<ZetaNeta>
Can you do a test of this camera in some hard conditions?
<wolfy>
and tested with a friend's microsoft
<wolfy>
no, I cannot test at all, it has been shipped to a remote office, out of the country
<eagles0513875>
hey all
<ZetaNeta>
Better, if on some linux. As in M$ they may have some special "Logitech drivers"
<ZetaNeta>
:P
<WarheadsSE>
also, why am I not surpised a Gentoo user is say to switch to it ;)
* WarheadsSE
is a pot
<ZetaNeta>
also, why i am not surprised why WarheadsSE knows no grammar
<ZetaNeta>
s/i/I
<agath_at_work>
religion wars :_)
<agath_at_work>
:-)
<WarheadsSE>
haha
<ZetaNeta>
agath_at_work, I know this feeling.... holding shift...
<WarheadsSE>
Oh, trust us, we would go off on certain distribution evangelists in a combined manner.
<ZetaNeta>
Recently i had to move one of my servers to freebsd....
<ZetaNeta>
#gentoo now knows how MUCH i love them all
<WarheadsSE>
Gentoo and Arch are not too dissimilar, and I have a large number of associates in that distribution
<ZetaNeta>
WarheadsSE, Gentoo, Arch and Slackware (and sometimes LFS) are considered in 1 group
<ZetaNeta>
while they are like debian and opensuse
<ZetaNeta>
but... i dare to say i dont see much difference between slack and LFS
* ZetaNeta
got hit by a random patric
<WarheadsSE>
Heh, yeah, I agree there.
ganbold_ has joined #linux-sunxi
<agath_at_work>
I used slackware at the time with kernel 1.2.8 :-)
<WarheadsSE>
Also know many of the core Slackware team
<WarheadsSE>
good fellows to go drinking with.
<agath_at_work>
at that time I was compiling kernels everyday... but after I switched to opensuse I didn't compile anymore until nowadays with the ARM stuff :-)
<netlynx>
ZetaNeta, what hard camera tests are you looking for?
<WarheadsSE>
So, whats the actual state of all hardware support in mainline then ZetaNeta, not just the watchdog.
<ZetaNeta>
netlynx, Attaching it to a human, and letting him go round in both "AHSUNBURNMYJACKET" and "Where is the ground!?!" brightness enviroments
<WarheadsSE>
And what of script.bin vs dts?
<ZetaNeta>
agath_at_work, I compiled X on a armv5 board
<WarheadsSE>
(Because, yes, I am aware that the sun7i kernel package needs a bump, but I can't spend time on research at the moment.)
<ZetaNeta>
+ Half the system
<ZetaNeta>
it wasnt so long like most of you think
<WarheadsSE>
meaning a ARM926EJS+
<mnemoc>
does the mele with a31 come with uart pins?
<libv>
mnemoc: do you have a handle on where this 8192cu driver comes from? do you perchance know which realtek release it originally was?
<ZetaNeta>
netlynx, I need to record my way "there" under the sun of Cyprus, which will first burn you umbrella, then you. (At least in summer)
<ZetaNeta>
And my way back, in complete darkness, with alot of "far away dots" lights
<mnemoc>
libv: don't remember, but the only special change there is the activation/deactivation of the usbc power on load/unload
FR^2 has quit [Quit: Connection reset by peer]
pwhalen has quit [Quit: Leaving]
<libv>
ah, this is what i had assumed...
<libv>
in the meantime, i have gotten 8192cu to work on a7hd
<libv>
this was a wpa_manager vs network manager thing
sspiff has quit [Quit: Konversation terminated!]
<netlynx>
ZetaNeta, Can't test those high brightness environments for you. Only low/normal brightness (Logitech C930).
<libv>
this usbc enabling code seems to also be present in 8188eu, but it apparently does not seem to have the same effect, i will dig into this deeper
<ZetaNeta>
Well, dont you have a desk p
<ZetaNeta>
lamp
<netlynx>
ZetaNeta, would that be a close enough imitation for you?
<ZetaNeta>
some bright lamp in the left top corner, not constantly visible
<libv>
hah.
<libv>
#ifdef CONFIG_PLATFORM_ARM_SUN4I
<ZetaNeta>
But, main thing i am worried is shaking
<ZetaNeta>
Sun could be "fixed" with filters, both hardware and software
<ZetaNeta>
But shaking... only software, and only affecting the quality
<ZetaNeta>
and not always
<libv>
yet that code is still run...
<ZetaNeta>
So just try the different types of shaking
<ZetaNeta>
thats the "main"
<ZetaNeta>
Also, would be cool if you will turn off the light. (If doing tests indoor)
<ZetaNeta>
w00tc0d3, I am reading the "3 lines privacy policy"
<ZetaNeta>
and start remembering one of my old ideas
<ZetaNeta>
to write a ToS and Privacy Policy, getting me a stable source of slaves
pwhalen has joined #linux-sunxi
<libv>
ok, seems i was totally off.
<libv>
8188eu works, a7hd does have usb_wifi_usbc_num
<libv>
but it doesn't explicitely force the usbc2
<libv>
the latter is not needed on sun4i due to the usb code being properly initialized
<libv>
with that enabled on sun7i, 8188eu works just like 8192cu
<libv>
which is relatively happy (just complains, and might break on subsequent ifup/downs) when networkmanager is properly disabled.
<w00tc0d3>
libv: you were the Mali hacker, right?
<libv>
w00tc0d3: last i checked, i still am, supposed to be, that is
<libv>
w00tc0d3: why?
<w00tc0d3>
libv: notrhing in particular, was testing my ind
<w00tc0d3>
mind*
<wigyori>
hmm, question on sunxi-mci - on 3.12, if the card(s) are removed after the driver is brought up and recognizes the card, should it rediscover if a card is inserted?
n01 has quit [Ping timeout: 264 seconds]
panda84kde has quit [Quit: Konversation terminated!]
Quarx|2 has quit []
maz_ has joined #linux-sunxi
printallthething has joined #linux-sunxi
LoCoZeNoz_ZUE has joined #linux-sunxi
ZetaNeta has quit [Read error: Connection reset by peer]
_massi_ has quit [Quit: Leaving]
maz_ has quit [Ping timeout: 252 seconds]
LoCoZeNoz_ZUE is now known as ZetaNeta
n01 has joined #linux-sunxi
<ZetaNeta>
does any board got a hdmi capturing ability?
brain_ has quit [Quit: Leaving]
<bsdfox>
sunxi android question- is there a way to install a better shell through adb? I've got a working A10 tablet with a broken FPC cable for the screen.. I want to use it for something but the existing root shell is pretty shitty. I haven't been able to find a uart on it (or at least not an active one with the boot console) so I don't like my chances of getting linux on it
<bsdfox>
root@android:/system # echo $SHELL
<bsdfox>
echo $SHELL
<bsdfox>
. /system/bin/sh
<RzR>
hi w00tc0d3 an other meego hacker's place :)
<RzR>
so is captainigloo
<libv>
RzR: there are several former nokians in here as well, ssvb and myself for instance.
<RzR>
cool
<RzR>
so you're all running mer ? :)
wolfy has quit [Ping timeout: 252 seconds]
<libv>
nope, i am using a bogstandard ubuntu, so i can concentrate on the graphics hw
netlynx has quit [Quit: Leaving]
ssvb has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
flextron has joined #linux-sunxi
<flextron>
hi!
rz2k has joined #linux-sunxi
<techn__>
libv: that bug is for hackberry which is special case
<techn__>
it has usb1 and usb2 ports which take power from usb0
<techn__>
i'm not sure if anyone has got a20 otg port working
RzR has quit [Read error: Connection reset by peer]
RzR has joined #linux-sunxi
NightShade has joined #linux-sunxi
<libv>
techn__: i have ordered some usb micro plugs so i can solder something to the id pin
<libv>
techn__: because first things first, i need to know whether the gpio attached to it really is the one it says in the script.bin
<libv>
but yeah, it does seem to need some work
<libv>
ah, i still need to get the fix to sun7i_defconfig out
Black_Horseman has quit [Remote host closed the connection]
flextron has quit [Ping timeout: 272 seconds]
stoupaxyz has joined #linux-sunxi
<captainigloo>
RzR: hey
<oliv3r>
ZetaNeta: i know what you are trying to build :) you should have used that CSI camera link i sent you :) probably easiest
<oliv3r>
ZetaNeta: also, there's backpacks with solar panels; which should help you recharge your batteries, even if you only recharge 20% during the day, that's 20% extra
<ZetaNeta>
oliv3r, battery is no longer a problem
<ZetaNeta>
I am carrying a 65ah battery
<ZetaNeta>
That should be enough for few days even if il forget to charge it
wingrime has quit [Ping timeout: 246 seconds]
<oliv3r>
wigyori: i don't think we have an mmc driver on 3.12; so after it boots from the mmc, you can't use it