<wens>
But that spawn the very long thread [0] mentioned
<wens>
above and I've zero interest in joining that discussion...
<wens>
--
<wens>
lol
<Turl>
:)
<Turl>
good night
physis has joined #linux-sunxi
physis has quit [Ping timeout: 245 seconds]
<wens>
gn
ricardocrudo has quit [Ping timeout: 276 seconds]
Andy-D has quit [Ping timeout: 268 seconds]
FDCX has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<wens>
starting to do manual merge of sun6i from u-boot-sunxi to u-boot
ricardocrudo has quit [Remote host closed the connection]
Gerwin_J has quit [Ping timeout: 250 seconds]
hramrach has quit [Remote host closed the connection]
hramrach has joined #linux-sunxi
<plaes>
wens: good luck
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
weissschloss has quit [Remote host closed the connection]
imcsk8 has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
naobsd has joined #linux-sunxi
tomcheng86 has quit [Quit: leaving]
Black_Horseman has quit [Ping timeout: 252 seconds]
physis has joined #linux-sunxi
tomcheng76 has joined #linux-sunxi
akaizen has joined #linux-sunxi
physis has quit [Ping timeout: 255 seconds]
froese has quit [Ping timeout: 245 seconds]
froese has joined #linux-sunxi
Faisal has quit [Ping timeout: 260 seconds]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has joined #linux-sunxi
mmarker1 has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
amitk has joined #linux-sunxi
cubear has joined #linux-sunxi
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
FreezingCold has quit [Ping timeout: 252 seconds]
physis has joined #linux-sunxi
Zboonet has joined #linux-sunxi
physis has quit [Ping timeout: 252 seconds]
FreezingCold has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
<libv>
hramrach: i was about to send new patches, and a usage mail
<libv>
i will also try to send a mail about a31(s)/a23/a33/a80 initial support strategy today
<libv>
urgh, our main page looks terrible now
<libv>
any thoughts?
<ssvb>
libv: do you mean the bold red statements, which are supposed to scare away the users and encourage them to pick some other SoC?
akaizen has joined #linux-sunxi
<libv>
it's too bold
<libv>
and especially the red one is over the top
<libv>
the gpl violations need to be mentioned, but they should not be this bad :)
philippe_fouquet has joined #linux-sunxi
physis has joined #linux-sunxi
<ssvb>
the main page nicely represents linux-sunxi as an "advanced" community of blob ridden kernel users
physis has quit [Ping timeout: 264 seconds]
sehraf has joined #linux-sunxi
<philippe_fouquet>
hi
<philippe_fouquet>
I don't now if is it the good channel?
<philippe_fouquet>
I designed a new board from scratch on allwinner A20
<philippe_fouquet>
But I can't load on FEL mode
<hramrach>
ugh
<philippe_fouquet>
wen I run the fel version command I recive all inforation but with the command fel write ... I have a error "libusb usb_bulk_send error -99"
<hramrach>
technically, this is the right channel but not many people designing boards
<philippe_fouquet>
and the system doesn't respond any more
<hramrach>
anyway, FEL is triggered either by all devices being invalid or by changing the leve on some pin of the SoC which is sometimes available as a button on boards
<hramrach>
presumably your nand is empty so if it does not work you broke something ;-)
<philippe_fouquet>
I uesd the pin UBOOT_SEL (W8) for triged the fel mode
<philippe_fouquet>
it sure my nand is empty the board come from the factory
<hramrach>
then it should enter fel mode regardless
<hramrach>
which would make sense if the previous call failed
<philippe_fouquet>
yes it sure
diego_r has joined #linux-sunxi
<philippe_fouquet>
I check the usb link
physis has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
philippe_fouquet has quit [Remote host closed the connection]
Zboonet has quit [Ping timeout: 240 seconds]
Quarx has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
kz1 has quit [Ping timeout: 268 seconds]
notmart has joined #linux-sunxi
FR^2 has joined #linux-sunxi
notmart has quit [Excess Flood]
notmart has joined #linux-sunxi
linkmauve1 has left #linux-sunxi [#linux-sunxi]
<philippe_fouquet>
when I try to load the u-boot-spl.bin at 0x2000 with command "fel write" where it writed in A20 cache memorie or in DDR3 memorie?
<philippe_fouquet>
when I debug the USB command in fel process I could see that the first write (offset sending) it work but it fail when it try to send the data
<mnemoc>
you don't have access to the dram at that point
<mnemoc>
only sram
<philippe_fouquet>
the sram are internal to A20
<mnemoc>
yes, inside the SoC
<philippe_fouquet>
ok thank
notmart has quit [Remote host closed the connection]
<mnemoc>
u-boot-spl.bin's job is not initialize the dram :p
notmart has joined #linux-sunxi
<philippe_fouquet>
where coudl be my fault the USB link coulbe ok, I can get version, dump, read but i can't right
Quarx has quit [Ping timeout: 250 seconds]
<mnemoc>
wrong address probably
<philippe_fouquet>
write
<philippe_fouquet>
i used A20 and i try to write at 0x2000 (like in linux-sunxi.org)
linkmauve1 has joined #linux-sunxi
physis has joined #linux-sunxi
physis has quit [Ping timeout: 272 seconds]
_massi has joined #linux-sunxi
RaYmAn_ is now known as RaYmAn
notmart has quit [Remote host closed the connection]
t3ngu has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
notmart has quit [Excess Flood]
naobsd has quit [Quit: Page closed]
Net147 has joined #linux-sunxi
deasy has joined #linux-sunxi
physis has joined #linux-sunxi
physis has quit [Ping timeout: 245 seconds]
avsm has joined #linux-sunxi
Zboonet has joined #linux-sunxi
sehraf has quit [Ping timeout: 272 seconds]
physis has joined #linux-sunxi
physis has quit [Client Quit]
Renard has joined #linux-sunxi
_massi has quit [Remote host closed the connection]
avsm has quit [Quit: Leaving.]
sehraf has joined #linux-sunxi
_massi has joined #linux-sunxi
avsm has joined #linux-sunxi
enrico_ has joined #linux-sunxi
alexvf has joined #linux-sunxi
FDCX has quit [Ping timeout: 268 seconds]
Black_Horseman has joined #linux-sunxi
FDCX has joined #linux-sunxi
naobsd has joined #linux-sunxi
<arokux>
hi guys
<arokux>
what is happening in sunxi world in two words? :)
<Montjoie>
depends of the size of the word 32 or 64 ?
quitte has quit [Remote host closed the connection]
<arokux>
mm... better 64 :)
<Montjoie>
more entropy of choice, but for world conquest I wait for 128, all devs becoming mad (/lib /lib32 /lib64 /lib128)
<arokux>
Montjoie: oh, I meant not that detailed info :)
notmart has joined #linux-sunxi
cajg has quit [Quit: detetcive]
avsm has quit [Quit: Leaving.]
cajg has joined #linux-sunxi
Renard has quit [Remote host closed the connection]
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
naobsd has quit [Quit: Page closed]
Renard has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
morfoh_ has quit [Remote host closed the connection]
pwhalen has joined #linux-sunxi
popolon has joined #linux-sunxi
<wens>
ijc: why doesn't u-boot mainline have CONFIG_MACH_TYPE set?
arokux has quit [Remote host closed the connection]
PulkoMandy has joined #linux-sunxi
Quarx has joined #linux-sunxi
arokux has joined #linux-sunxi
<ijc>
wens: I don't think there's any specific reason, except that mainline kernels don't use it so noone noticed.
<wens>
so that's one of the things we need to add back for sunxi 3.4 to work?
<wens>
i'm merging sun6i support, so i could just keep that bit in
notmart has quit [Remote host closed the connection]
<ijc>
TBH I don't know what sunxi 3.4 requires, but that sounds very plausible.
notmart has joined #linux-sunxi
<wens>
i don't have any 3.4 setups atm
<ijc>
wens: Are you meaning to add upstream, or just add/retain as part of the merge into the github u-boot-sunxi tree? For mach_type I don't mind either way, but I'm not sure what else 3.4 expects of u-boot. FEX support at least I suppose...
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
rafaelMOD has quit [Quit: Leaving]
<philippe_fouquet>
I come back with my dificulties to communicate in fel mode in A20 cpu
<libv>
wens: so you have a columbus board?
notmart has quit [Ping timeout: 268 seconds]
<philippe_fouquet>
My USB signal are good (I check it with a scop)
<wens>
libv: i have the hummingbird
<wens>
for basic bringup purposes, they are the same
<libv>
wens: aw, too bad, i wanted to slap someone with ndh again :p
<wens>
libv: btw, those patches are for mainline
<libv>
yeah, i know
<libv>
i just noticed that it included columbus support, so i assumed someone who actually cared about users had a non-ndhed board :)
astr has joined #linux-sunxi
<wens>
hmm, so the chromebook people are going to add clock-always-on to the DT?
<libv>
wens: i haven't followed the discussion, i am pretty tired of that thread.
<philippe_fouquet>
I can read the version (fel ver) read ( fel dump or fel read) clear (fel clear) but i can't write (fel write) i have a usb_bulk_send error -99
VargaD_ has joined #linux-sunxi
<wens>
libv: it's the other thread, not the one with 100+ replies
<Turl>
philippe_fouquet: where are you trying to write? you can only do so to the sram most likely
<Turl>
wens: their problem was with regulators though
<wens>
Turl: yeah, but that's because they're using clk_ignore_unused
Gerwin_J has joined #linux-sunxi
VargaD has quit [Ping timeout: 245 seconds]
VargaD_ is now known as VargaD
<wens>
i suppose we could get u-boot to magically add that to the bootargs for simplefb :|
<philippe_fouquet>
i try the tuto in linux-sunix.org/FEL/USBBoot ("fel write 0x2000 ./u-boot-spl.bin")
<ssvb>
wens: we don't have enough data yet to decide what would be the best DRAM configuration
<wens>
don't quite understand what mbus is... a buffer between the system and dram?
<ssvb>
wens: well, nobody knows for sure (we only have scarce comments)
<ssvb>
wens: but MBUS is likely the clock speed of the DRAM controller itself, and DRAM is the clock speed of the PHY
<jemk>
rellla: good question ;) im not sure how this video ioctls work and if it is correct, but it worked. I think i basically copied it from willswangs libcedarx.
prahal has joined #linux-sunxi
<ssvb>
wens: the DRAM controller is handling requests from 32 host ports, it is able to prioritize and reorder them for better performance, etc.
<ssvb>
wens: so yes, it is surely doing some buffering
<rellla>
jemk: just wondered about it, because it seems pretty useless for me at that line :p
<jemk>
rellla: just to make sure you noticed, its a static variable, it keeps its value
<ssvb>
wens: if we want to do dram reclocking, then dram needs to be temporarily put into self-refresh mode
<ssvb>
wens: if dram is in the self-refresh mode, then the whole SoC can be even powered down
<ssvb>
wens: so basically we are free to re-initialize the dram controller in any way we like, and retain the old data
<ssvb>
wens: but of course, we need to clearly know what we are doing and perform all the steps in the correct order (flushing all the queues, etc.)
<ssvb>
wens: that's where the actual documentation might be very handy
<ssvb>
wens: because the existing code from Allwinner is full of magic constants and is rather scary :-(
<ijc>
wens: Thanks for that A31 series. Are you intending it to be for v2014.10? If so then it has missed the merge window and we are now post -rc2 (-rc3 must be happening soon) so someone would need to make an (pretty compelling) argument for why it must go in now.
<ijc>
Alternatively if you are happy for it to hit v2015.04 we can target that instead.
<ijc>
My default position at this stage would be to target v2015.04, but if you want it to land sooner please make a case (on the uboot list please).
<ssvb>
wens: it's not huge (we can copy/paste the bits of pm code from the Allwinner kernels), but rather risky
<ssvb>
wens: still right now u-boot configures pll6 and pll5 and the dram controller kinda "owns" them
<ssvb>
wens: if the kernel tries to manage them too, then everything may get out of control
<ssvb>
ijc: sun6i support is clearly too late for v2014.10, nobody is going to bend the rules
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<ijc>
ssvb: Agreed, I certainly wasn't going to be making that argument myself.
<Turl>
ssvb: right now sata also uses pll6
<Turl>
and iirc cedar and mali also feed off of it so it may not be the wisest thing to blindly clock mbus off of
<ssvb>
Turl: the current assumption is that pll6 stays at 600MHz, right?
<Turl>
I think so
<ssvb>
Turl: iirc, cedar and mali use pll4
<Turl>
the sata output is 1.2GHz iirc and the other one is 600MHz
xavia has joined #linux-sunxi
<Turl>
hm may be pll4 then
zeRez has joined #linux-sunxi
<ssvb>
Turl: MBUS also uses 1.2GHz (that's how we can get 400MHz for MBUS) on sun7i, but is only restricted to 600MHz on sun5i
<Turl>
sun5i doesn't have sata though
<ssvb>
Turl: yes, and the sunxi-3.4 kernel configures PLL6 to something much lower than 600MHz
<wens>
ijc: no 2015.04 is fine
<ssvb>
Turl: which may affect dram performance, in the case if the dram controller is clocking mbus from pll6
<ssvb>
Turl: do we normally reduce pll clock speeds to optimize power consumption?
<ijc>
wens: Ack
<wens>
ijc: since no one was working on it, i thought i'd get things started
<Turl>
ssvb: checking 3.4 quickly, pll6 is also potentially used for usb and other stuffs
<Turl>
ssvb: no, we shut them off :)
<wens>
yeah, some part of the docs mentions usb 24M being clocked from pll6
<wens>
in the clock diagrams i think
<ssvb>
wens: isn't it the other way around?
<wens>
ssvb: "USB 24M", not the 24M osc
<Turl>
bbl
<ijc>
wens: Ack, thanks for doing so!
<wens>
can't find it :|
<wens>
hmm, a10 manual lists pll6 as "fixed to 1.2 GHz"
konradoo77 has joined #linux-sunxi
<wens>
ssvb: ok, i probably mixed things up
Andy-D has joined #linux-sunxi
<ssvb>
Turl: the 3.4 kernel has some rather nasty hardcoded divisors, and also some nasty defines like '#define MMC_SRCCLK_PLL6 "sdram_pll_p"'
<ssvb>
Turl: so that the PLL6 identifier in the code sometimes actually means PLL5
<ssvb>
Turl: a funny grep exercise to find all this junk...
<ssvb>
Turl: almost like the classic '#define TRUE FALSE' :)
<ricardocrudo>
ssvb: arm-none-eabi-gcc --version = 4.8.3, from debian testing repo
bengal has joined #linux-sunxi
<ssvb>
ricardocrudo: it's hard to say what's wrong, supposedly everything should work fine
<ssvb>
ricardocrudo: except that Iteaduino_Plus_A20 is not a very popular board around here and I'm not sure if it is really well supported
prahal has quit [Quit: prahal]
bonbons has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
<astr>
sorry buts whats the git command to download the revision tree (is that what it's called?) of just the latest version of sunxi uboot for olimex lime-a10?
<ricardocrudo>
ssvb: I see. And how about "spl: not an uImage at 1600" do you know what this means?
<astr>
diego71, arr good but then again... theres a bug when I first plug the power cable in the board boots but fails due to bad kernel image checksum, i think(?) then I press the power on button for a few secs the board does a forced powers off then I press the power button again and it boots successfully is this a bug fixed in a newer uboot?
bengal has quit [Quit: Leaving]
<diego71>
ssvb: mainline u-boot should support changing mbus clock, right? But it looks like not: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/dram_sun7i_384_1024_iow16.c;h=04e4b1e9b99d5a65ff3009f0b07fe9cb6ff789dd;hb=HEAD
<diego71>
astr: it's possible. But I never had this kind of problem
<ssvb>
diego71: if you don't explicitly initialize some parameter in the 'dram_para' struct, it gets assigned a default 0 value (which is interpreted as 300 for mbus_clock)
<diego71>
ssbv: ok, now I understand
<diego71>
ssbv: i'm going to do some test also on a a13-olinuxino, using mainline u-boot
<ssvb>
diego71: the mainline u-boot is not going to work well out of the box, I'm still preparing the patches for a proper sunxi-3.4 support
<ssvb>
diego71: a13-olinuxino? or a13-olinuxino-micro?
<ssvb>
diego71: also the default environment is different in the mainline u-boot
bertrik has quit [Remote host closed the connection]
<ssvb>
diego71: how is the emr1 test progressing on a20?
<diego71>
ssvb: I tested with 0x44 and I didn't see much difference from 0x4
<diego71>
ssvb: now I'm testing 0x40
<ssvb>
diego71: ok
<ssvb>
diego71: I forgot to mention that you don't need to wait for completion of the additional 'hardening' tests, which try to run 100 rounds of memtester for each config
<ssvb>
diego71: this only makes sense for testing the 'final' configuration
<diego71>
ssvb: thanks, i've already found out during the previus tests...
<ssvb>
diego71: yeah, it's kind of intuitive, but sorry for not explicitly mentioning this earlier
astr has quit [Ping timeout: 272 seconds]
<ssvb>
diego71: can you still upload the emr1=0x44 results?
<diego71>
ssvb: of course
<ssvb>
diego71: thanks, it's just interesting if it is maybe slightly better or slightly worse
rnp has left #linux-sunxi [#linux-sunxi]
xavia has quit [Remote host closed the connection]
<diego71>
ssvb: done, i pasted also 0x40 case
<diego71>
It looks slightly worse
<ssvb>
diego71: yes, indeed
<ssvb>
diego71: and it looks like 0x40 is also going to be worse than 0x4 when it runs to completion
<diego71>
ssvb: and I expect 0x0 to be even worse ...
<diego71>
ssvb: I wonder if it's better start to play with zq, leaving emr1=0x4
Renard has joined #linux-sunxi
<diego71>
ssvb: about uboot mainline and A13, it looks like the second commit it's not needed for A13 (sun5i)
<ssvb>
diego71: do you have the machine id already defined in your u-boot environment?
<ssvb>
diego71: or maybe it does not actually do a strict check for the machine id if u-boot does not define one
astr has joined #linux-sunxi
pwhalen has quit [Ping timeout: 255 seconds]
<diego71>
ssvb: I don't know
<ssvb>
diego71: about emr1=0x4, it looks like Olimex people have selected the 330 ohm resistor for a reason, essentially doing impedance configuration in a hardware way instead of configuring it in software :)
<diego71>
I've to look better, but I think that I'm going to sleep now
<ssvb>
diego71: but nevertheless, it's good to confirm that emr1=0x4 is already the best value
<ssvb>
ok, good night
<diego71>
ssvb: it's possible, expecialy if they had changed the impedence
<diego71>
thanks
pwhalen has joined #linux-sunxi
apo_ has quit [Ping timeout: 240 seconds]
rafaelMOD has quit [Quit: Leaving]
Andy-D has quit [Ping timeout: 240 seconds]
fedya|2 has joined #linux-sunxi
lerc has quit [Ping timeout: 245 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
Renard has quit [Quit: Renard]
avsm1 has quit [Quit: Leaving.]
lerc has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]