ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
deasy has joined #linux-sunxi
<Turl> BJfreeman: ah, I assumed you were using the bsp somehow, sorry
<BJfreeman> np, the chain is the make for the easycap call the /lib/modules/3.0.42+ the symblink build points to the make file in linux-sunxi. the makefile in linux-sunxi gives these errors
<BJfreeman> Makefile:327: /data/a13/linux-sunxi/scripts/Kbuild.include: No such file or directory
<mturquette> Turl: pong
<Turl> mturquette: pretty high latency :)
<Turl> mturquette: I wanted to ask you for your thoughts on some clock code
<Turl> mturquette: not sure if you recognise me with this name, but I'm Emilio, and I've been working on the sunxi clk driver
<mturquette> Turl: hi Emilio! good to meet you on irc ;-)
<mturquette> yeah, sorry for the high latency. what's your question?
<Turl> :)
<Turl> it turns out some PLLs have multiple outputs
<Turl> like, one output with divisor and one without
<Turl> or one with divisor M and other with P
<Turl> do you have any ideas on how to implement it nicely?
<Turl> should I just make child clocks configuring each divisor as applicable?
<mturquette> i typically model each divider coming off of a pll as a separate clock
<mturquette> because it is ;-)
<mturquette> for instance on OMAP we have these HSDIVIDERS (high speed dividers) as children of every PLL
<mturquette> anywhere from 1 HSDIVIDER up to 6
<mturquette> for OMAP it's convenient b/c the programming model fits nicely with the basic clk_divider type
<mturquette> perhaps for sunxi the same can be done
<Turl> I think so, yes
<Turl> on their ugly code AW had fancy names for the divisors too I think
<mturquette> all that matters is programming model
<mturquette> and i try not to think of a clock having multiple outputs
<mturquette> i think of lots of children having the same parent ;-)
<mturquette> that sometimes makes the design more clear, at least for me
<Turl> makes sense :)
<Turl> thanks mturquette
<Turl> mturquette: also, you were talking about dvfs the other day
<Turl> mturquette: even if you don't have a regulator, cpufreq should be doable :)
<mturquette> yes, which will save a small bit of power and potentially help with thermal issues
<mturquette> but calling clk_set_rate from a cpufreq .target callback is easy
<mturquette> in particular i'm trying to make clk_set_rate also scale voltage
<mturquette> also, i've never seen a cortex-a8 system actually have thermal issues... so i wonder how useful cpufreq would be on a board like the olinuxino-micro
<mturquette> but running at the highest frequency might shorten the chips end-of-life, so probably good to still use ondemand governor or something
<Turl> mturquette: I haven't had any thermal issues on my cubieboard
<Turl> at least that I noticed
<mturquette> does that board use the QFP package chip?
<Turl> might be because I have cpufreq patched in though
<Turl> mturquette: it's an A10, let me check the package
<Turl> AW doesn't list the package type :/
<Turl> mturquette: TFBGA441 says the datasheet
<mturquette> is it bigger than US quarter?
<mturquette> ;-)
<Turl> I haven't ever seen a US quarter :)
<Turl> so bigger than 15x15 I suppose
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<Turl> mturquette: the uglyness of the code shouldn't affect the thermal effects, so if you want to experiment,
<mturquette> Turl: the smaller process omap chips that shipped in smartphones are smaller than the finger nail on most people's tiny finger
<mturquette> Turl: including the stacked memory part!
<mturquette> Turl: often the bigger chips just don't have the thermal issues that the advanced process chips have
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
mdfe_ has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
mdfe has quit [Ping timeout: 276 seconds]
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
<drachensun> oliv3r: I compared them side by side, the dram struct is very different and the gpios aren't matching up, I think I've got a good handle on in though, they are more similar than I first thought
<drachensun> on it I mean
rz2k has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
mturquette has quit [Quit: leaving]
oliv3r has quit [Ping timeout: 260 seconds]
rellla has joined #linux-sunxi
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 256 seconds]
el has quit [Ping timeout: 256 seconds]
el has joined #linux-sunxi
eebrah|away is now known as eebrah
n01|afk is now known as n01
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
deasy has quit [Ping timeout: 264 seconds]
gzamboni has quit [Ping timeout: 276 seconds]
rellla has joined #linux-sunxi
egbert has joined #linux-sunxi
egbert_ has quit [*.net *.split]
rellla2 has quit [*.net *.split]
_BJFreeman has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
BJfreeman has quit [*.net *.split]
ssvb has quit [*.net *.split]
ssvb has joined #linux-sunxi
ssvb has quit [Excess Flood]
ssvb has joined #linux-sunxi
andoma_ has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
eebrah- has joined #linux-sunxi
andoma has quit [Ping timeout: 264 seconds]
eebrah has quit [Ping timeout: 264 seconds]
oliv3r has joined #linux-sunxi
<oliv3r> moo
paulk-desktop has joined #linux-sunxi
gzamboni has joined #linux-sunxi
mdfe_ has quit [Remote host closed the connection]
tinti has joined #linux-sunxi
vicenteH has joined #linux-sunxi
ganbold__ has joined #linux-sunxi
vicenteH has quit [Read error: Operation timed out]
eebrah- is now known as eebrah|away
eebrah|away is now known as eebrah
eebrah is now known as Guest43553
fredy is now known as mikeX
mikeX is now known as fredy
Guest43553 is now known as eebrah|away
lkcl has quit [Ping timeout: 268 seconds]
rellla has quit [Quit: Nettalk6 -]
_BJFreeman is now known as BJfreeman
shineworld has joined #linux-sunxi
tinti_ has joined #linux-sunxi
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
deasy has joined #linux-sunxi
lkcl_ has joined #linux-sunxi
deasy has quit [Quit: *freesoftware song* :p]
rellla has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
hipboi|cubie has quit [Ping timeout: 264 seconds]
hipboi|cubie has joined #linux-sunxi
ganbold___ has joined #linux-sunxi
ganbold__ has quit [Ping timeout: 255 seconds]
KamiKaze_Phoenix has joined #linux-sunxi
<KamiKaze_Phoenix> hello
<KamiKaze_Phoenix> i search .config for 3.4.4 kernel with lcd support for linux-sunxi ?
<KamiKaze_Phoenix> for debian
simosx has joined #linux-sunxi
simosx has quit [Changing host]
simosx has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 -]
<KamiKaze_Phoenix> pff
<techn_> KamiKaze_Phoenix: lcd support?
rellla has joined #linux-sunxi
<hno> mnemoc, no I dit not extract files from livesuit images. Got them from the SDK releases, and dumped boot0 from NAND on some devices.
<drachensun> hno: I think I have a handle on the format now, the dram parameters have changed but the new struct is also available in the kernel struct
rellla has quit [Quit: Nettalk6 -]
vinifm has joined #linux-sunxi
<hno> drachensun, a bit of context please. I assume we talk about boot0, but for what?
<hno> A31?
<drachensun> yup
<drachensun> I got U-boot to create an SPL
<drachensun> but the BROM is ignoring it
<drachensun> so I thought maybe the header is invalid
<drachensun> and I dumped a few headers from A31 firmwares I could download
<drachensun> it does seem to be different
<drachensun> so I am reverse engineering it now
<drachensun> I actually just had an A31 dev kit arrive today as well
mdfe has joined #linux-sunxi
<drachensun> but despite their promises, they didn't send _any_ documentation with it
<hno> Is A31 sun6i? or something else?
<mnemoc> a31 and a31s are sun6i, a20 is sun7i
<mnemoc> sun6i has a "little" opencore companion (called ar100) doing the power management and other stuff
<mnemoc> which firmware is a blob
mturquette has joined #linux-sunxi
<hno> opencore?
<mnemoc> openrisc I mena
<mnemoc> mean
<mnemoc> some think this ar100 thing will be in charge of baseband stuff in their a31s "phablet" thing
<rz2k> oh god no, please no. then they will go nuts with encryption
<rz2k> no gsm modems in our sunxi stuff, please.
<mnemoc> the a31s-dev branch in my github is the most ugly thing I've ever seen
<mnemoc> impossible to rebase
<hno> interesting
<rz2k> allwinner doing its best as always
<hno> mnemoc, have you seen any NAND driver for A31?
<rz2k> (or they lost Tom and Benn and now there are nobody to insist on reading the Documentation/ directory)
<hno> source
<rz2k> hno: but you said that it was blob (somewhere on ML)
<rz2k> or it was the new emac...
<mnemoc> rz2k: in the SDK they distribute it as modules/libnand(.o)
techn__ has joined #linux-sunxi
<mnemoc> but in some parts of the -dev history the code remains
<mnemoc> hno: ignore those URLs
<mnemoc> 1m
techn_ has quit [Ping timeout: 260 seconds]
<mnemoc> hno: see /query
rz2k has quit []
<hno> mnemoc, that does not look like any allwinner nand drivers in those URLs.
<mnemoc> hno: right. my mistake
<hno> so we have no public sources for the A31 NAND driver?
<mnemoc> seems so
<mnemoc> but there are more sun6i -dev branches to check
eebrah|away is now known as eebrah
tek_0 has joined #linux-sunxi
ganbold___ has quit [Remote host closed the connection]
ganbold___ has joined #linux-sunxi
<hno> I am pretty sure the Allwinner NAND driver development have moved to some locked down place for some reaseon.
<hno> feels like a off piece to lock down.
<hno> s/off/odd/
<hno> mnemoc, where did you find out about the openrisc core?
<mnemoc> I was told ar100 was openrisc by tom iirc
shineworld has joined #linux-sunxi
<mnemoc> and i think someone confirmed the blob is for openrisc
<KamiKaze_Phoenix> search for .config for a13 olinuxino wifi ?
<shineworld> Hi all, I'm trying to use LiveSuit after a long time of SD usage, and after some kernel update too, but I've got some problems after OK to format:
<shineworld> have you any suggestion ?
vinifm has quit [Ping timeout: 245 seconds]
<KamiKaze_Phoenix> for 3.8 or > kernel...
<Turl> KamiKaze_Phoenix: multi_v7_defconfig should work
<mnemoc> KamiKaze_Phoenix: beware the is no storage support up there yet
<mnemoc> so it's still devs-only realm
mdfe has quit [Remote host closed the connection]
<KamiKaze_Phoenix> Turl: you can i can make linux kernel 3.8 or 3.9 for a13 olimex.... i try 2 last days.....
<KamiKaze_Phoenix> i haven t the good cmd.... i cross compil on debian
<techn__> KamiKaze_Phoenix: you have uart?
<KamiKaze_Phoenix> usb to uart cable ?
<techn__> yep
<KamiKaze_Phoenix> yes i have the olimex a13 pack
<KamiKaze_Phoenix> i take .config for sunxi-linux 3.4.X, and make olconfig ?
<Turl> KamiKaze_Phoenix: no
<Turl> KamiKaze_Phoenix: 'make multi_v7_defconfig' then 'make uImage sun5i-a13-olinuxino.dtb'
<KamiKaze_Phoenix> turl with the last 3.9X kernel source ?
<Turl> then on uboot you need to load both dtb and uImage and use 'bootm 0xkernel - 0xdtb' where 0xkernel and 0xdtb are the right addresses where you loaded them
<Turl> KamiKaze_Phoenix: yes, or master on torvalds' repo
<KamiKaze_Phoenix> oki from
<Turl> KamiKaze_Phoenix: do you plan on using it for something?
<KamiKaze_Phoenix> carputer, cam, phone etc
<Turl> KamiKaze_Phoenix: you should use 3.4 from linux-sunxi then
<Turl> KamiKaze_Phoenix: 3.8+ has no usb, wifi, sata, audio
<techn__> KamiKaze_Phoenix: there is current mainline status:
<Turl> it only has gpio
shineworld has quit [Ping timeout: 246 seconds]
<Turl> see that page for what's supported ^
<KamiKaze_Phoenix> ok it s for somagic capture driver
<KamiKaze_Phoenix> is in 3.8 or > kernel i think
<Turl> v4l people backport their stuff I think
<Turl> I got to go, see you guys later
<KamiKaze_Phoenix> linux-sunxi i have this 3.4.43 but i havent lcd 7" working.....
<KamiKaze_Phoenix> only on 3.0.X...
shineworld has joined #linux-sunxi
<KamiKaze_Phoenix> linux-sunxi 3.4.43+ have LCD support on olinuxino a13 WIFI ?
<KamiKaze_Phoenix> with debian ?
vinifm has joined #linux-sunxi
<techn__> 3.4 should support same as 3.0
<KamiKaze_Phoenix> f... i am a bad compiler...
<techn__> plan is to deprecate 3.0 in near future
<KamiKaze_Phoenix> i use this for make kernel, is good ?
<KamiKaze_Phoenix> with last git linux-sunxi ?
<KamiKaze_Phoenix> us hf for compil
<techn__> plan is to have 3.4 as preferred kernel
<techn__> KamiKaze_Phoenix: there is another guide
<KamiKaze_Phoenix> ok thk for all, return to my kernel compil problem :D
<KamiKaze_Phoenix> good is you re work
KamiKaze_Phoenix has left #linux-sunxi [#linux-sunxi]
<shineworld> segmentation fault also with su:
<shineworld> Dev Plugin The Device Path is: /dev/aw_efex0
<shineworld> /home/shine/Bin/LiveSuit/ line 28: 8910 Segmentation fault (core dumped) $BinDir/$AppName "$@" > /dev/null
<shineworld> anyone use LiveSuit with ubuntu 64 bit here ?
<shineworld> should be called with normal user or su or sudo ?
deasy has joined #linux-sunxi
<hno> mnemoc, where is the openrisc blob?
<hno> found it.
deasy has quit [Client Quit]
<shineworld> Now I've more detailed info:
<shineworld> seem something in parsing fex file ?
<shineworld> never see before when some weeks ago I've used LiveSuit to change nand content
<shineworld> uhm... downloading the official image all works fine
<drachensun> I'm confused about the boot0 private header referenced here
<hno> what about it?
<drachensun> oops here
<drachensun> ok, I see that mksunxiboot prepares the public header
<drachensun> where is the private header? it should be right after it right?
<hno> drachensun, see bootinfo.c.
<hno> in sunxi-tools
* hno should add NAND info there as well, now that the NAND boot params struct have been found in kernel source scrap.
<drachensun> ok, well I see thats got the setup
<drachensun> but I thought when you made the SPL it has to have the boot0 header for the BROM to recognize it, where does the SPL define the private side of that header?
<drachensun> the dram parameters struct looks different in the sun6i
<drachensun> so I need to make sure it is creating that correctly now
e-ndy_ has quit [Remote host closed the connection]
<hno> drachensun, the private side of the header is up to the maker of the SPL to define. BROM do not care. We do not use a private header in u-boot SPL.
<drachensun> ah ok
<drachensun> hmmm ok, wrong tree then
<drachensun> as in barking up the wrong tree
<hno> The public header contains version information etc so tools can know they operate on the right thing.
<drachensun> well the platform numbers are different
<drachensun> I'm trying to figure out why the BROM blows by the SPL I have created
<hno> drachensun, what do you mean by "blows"?
<drachensun> well it goes on and boots from nand
<mnemoc> then it's simply ignoring it
<hno> So it rejects the SPL as invalid
<drachensun> as if the SD card didn't have an SPL,
<drachensun> yeah I think so
<mnemoc> tried to make a phoenixcard of an a31 liveusit image?
<hno> The A10 BROM checks very little beside the checksum. No idea what the A31 does but I can imagine it checks a little more to avoid people accidently trying to boot A10 code.
<drachensun> I'm sure the SPL isn't right internally, but I figure it would be freezing or reseting if it actually tried to run it
<hno> drachensun, it's easy to dump BROM from u-boot.
<mripard_> drachensun: have you read ?
<drachensun> mripard_: nope, reading now
<mripard_> it looks like you can't expect the A31 to just pick up a bootloader on the SD card like the A10/A13 did
<mripard_> you have to push the fel button
<mnemoc> uh
<drachensun> ugh
<mripard_> depending on your hardware, you maybe won't have a way to select the boot device you want to boot on
<mnemoc> not nice
<drachensun> man, I asked this question directly to wits to
<hno> True, If there is no "uboot" button to force FEL mode then it's hard.
<drachensun> and got the dance
<drachensun> I should have paid more attention to what that probably meant
<mripard_> drachensun: what device are you booting it on?
<drachensun> Well I wanted to boot it on an SD card
<drachensun> its booting of nand with the stock Android now
<mripard_> yeah, but I mean, what board/device?
<drachensun> Oh
<drachensun> I've got a mele M7 tablet
<drachensun> and just today
<drachensun> and a31 dev kit from wits
<mnemoc> *envy*
<hno> drachensun, no recovery button on the tablet?
<drachensun> hno: nope, just looked when this came up
<mripard_> drachensun: for the devkit, you have the uboot button.
<mnemoc> how are you supposed to upgrad it's "firmware"?
<drachensun> yup, it has one
<drachensun> but I'm just thinking for my goals
<hno> mnemoc, by soft recovery button just like most A10 devices.
<mripard_> drachensun: just nearby the TV-in connectors
<drachensun> I'm going to have to focus on a nand based boot
<mnemoc> hno: :(
<drachensun> yeah, so the dev kit has the button, the m7 tablet and the other tablets with the A31 I have gotten dont have one
<mnemoc> removing the automagic booting from uSD is evil :(
<drachensun> seriously, that was a great feature
<mnemoc> it's what gives the unbrickability
<hno> drachensun, not even a test pin on the board?
<hno> test pad
<hno> drachensun, any pictures of the M7 board?
<mnemoc> drachensun: can you make pages for them in the wiki and upload pictures?
<drachensun> hno: nothing obvious, all the tablet boards have a ton of unmarked test points though
<drachensun> yeah, I'll go ahead and put some up
<drachensun> I didn't want to play with the nand flash yet because I don't have a recovery image for either device
<drachensun> of course I have images for my devices without uarts
<drachensun> mripard_: Do you have the stock image for the dev kit?
e-ndy has joined #linux-sunxi
<drachensun> I think they were supposed to send me a download link but haven't yet
<mripard_> drachensun: no :(
<mripard_> k
<hno> drachensun, have you tried holding down all buttons at power on? Some wire the LRADC button chain to uboot as well.
<drachensun> ok, I'll try that
<drachensun> well hey that might have worked
<drachensun> it just sits there when I do that, which sounds a lot like the result of booting a first try development SPL
<drachensun> yup, so I have to release the buttons and hard reset to get it running again
<drachensun> so yeah, that will make it try and boot from the SD I think
<drachensun> well good, thats workable
<drachensun> alright well family stuff has come up, I wont be upload the pictures now, hopefully soon
<drachensun> thanks for the help
<hno> drachensun, are you sure it didn't just enter FEL mode?
<hno> because the buttons is used by allwinner bootloaders to enter fel mode as well.
<hno> mnemoc, yes the ar100.code blob do look very much like it could be OpenRISC, but it's oddly using little endian data where the rest of the OpenRISC world is using big endian.
<hno> not even aware that the tools handle little endian data.
<mnemoc> uhm
<hno> But all instruction sections do decode nicely as OpenRISC and seems to make some sense as well.
shineworld has quit [Quit: Leaving]
deasy has joined #linux-sunxi
simosx has quit [Quit: Αποχώρησε]
deasy has quit [Client Quit]
<ssvb> hno: which tools are you looking for?
<ssvb> I guess using little endian makes a lot of sense because that's what is used for ARM
<ssvb> avoids the troubles of byte swapping for any possible arm<->openrisc data exchange
tek_0 has quit [Quit: Bye bye]
<hno> ssvb, gcc and friends.
<ssvb> hno: openrisc folks are supposed to have all of this
<ssvb> but maybe not in the mainline gcc yet
<hno> There is no public little-endian OpenRISC implementation. And the ar100 is not even that, code is still big-endian only data is little-endian.
* hno works with OpenRISC programming.
<hno> It's like they have taken a big endian OpenRISC core (quite likely or1200) and just byte swapped the databus but not the instruction bus.
<vinifm> ssvb, i tested small videos with lib buggy linux, there is not problem
<vinifm> flawless
<ssvb> hno: hmm, the code looked little endian to me
<hno> ssvb, yes you are right. It's all little endian.
<hno> makes more sense now.
<hno> looks like it's really compiled as big-endian code but byteswapped to little endian.
tinti_ has quit [Remote host closed the connection]
<hno> 'From a quick analysis of the OpenRISC code it seems to handle deep sleep & suspend modes where pretty much everything else in the SoC is powered off. Earlier this was done by the "standby" ARM code running from SRAM with the CPU at lowest possible frequency.
<hno> Wonder if there is a UART port for the AR100. There is lots of debug messages.
rellla has joined #linux-sunxi
<hno> Turl, yes I noticed.
<hno> I would guess it's sharing UART0.
vinifm has quit [Quit: Saindo]
<Turl> any idea what's ac327?
<hno> ac327 seems to be some code name for the main CPU.
<hno> was wondering the same before, but quite obvious hints at the link above.
<Turl> ARM Core 327 maybe?
<hno> I would guess A is Allwinner. Matches better with AR100 being the name of the OpenRISC one.
paulk-desktop has quit [Quit: Ex-Chat]
<Turl> makes more sense, yep
lunra has quit [Ping timeout: 252 seconds]
lunra has joined #linux-sunxi
bsdfox\ has joined #linux-sunxi
deasy has joined #linux-sunxi
cajg has quit [Ping timeout: 264 seconds]