<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>
mturquette: the uglyness of the code shouldn't affect the thermal effects, so if you want to experiment, http://goo.gl/1snbQ
<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]
<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
<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: http://pastie.org/7827938
<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 kernel.org
<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
<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_>
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.
<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.