<wens>
Dodger78: as i said, no cpufreq support for now
<wens>
Dodger78: and cpu usage is readily available via top and other tools
<wens>
you can even use all 8 cores
hero100 has joined #linux-sunxi
vipzrx has joined #linux-sunxi
vipzrx has left #linux-sunxi [#linux-sunxi]
vipzrx has joined #linux-sunxi
<vipzrx>
i am writing a program using the uart
<vipzrx>
it should be using "chmod 777 /dev/ttyS2", or the android issue the permision problem. so i want to change the /dev/ttyS2 to 777 at the boot stage .
<vipzrx>
i want to edit the ramdisk.img
<vipzrx>
where can i find the ramdisk.img
hero100 has quit [Read error: Connection reset by peer]
<vipzrx>
there are 137 people in this channel , but i get no response
khuey|away is now known as khuey
<wens>
ssvb: confirmed, rtc is by default secure
ninolein_ has quit [Ping timeout: 246 seconds]
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
kaspter has joined #linux-sunxi
<TheLinuxBug>
vipzrx: if you want instant gratification you came to the wrong place, if you are patient and you ask questions and when people are around that know the answer they may answer you. This isn't a place where you can just ask and everyones going to instantly rush to help you... if you need that go Google for it or RTFM :)
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
<vipzrx>
ok
<vipzrx>
i will wait
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
naobsd has quit [Ping timeout: 246 seconds]
naobsd has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
orly_owl has quit [Ping timeout: 272 seconds]
khuey is now known as khuey|away
Igorpec has joined #linux-sunxi
orly_owl has joined #linux-sunxi
Zboonet has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hero100 has joined #linux-sunxi
xenoxaos has quit [Ping timeout: 246 seconds]
avph_ has joined #linux-sunxi
xenoxaos has joined #linux-sunxi
xenoxaos has quit [Ping timeout: 246 seconds]
jinzo has joined #linux-sunxi
aez2SeWi has joined #linux-sunxi
domidumont has joined #linux-sunxi
xenoxaos has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
philectro has joined #linux-sunxi
ssvb has quit [Ping timeout: 265 seconds]
ganbold has quit [Ping timeout: 255 seconds]
ricardocrudo has joined #linux-sunxi
_massi has joined #linux-sunxi
ssvb has joined #linux-sunxi
ricardocrudo has quit [Read error: Connection reset by peer]
ricardocrudo has joined #linux-sunxi
<arete74>
pasword
FlorianH has joined #linux-sunxi
hero100 has left #linux-sunxi ["Leaving"]
ricardocrudo has quit [Ping timeout: 246 seconds]
Igorpec has quit [Ping timeout: 264 seconds]
premoboss has quit [Remote host closed the connection]
<ssvb>
wens: thanks for posting the patch, someone had to come under fire ;-)
adj_ has quit [Ping timeout: 246 seconds]
adj_ has joined #linux-sunxi
Igorpec has joined #linux-sunxi
adj_ has quit [Ping timeout: 250 seconds]
adj_ has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<wens>
ssvb: haha
paulk-collins_ has joined #linux-sunxi
<wens>
ssvb: funny thing is my primo81 still doesn't work
<wens>
maybe a bad u-boot build
<ssvb>
wens: hmm, how did you test it then?
paulk-collins has quit [Ping timeout: 250 seconds]
<ssvb>
wens: on another a31s board?
<ssvb>
wens: does primo81 not work even with a VOL+ button trick that you mentioned earlier?
<wens>
ssvb: i meant rtc still doesn't work
<wens>
it boots up fine with VOL+
naobsd1 has quit [Quit: naobsd1]
<ssvb>
wens: maybe now that's because I'm using a different kernel and an old dts for primo81?
<ssvb>
wens: can you access the relevant hardware registers via devmem2 now?
<maz_>
ssvb: that's probably because the base you're using is not the real base.
<ssvb>
maz_: the difference is that A31 does not have a gap between TZPCR0SIZE and TZPCDECPROT0Stat
<maz_>
ssvb: I see. really odd.
<maz_>
ssvb: another bunch of creative idiots, by the look of it.
<maz_>
oh well.
<wens>
sigh
<maz_>
wens: forget about my grand unification plan then.
<wens>
ok :)
<maz_>
wens: these guys should be spanked.
<wens>
for the record, could you reply to the mail thread?
<RSpliet>
vipzrx: are you sure you don't want to add the user to the "modem" group?
<maz_>
wens: sure, I'm about to do that.
<ssvb>
maz_: different TZPC implementations can probably still share a common accessors API (for example, have a common function to configure the secure SRAM size), but not the exactly same implementation
uncle_gonzzo has joined #linux-sunxi
<wens>
ssvb: secure SRAM size seems to be RO?
<uncle_gonzzo>
i saw that the dma patch in next doesn't include the dts file changes could someone add these patches into sunxi-next?
<wens>
uncle_gonzzo: depends on where the patches are
pirea has joined #linux-sunxi
<wens>
sunxi-next only has stuff that's queued for the next merge window
<maz_>
ssvb: I don't think that's worth it (each platform only has a couple of lines of code). it would have been nice if we could address them all, but if we're starting having more declarative code to express the various quirks, there is no gain.
<uncle_gonzzo>
emilio lopez send the patches for sun4i-dma. And in slave dma is only the patch for the dma-slave. The other patches emilio posted weren't applied.
<wens>
dts patches are merged through mripard's tree
<ssvb>
maz_: ok
kz1 has quit [Ping timeout: 272 seconds]
<uncle_gonzzo>
but I can't see the patches in maximes for-next free
<wens>
uncle_gonzzo: right, so they aren't merged for the next release
<pirea>
wens so 4.3 will have support for dma-slave only?
<wens>
4.3 will have the driver, not the dts bits
kz1 has joined #linux-sunxi
<pirea>
wens sweet
<uncle_gonzzo>
is there a reason maxime dosn't include the dts files?
<wens>
i think we normally merge dts after the driver is confirmed to be merged
<uncle_gonzzo>
ok
<wens>
otherwise we might break stuff that worked before
<uncle_gonzzo>
could these patches merged in rc1 for example
<ssvb>
wens: what about the usb otg in tablets? which kernel is going to have full support for it (the driver + dts)?
<wens>
ssvb: if it uses normal gpios for vbus, then its just a dts update away
<wens>
unfortunately the newer ones seem to prefer using the axp
<ssvb>
wens: so the driver is fully merged now and no last minute compatibility breaking changes are expected?
<wens>
the power-supply driver isn't in yet, nor is RSB
<wens>
ssvb: i think there are only bug fixes
<ssvb>
wens: this gpios for vbus stuff is more relevant for the tablets, which have a separate charger connector
kz1_ has joined #linux-sunxi
<ssvb>
wens: but IMHO does not have much practical use, for example, on primo81
<wens>
but if you want proper otg, you need vbus detection
<wens>
otherwise it's host only
<wens>
and some tablets use axp to drive vbus as well
<wens>
that we don't have a driver for
kz1 has quit [Ping timeout: 250 seconds]
kz1_ is now known as kz1
<ssvb>
wens: the charging hub has a third state, which unfortunately can't be detected by the primo81 hardware
adj_ has quit [Ping timeout: 240 seconds]
<ssvb>
wens: in the 'charge' state it just gets detected as a charger and can't be used for usb if the driver applies the id pin and vbus voltage detection logic
<ssvb>
wens: which is probably not always what the users want
<wens>
i wonder if that's part of the official spec
<ssvb>
wens: right now if the usb otg is hardcoded as (unpowered) host, the charging hub happens to work fine :-)
<ssvb>
wens: expected to work for both charging and data transfer at the same time on Samsung Galaxy S4, Galaxy Note3, etc.
BBerry82 has joined #linux-sunxi
* BBerry82
is using a BlackBerry Runtime for Android Apps running Android 2.3.3 (2.1.0.147)
<ssvb>
wens: they are using a special resistance value on the id pin for this third state (in addition to the standard 0 and infinity states), as discussed in some android forums
<mripard>
wens: the DT bits have been merged a loooong time ago
<mripard>
so unlike what he said, it's already there.
<mripard>
since 3.18.
reinforce has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<ssvb>
mripard: do you mean the dma stuff?
pirea has quit [Quit: Leaving]
<mripard>
yep
BBerry82 has quit [Ping timeout: 246 seconds]
hansg has quit [Quit: Leaving]
gzamboni has quit [Ping timeout: 250 seconds]
vipzrx has joined #linux-sunxi
gzamboni has joined #linux-sunxi
gzamboni has quit [Ping timeout: 255 seconds]
ssvb has quit [Ping timeout: 256 seconds]
Nacho has quit [Remote host closed the connection]
Nacho__ has joined #linux-sunxi
gzamboni has joined #linux-sunxi
fs has joined #linux-sunxi
avph has joined #linux-sunxi
fs has quit []
diego_r has joined #linux-sunxi
ssvb has joined #linux-sunxi
popolon has quit [Ping timeout: 244 seconds]
cubeast has quit [Quit: Leaving]
popolon has joined #linux-sunxi
tomboy64 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<wens>
ssvb: well, the id pin is a gpio, so only 1 or 0 :p
ganbold has joined #linux-sunxi
<ssvb>
wens: well, I had a hope that we might be able to do some hack with pull-up pull-down settings
vishnup has joined #linux-sunxi
<ssvb>
wens: the id pin is typically pulled up with a 10K or 47K resistor according to the reference schematics for different tablets
<ssvb>
wens: then we have the soc pull-up/pull-down settings
<wens>
ssvb: seems... complicated
<ssvb>
wens: one could probably design the hardware in such a way, that we could get different results depending on whether we configure the soc to pull the id pin up or down and make the threshold match this magic charging hub resistance :)
<ssvb>
wens: well, I did some experiments a while ago on primo81 and there was nothing interesting :-)
<ssvb>
wens: the id pin is strongly pulled up by the board, and pulling it down by the soc has no effect
<ssvb>
wens: anyway, for me the current host-only otg settings are perfect on primo81
GreatSage has joined #linux-sunxi
<ssvb>
wens: but if this stuff is improved to take the id pin into account and control vbus, then I will have to patch this out from the dts in order to continue using the tablet the way I want
<ssvb>
wens: there could be one more hack, based on watching the transition timings
<ssvb>
wens: I mean, we can tell the difference between 1) unplugging the regular usb hub and then plugging a regular charger 2) flipping the switch on a charging hub into the "charge" mode
leviathanch has quit [Remote host closed the connection]
<ssvb>
wens: in the former case, there will be a somewhat long period of time without vbus
<ssvb>
wens: in the latter case, 5V will become available on vbus instantly
<ssvb>
wens: this is not a pretty hack though, and requires the user to flip the switch back and forth at least once every time after rebooting the device
<ssvb>
wens: after the otg support is in a better shape in the mainline kernel, I can add all these tips and tricks to the charging hub wiki page, along with the "unofficial" patches for the kernel :-)
<libv>
wigyori: yet another kickstarter with severely dishonest marketing
<wigyori>
libv: can't argue with that, what hit my eye was the h64 in it
<maz_>
I seriously fail to see the innovation here.
<libv>
these days one needs to wonder whether there is any other kind of kickstarter
<libv>
wigyori: at least they did not lie about "open source"-ness
<libv>
at least, they didn't when i first spotted this like a month or so ago
<wigyori>
there is not a word for 'open' or 'source' on the page, so... :)
<maz_>
ah... maybe that's the real innovation.
<libv>
isn't a PC a trademark by IBM?
cnxsoft has quit [Quit: cnxsoft]
<libv>
shouldn't it come with msdos and optionally a windows version?
orly_owl has quit [Ping timeout: 265 seconds]
<Dodger78>
@wens , how can i use all cores ? how can i see which core cluster is currently active ?
<wens>
Dodger78: huh? check /proc/cpuinfo, all 8 cores should be up
Igorpec has quit [Ping timeout: 264 seconds]
<Dodger78>
hmm no only 4 are up .. dmesg says some cores are "disabled" . do i need to correct your patch regarding the PRCM adress copynpaste problem ?
<Dodger78>
the exact message about it is : CPU4: shutdown
<Dodger78>
this happens for 5,6,7 also
<Dodger78>
proc/cpuinfo shows only the little cores i guess ...
<Dodger78>
is prcm @ 01700000 or 08001400 , is the 0x200 correct ? the mailing list mentioned a copypaste problem
<wens>
funny...
<wens>
Dodger78: did you turn on big.LITTLE switcher?
<Dodger78>
yes
<wens>
if you did, turn it off, then you get all 8 cores
<Dodger78>
ook . do i need to correct the prcm entry ?
<wens>
the address after the "@" doesn't matter, it's just the node name
<wens>
the value in the "reg" property does
<Dodger78>
ok, so this is correct ?
<wens>
yes, otherwise you won't get the extra cores
<Dodger78>
and another question, your code is intended to show all 8 cores and will switch load from little to big if a limit is reached ?
<wens>
switching and stuff is done by common code
<wens>
i just gave it the callbacks to bring up and down cores
<Dodger78>
so the big little switcher is destroying your functionality ?
FlorianH has quit [Ping timeout: 272 seconds]
FlorianH has joined #linux-sunxi
Igorpec has joined #linux-sunxi
Dodger78 has quit [Ping timeout: 264 seconds]
FlorianH has quit [Ping timeout: 256 seconds]
afaerber has joined #linux-sunxi
<wens>
what? no, it's a big.little arch
<wens>
you turn on the switcher, of course it's going to choose either cluster, but not both
<maz_>
nobody should select the BL switcher. ever.
<wens>
why is it there in the first place
<maz_>
because some people still think this is a great idea.
<maz_>
hopefully we'll never have this on 64bit.
* NiteHawk
is confused
<NiteHawk>
i don't get this "switcher" thing. wasn't the whole point of big.LITTLE architecture that the transition was supposed to automatic / "transparent" to the user?
<NiteHawk>
*to be
<NiteHawk>
i.e. you have 4 cores and don't bother whether they're currently running in A7 or A15 mode
<maz_>
NiteHawk: there is a different between a marketing plan and a properly engineered solution.
<maz_>
*difference
<maz_>
the real solution is not to pretend that A7 and A15 are the same thing - they are incredibly different.
ialokin has joined #linux-sunxi
<NiteHawk>
meaning what? these socs aren't capable of managing the transition themselves and need software help (from the kernel)?
<maz_>
we have a decent scheduler, we can teach it to migrate tasks as required
<maz_>
NiteHawk: look at the TRMs for A7 and A15, spot the differences.
<maz_>
NiteHawk: different PMUs, different caches
bonbons has joined #linux-sunxi
<maz_>
nicksydney: and now try to combine things like real-time, or virtualization together with that.
<maz_>
oh wait, you can't.
<maz_>
NiteHawk: ^^
<NiteHawk>
well, until now i had supposed that all that stuff gets managed "in silicone" - obviously it isn't. and that indeed makes the whole big.LITTLE story a bit moot
RSpliet has quit [Read error: Connection reset by peer]
RSpliet has joined #linux-sunxi
<maz_>
nicksydney: absolutely *nothing* in big-litle in is silicon. This is purely a software thing.
<maz_>
NiteHawk: the big-little story is actually very interesting (and not moot at all). but the switcher is not the solution at all.
<NiteHawk>
oh... with a big :O
<maz_>
NiteHawk: and frankly, I have a hard time imagining how you would do that in HW, as the HW has strictly no knowledge of the workload...
diego_r has quit [Ping timeout: 260 seconds]
Zboonet has quit [Read error: Connection reset by peer]
Zboonet has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ialokin has quit [Read error: Connection reset by peer]
ialokin has joined #linux-sunxi
vishnup has quit [Quit: Leaving]
bmeneg has joined #linux-sunxi
<bmeneg>
Hello, I would like to know the right place to look for the image and script memory addresses to use at uEnv.txt or boot.scr, someone know where to look for it? I know it is platform specific but I didn't find anything on it's user manual document.
<bmeneg>
More specifically it is a sun7i A20 SoC
<bmeneg>
I know there is the 0x40008000 specified at linux-sunxi.org for nand boot, but where do they found it?
<bmeneg>
NiteHawk, hmm thank you very much! I will take a look.
enrico_ has quit [Quit: Bye]
ialokin919 has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ialokin has quit [Ping timeout: 265 seconds]
_massi has quit [Remote host closed the connection]
orly_owl has joined #linux-sunxi
ialokin919 has quit [Ping timeout: 244 seconds]
<ssvb>
bmeneg: these addresses are a purely software thing and arbitrarily selected, you can't find this information in the hardware documentation
<ssvb>
bmeneg: basically, one needs to pick some areas in DRAM, which are not overlapping each other (and anything else)
domidumont has quit [Read error: Connection reset by peer]
<ssvb>
bmeneg: the installation guides in the wiki typically stick to some set of good known addresses, mostly for the sake of consistency :-)
<bmeneg>
ssvb, isn't there any relation to hardware? Mmm.. ok, but everywhere I see is the same addresses. I mean, every uboot implementation (from different sources) uses the same, I thought it was related somehow.
<bmeneg>
ssvb, Ahh.. interesting! I understand.
<bmeneg>
ssvb, so I could load my images anywhere in the DRAM and start from it?
<bmeneg>
ssvb, thank you very much.
<bmeneg>
ssvb, indeed this is the obvious startup process of any kernel xD.
<ssvb>
bmeneg: the chances are that this will work fine, unless you mess up something and make a mistake (like assigning an address, which falls outside of the DRAM valid addresses range)
<ssvb>
bmeneg: it is always safer to use something, that has been tested by other people
<bmeneg>
ssvb, Mmm... interesting! I was looking for something like that.
<bmeneg>
ssvb, but the are just default values, I could use others.
<bmeneg>
yeah, they are just env values.
jelly has joined #linux-sunxi
<bmeneg>
ssvb, thank you very much. I am really new on embedded linux development and some things just seems "magic" yet :)
<bmeneg>
ssvb, just tell me another thing, the mainline uboot supports A20 NAND boot? I have a .dtb file with this support, but does it make any different if the uboot doesn't maps the nand or something like that?
<ssvb>
bmeneg: I'm not into NAND stuff myself, but it's a work in progress
<ssvb>
bmeneg: not everything might be fully implemented yet
<ssvb>
bmeneg: which version of u-boot are you talking about?
<bmeneg>
ssvb, I have one 2011.09 working over NAND but I would like to update to the mainline 2015.x
<ssvb>
bmeneg: 2011.09 uses the original code from Allwinner, basically the same stuff that works on android tablets
<ssvb>
bmeneg: NAND support is a very new thing for the mainline U-Boot, AFAIK it has not even made it to any formal U-Boot release yet
<bmeneg>
ssvb, Mmm... right!
<bmeneg>
ssvb, thank you for everything!
jinzo has quit [Remote host closed the connection]
ialokin has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
khuey|away is now known as khuey
17SADETWG has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
17SADETWG has quit [Quit: Lost terminal]
paulk-collins_ has quit [Ping timeout: 245 seconds]
<arnd>
mripard: in https://github.com/NextThingCo/CHIP-linux/commit/5abbaed135b1fc6f6074e27890daabec206df1cc, you write "SDIO chips don't have any kind of DT support". Is that still true? I thought that was fixed a while ago, and e.g. Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt describes the binding for an SDIO wifi chip with DT properties
adj_ has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
Andy-D has joined #linux-sunxi
Dodger78 has joined #linux-sunxi
<Dodger78>
@wens , does the kernel on A80 with your patches know, that its smarter to schedule to cpus 4-7 since they are faster ? when i do a make -j2 it seems that the load is spread across all cpus
ricardocrudo has quit [Ping timeout: 260 seconds]
ricardocrudo has joined #linux-sunxi
bmeneg has quit [Quit: Leaving]
pirea has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 255 seconds]
L0op has joined #linux-sunxi
<L0op>
hi, I need to ask a question but it's about a clone so I'm not sure if this is the right place
<L0op>
I'll figure it out by myself, thanks
L0op has quit [Client Quit]
\\Mr_C\\ has joined #linux-sunxi
pirea has quit [Quit: Leaving]
MaDMaLKaV has quit [Read error: No route to host]
viccuad has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
philectro has quit [Quit: Konversation terminated!]