<naobsd>
can anyone merge s/EMAC/GMAC/ patch for linux-sunxi u-boot for A20 lime?
nicksydney has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 260 seconds]
lerc has quit [Read error: Connection reset by peer]
FreezingCold has joined #linux-sunxi
lerc has joined #linux-sunxi
<wens>
libv: looks like a80 basic dram code is actually in brom
<wens>
or i'm dumping the wrong address
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
Lorenzo64 has quit [Ping timeout: 245 seconds]
Nyuutwo has quit [Ping timeout: 260 seconds]
Nyuutwo has joined #linux-sunxi
amitk has joined #linux-sunxi
pwhalen has quit [Ping timeout: 255 seconds]
pwhalen has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 245 seconds]
ddc has joined #linux-sunxi
<ddc>
wens: Hi
FreezingCold has joined #linux-sunxi
<wens>
ddc: hi
xavia has joined #linux-sunxi
<ddc>
wens: I'm asking about utilizing Device Tree Control in the sunxi U-Boot
<wens>
huh? device tree control?
* wens
has no clue
<ddc>
wens:/doc/README.fdt-control
<ddc>
wens: I've brought this subject a few days ago. and I had unpleasant answer from libv
Akagi201 has quit []
<ddc>
wens:I'm trying to port bbrezillon mtd nand driver to u-boot, I found that using dts will make the porting a bit easier. rather than using lots of #define CONFIG_
<ddc>
wens: I don't want to introduce such a thing without consulting the community about
<libv>
hrm, integfred expects others to review his code and spot his error, without using a uart?
<libv>
nedko: as said, email, let those with a bit more knowledge about this specific topic discuss this out.
<libv>
Turl: what would the world do without us :)
<libv>
wens: i am going to rework my meminfo test code now, and send the patches in, and place a binary on my dl.ls.o so people can start throwing out some results
skoperst has quit [Ping timeout: 246 seconds]
FreezingCold has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 245 seconds]
ssvb has quit [Remote host closed the connection]
Nyuutwo has quit [Remote host closed the connection]
Nyuutwo has joined #linux-sunxi
<wens>
libv: ok
<wens>
libv: had no luck getting my a80 to boot with a custom image
<wens>
s/custom image/custom sd card/
<wens>
and phoenix card refuses to write my packed image...
<libv>
wens: keep at it :)
<libv>
wens: you'll find a way
deasy has joined #linux-sunxi
<wens>
yeah, i'll probably try to hack the uboot in the emmc, if i can
<t3ngu>
ls
<t3ngu>
oops
<wens>
i still need to produce a slightly ugly ahb1 clk driver for a31/a23
FreezingCold has joined #linux-sunxi
<libv>
wens: i really need to get to tom tisdalls nand problem soon, but i feel that we really should spend some time on getting the other SoCs going with the SDKs. i will be happy to work on the a23 for that, as i do not have the other hw atm
FreezingCold has quit [Ping timeout: 252 seconds]
alexvf has joined #linux-sunxi
avsm has joined #linux-sunxi
<libv>
mripard_: this simplefb clocks thing seems to have no end :(
<libv>
as you've clearly seen, my heart is not attached to simplefb or this code
avsm has quit [Quit: Leaving.]
<libv>
i am amazed about this story, seems like the clock naming thing is just one of many corners in dt, and that many things have not been thought through with it
yann_s has quit [Ping timeout: 240 seconds]
jelly-home has quit [Ping timeout: 245 seconds]
jelly-home has joined #linux-sunxi
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
bengal has joined #linux-sunxi
hipboi_ has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<cubear>
Is there a document that describes how to use interrupt-driven GPIO on A10/A20?
<mnemoc>
search for eint
hipboi_ has joined #linux-sunxi
arend has quit [Remote host closed the connection]
kz1 has joined #linux-sunxi
bengal has quit [Ping timeout: 272 seconds]
FDCX has quit [Ping timeout: 268 seconds]
jinzo has joined #linux-sunxi
<hramrach>
hehe, clock story
<hramrach>
I guess opensource has its downsides, too
<hramrach>
like i have to maintain my local fork of gvncviewer for it to not grab keyboard and mouse on every occasion because the maintainer is asinine about accepting patches for that :/
<wens>
cubear: you can only use it from kernel space i think
hipboi_ has quit [Ping timeout: 245 seconds]
<libv>
hramrach: i am not sure it is a downside
<libv>
this does not feel like your usual bikeshed
<mnemoc>
wens: iirc the gpiolib driver in 3.4 was exposing the eint functionality to userspace
<libv>
to me, it just shouts out that dt is not as thought out as it should be
<libv>
hramrach: i will push your patches in an hour or so
<libv>
then we will at least put 1 more device to rest
<wens>
mnemoc: huh? then how does it trigger? blocking read?
<mnemoc>
i suppose so
<mnemoc>
it was part of the standard gpiolib iirc
<mnemoc>
and as a blocking read would be compatible with epoll
naobsd_ has quit [Quit: Page closed]
hipboi_ has joined #linux-sunxi
<hramrach>
libv: it's the story about "I send you patch that solves this problem" "I do not have this problem. Go away."
<libv>
hramrach: that's just one part of it
Black_Horseman has quit [Remote host closed the connection]
<libv>
hramrach: another part of it is that these two nvidia guys (and i know thierry) didn't think simplefb through, not for rpi and not for the short lived tegra intermediate solution
<libv>
and now, as usual, i come along, and show that they didn't think things through
ssvb has joined #linux-sunxi
<libv>
which explains why exactly these two persons are against it
* libv
has always run into such things his whole carreer
<hramrach>
the major part afaict. There must be a balance between feature creep and accepting patches for problems that only occur on some systems/configurations
<hramrach>
and when the maintainer just refuses to see that his use case is limited he says go away
<libv>
hramrach: they do not want to admit that they did not think simplefb through
<libv>
but, there is an actual problem there that needs solving
<libv>
and just specifying clocks is not going to make all problems go away
<libv>
people just never had a proper discussion about how to deal with volatile bootloader provided resources
<hramrach>
it seems that at later stages of the thread when there was enough technical argument stated and restated excuses were given why this would be bad
FDCX has joined #linux-sunxi
<hramrach>
without any actual substance
<libv>
once i have worked off my todo list a bit more
<libv>
i will provide an offb where resource handling can be added
<hramrach>
I can see that on systems with a LCD you could specify a backlight regulator which the simplefb code could actually use
<libv>
it will be nothing more than simplefb with clock handling
<libv>
and other bits should get bolted onto that
<hramrach>
I do not know offb but presumably you can bolt the DT support on that too
<hramrach>
if it does not have some already
<hramrach>
simplefb already reads DT as is
<libv>
heh, offb is wrong too
<libv>
it has a massive amount of avivo (radeon r500 display engine) specific code
shineworld has left #linux-sunxi ["Leaving"]
souther has quit [Ping timeout: 240 seconds]
<libv>
palette handling and other idiocy
<libv>
which definitely is not something you should deal with with a volatile bootloader provided resource
alexvf has quit [Ping timeout: 246 seconds]
<cubear>
mnemoc: where should I look for the code? gpio-sunxi kernel module?
<libv>
i guess i will take the first few commits in my sunxi_kms code and add some dt handling there
<mnemoc>
cubear: and the gpiolib documentation
<cubear>
wow looks like a lot of code to study
rz2k has quit []
<cubear>
alright, thanks for the info
<mnemoc>
in the 3.4 code there is a table defining the eints of each SoC. i don't know if that knowledge is already included in the DTs of mainline
<cubear>
so I better stick to 3.4 rather than mainline
<mnemoc>
or start by looking at 3.4's implementation and then contributing the needed changes to mainline ;-)
<mripard_>
it works in mainline
<mnemoc>
mripard_: eint?
<mripard_>
ye
<mripard_>
*yp
<mripard_>
**yep
<mnemoc>
cool :)
<mnemoc>
cubear: ----^ so you can use mainline :)
<cubear>
nice
<cubear>
^.^
Gerwin_J has joined #linux-sunxi
<wens>
in mainline you just specify which eint you want to use using interrupts binding, or gpio bindings then calling gpio_to_irq
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<mripard_>
wens: or sysfs ;)
<cubear>
isn't sysfs GPIO like slow as hell?
<mnemoc>
is hell slow?
<cubear>
I've seen some benchmarks, but that was ages ago, so I don't know, if it has improved any
<cubear>
mnemoc: depends. mmap is supposed to be faster
<hramrach>
benchmarks of hell ;-)
<mnemoc>
cubear: obviusly no abstraction can be compared to direct manipulation of the register, but playing with /dev/mem is.... risky
<wens>
mripard_: can sysfs do eint?
<hramrach>
I would not expect going through sysfs handler is the fastest thing ever
<mripard_>
cubear: how do you get an interrupt through mmap?
<cubear>
mnemoc: I understand. I was just worried because some people complained that sysfs takes unusually long to respond. I think it was about the output GIPO where there needed to be a context switch that took several milliseconds to complete before the output could be changed
<mripard_>
wens: yep, you'll have a blocking read, until you get an interrupt
<cubear>
mripard_: you don't, I was talking about normal GPIO
<mripard_>
cubear: and that means writing a new driver all over again, in user space, running in root
<hramrach>
but what is your speed requirement?
<mripard_>
not really a good idea, or the usual way of doing things.
<hramrach>
sysfs is nice for prototyping, too
avsm has joined #linux-sunxi
avsm has quit [Client Quit]
<cubear>
bleh
<cubear>
I can't find that forum post about speeds/benchmarks
<mripard_>
cubear: anyway, mmap or not, it's "fast", "gpio" and "userspace", pick two.
<cubear>
how much speed do I need for a rotary encoder?
<mripard_>
I don't know.
<mripard_>
is the usualy gpio driver for this too slow?
<cubear>
I haven't tried it yet, just recently received my rotary encoder from ebay. I was hoping to use interrupts to avoid polling. Will need to do some tests then.
<hramrach>
and do you get the raw lines or some cooked data already
<cubear>
raw lines
<cubear>
2 outputs
<cubear>
1 or 0
<mripard_>
cubear: the driver supports interrupts.
<cubear>
is there an existing rotary encoder driver for sunxi so that I don't reinvent the wheel?
<hramrach>
it's not sunxi specific
<hramrach>
there is probably already kernel driver
<cubear>
well then I've got most of the work done already
<cubear>
and that file is in the mainline as well
naobsd has joined #linux-sunxi
cubear has quit [Quit: Leaving]
<wens>
Turl: i'm thinking about the pll6 pre-div for ahb1 on a31
<wens>
if i add a clk div for it, i risk breaking the sun6i dma driver, as pll6 is no longer a direct parent of ahb1
alexvf has quit [Ping timeout: 246 seconds]
balog1 has joined #linux-sunxi
balog has quit [Ping timeout: 260 seconds]
ricardocrudo has joined #linux-sunxi
Net147 has joined #linux-sunxi
<rellla>
jemk: what was the issue/ bad thing with XClearWindow? i can remember we talked about that already ...
<rellla>
btw, saw you implemented MBAFF...
balog1 has quit [Ping timeout: 255 seconds]
<mripard_>
wens: a separate pre-divider clock would be the simplest I guess.
<mripard_>
I'm not really fond of it, since I'd prefer to have one clock per hardware clock
naobsd has quit [Quit: Page closed]
<mripard_>
but if it's much much harder...
<mripard_>
and don't worry about the A31 dma driver
<mripard_>
we need to convert it to the new DT parents assigned stuff anyway
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<wens>
for assigned parents, the pre-div clk would have to be in the DT as well
<mripard_>
well, or it would be assigned to pll6 directly
amitk has quit [Ping timeout: 260 seconds]
<wens>
i'll try to write a custom composite clk for it
<mripard_>
you don't need to write one like I was saying
<mripard_>
in the round_rate/determine_rate function, you can just take into account wether you can use the pre divider or not
amitk has joined #linux-sunxi
<wens>
yeah, i meant using that
<wens>
extending clk-factors is possible, but it's getting a bit feature bloat imho
<mripard_>
I agree.
<wens>
i'm unifying ahb1 and ahb1_mux as well, so that's why i'm going with a composite clk
<mripard_>
that's very much welcome :)
<wens>
and a basic mux doesn't do set_rate, so... either way it's custom tailored stuff
<wens>
we can generalize it later if we have other uses
mmarker has joined #linux-sunxi
Seppoz has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 268 seconds]
souther has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
Net147 has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet]
traeak1 has left #linux-sunxi [#linux-sunxi]
Zboonet has quit [Remote host closed the connection]
Zboonet has joined #linux-sunxi
pwhalen has quit [Ping timeout: 245 seconds]
zeRez has joined #linux-sunxi
lkcl has joined #linux-sunxi
<wens>
oh we got a reply from shuge
<mnemoc>
it's nice there is intention to solve the problems and help with the drivers which IP doesn't belong to them
Nyuutwo has quit [Ping timeout: 246 seconds]
zeRez has quit [Ping timeout: 240 seconds]
pwhalen has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
skaag1 has quit [Ping timeout: 260 seconds]
<jemk>
rellla: the bad thing with XClearWindow is that it always fills the whole window (needs much memory bandwidth), even if the window is already cleared.
<jemk>
rellla: we should wait for expose events and only clear then, or even rely on the fact that the window should be auto cleared at expose events
skaag has joined #linux-sunxi
skaag has quit [Ping timeout: 272 seconds]
xavia has joined #linux-sunxi
skaag has joined #linux-sunxi
<wens>
mripard_: is hans' interpretation of the GPL off? doesn't sound quite right...
nedko has left #linux-sunxi [#linux-sunxi]
<libv>
wens: what, where?
<libv>
i hope my latest email clears things up for everyone involved.
<mripard_>
or at least, that wasn't my understanding at all.
<wens>
libv: mail thread on linux-arm-kernel
<libv>
is this about giving bsds a chance as well?
<wens>
maybe
t3ngu has quit [Quit: Leaving.]
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
<ssvb>
wens: ianal, but but to me it looks like hans is right
<libv>
avoid all discussion, and relicense the dtsi first
<ssvb>
wens: you can freely mix BSD with GPL code, but the combined result is GPL as long as even a single part of it is GPL
<libv>
ssvb: i think hans is arguing that the dts file which includes the gpled dtsi has to be licensed GPL as well
<libv>
i think everyone agrees that the end result is gpl
<libv>
just the ordering is important
<libv>
so just cut the discussion short and relicense the dtsi first
<mripard_>
and he was saying exactly the opposite.
<ssvb>
libv: that's what mripard_ is saying, not hans :)
<ssvb>
libv: and I think that mripard_ is mistaken on this matter
<libv>
it's contentious, there's a way to avoid contention, take it
<libv>
it's not as if half the planet wrote those dtsis
afaerber has joined #linux-sunxi
<wens>
hmm...
<libv>
it just is an ordering thing
<libv>
who cares?
hipboi_ has quit [Ping timeout: 260 seconds]
hipboi_ has joined #linux-sunxi
<wens>
i think hans is arguing the dts is not a derivative work of the dtsi
<wens>
ssvb: if it were derivative work, could you still legally license it under a looser license? (BSD/MIT)
<wens>
not that it makes much sense
<ssvb>
wens: if the dts is not copy-pasting parts of dtsi, then it is not a derivative work
<ssvb>
wens: if you are developing an application, then you don't strictly need to pick exactly the same license is the libraries it depends on and header files it includes
<ssvb>
wens: it merely needs to be compatible
<ssvb>
wens: the final binary has a single license though, and that's where the most restrictive license takes effect
<mripard_>
ssvb: replace DTSI by "GPL Library" and BSD by proprietary, and look how it works for you
<ssvb>
mripard_: read my last line, that's how it works
<sehraf>
i want to access gpio pins on a cubietruck through /sys/class/gpio/export ... how do i translate the pin name (like PH18) to the corresponding number? can i use the formula from drivers/pinctrl/sunxi/pinctrl-sunxi.h (e.g. PH_BASE + 18)?
Nyuutwo has joined #linux-sunxi
bonbons has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
<wens>
sehraf: right
<wens>
or if you have debugfs, you could look at /sys/kernel/debug/pinctrl/1c20800.pinctrl/pins
<sehraf>
wens: thx
Uninstall has quit [Quit: No Ping reply in 180 seconds.]
amitk has quit [Quit: leaving]
Uninstall has joined #linux-sunxi
Uninstall has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
bengal has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 245 seconds]
ssvb has quit [Ping timeout: 245 seconds]
ssvb has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
nove has joined #linux-sunxi
akaizen has joined #linux-sunxi
rafaelMOD has joined #linux-sunxi
akaizen has quit [Client Quit]
akaizen has joined #linux-sunxi
<afaerber>
wens, hi. I saw you've created a Wiki page for the Optimus Board - did you get any sources from Merrii?
<rafaelMOD>
Guys, we are having a hard time trying to make an ITEAD A20 coreboard work in our audiophile base board. We have tried all patches, images and possible ways to load firmware to NAND and SDCard with no success. We read all the possible documentation and nothing! Can anyone look into our boot log for NAND and SDCARD? We are using a cubian official image for the SDCard and a LiveSuit image made with "https://github.com/cubieboard2/manifests".
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
akaizen has quit [Read error: No route to host]
akaizen has joined #linux-sunxi
<libv>
afaerber: check the A80 page
<libv>
afaerber: wens is working on it, but so far hasn't succeeded in getting an sd-card going
<libv>
we urgently need that worked out
<libv>
and documented
<afaerber>
libv, I saw the A80 page with the violations listed
<afaerber>
libv, so are you saying that the Allwinner SDK (that is described on A80 page) is identical to what Merrii uses? I would've expected something on top
<libv>
afaerber: merrii has not given anything to us
<libv>
if you want that, go bang on merriis door
<libv>
as always, we should consider ourselves lucky with what we got
<afaerber>
I see
<libv>
did you expect anything different?
<afaerber>
of course I expect either a tarball or some git repository ;)
<libv>
and samsung is investing a lot of money there already
<libv>
and perhaps imx6 is better
<afaerber>
libv, Qualcomm (InForce), Vybrid, ...
<afaerber>
(not saying that all of them were great, obviously, but at least something)
<libv>
afaerber: for an SoC meant for mobile which is barely shipping?
<libv>
anyway, i am sorry that we could not rise up to your high expectations
<libv>
we at linux-sunxi will try to do better next time.
<afaerber>
libv, I usually get only those barely shipping although not all mobile. usually the seller's support site has something to download
<afaerber>
libv, how has that got anything to do with linux-sunxi? it's not your fault if Merrii only puts some Hummingbird SDK up for download
<libv>
well, i did tell you to go bang on merriis door before.
<afaerber>
yep, and I will
<afaerber>
bbl
lkcl has quit [Ping timeout: 264 seconds]
FR^2 has quit [Quit: Connection reset by peer]
afaerber has quit [Quit: Verlassend]
<libv>
i am going to push the current changes to meminfo
<libv>
since noone cares to give a go-ahead, i am going to assume that everyone is just ok
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
Andy-D has joined #linux-sunxi
lkcl has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
jinzo has quit [Read error: Connection reset by peer]
mmarker has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
dack has joined #linux-sunxi
akaizen has joined #linux-sunxi
buZz has quit [Ping timeout: 240 seconds]
buZz has joined #linux-sunxi
buZz is now known as Guest89285
physis has joined #linux-sunxi
amitk has joined #linux-sunxi
<oliv3r>
ello
<oliv3r>
libv: i gave you my ok here :p
<libv>
oh, then i forgot to add your ok to the commits :)
<libv>
oliv3r: thanks though :)
akaizen has quit [Remote host closed the connection]
<oliv3r>
rafaelMOD: since you are using cubian, I guess you use a cubieboard, did you try #cubieboard or #cubietech?
akaizen has joined #linux-sunxi
skaag has quit [Read error: Connection reset by peer]
skaag1 has joined #linux-sunxi
skaag1 is now known as Skaag
FR^2 has joined #linux-sunxi
akaizen has quit [Ping timeout: 272 seconds]
lkcl has quit [Ping timeout: 260 seconds]
<rafaelMOD>
oliv3r: I am using ITEAD A20 coreboard, it has the same DDR3 and NAND ics of cubieboard2, so I am starting with cubie files. I also posted on #cubie*, but no answer. I am allmost getting it to load the kernel with NAND boot. Could you please check the NAND boot log on pastebin (http://pastebin.com/WtS2Au2A)?
<oliv3r>
rafaelMOD: you are booting allwinners bootloader, so get in touch with them to help you with that
<oliv3r>
rafaelMOD: as for u-boot, your uEnv seems to be wrong
<oliv3r>
rafaelMOD: try the sunxi fedora 20 image
konradoo77 has joined #linux-sunxi
<rafaelMOD>
libv: Sorry but I am not using the baseboard from ITEAD, the ITEADuino. I developed a baseboard for a soundprocessor with an audiophile sound card, from scratch. And I am using the ITEAD as coreboard processor, as it has the I2S pins available.
<rafaelMOD>
And I dont have an ITEADuino.
<libv>
rafaelMOD: perhaps we should split this page
<libv>
into 3 different pages
<rafaelMOD>
oliv3r: Thanks, I will try. I will also try different uboot versions from allwinner.
<libv>
rafaelMOD: the uart picture is baseboard specific, no?
<Skaag>
that's a pretty damn interesting board!! What does it do? Audio processing?
<rafaelMOD>
Live time audio processing runin open standard LV2 for audio plugins.
<Skaag>
amazing
physis has quit []
<rafaelMOD>
oliv3r: I have a big problem, in this prototype i was hopping to load the images through LiveSuit, so i made the serious mistake of not putting an sdcard slot. I am building my images for LiveSuit following https://github.com/cubieboard2/manifests. And I have not found the uEnv.txt yet!
<rafaelMOD>
Seems like the sd wireup is not working, even with eletrical continuity checked.
<rafaelMOD>
libv: Yes, The uart picture is baseboard specific, but i can make a picture of the UART pins on the A20 Coreboard
<rafaelMOD>
But it would need some wireup, as the connector is 1mm pitched! Awfull
<CaptHindsight>
\0/ SATA works again on cubie2
<oliv3r>
rafaelMOD: livesuit is an allwinner thing, so technically, barking up very much the wrong tree
<CaptHindsight>
now for RT over ethernet
<libv>
rafaelMOD: ah, the uart is part of the main connectors
<libv>
hrm :(
<oliv3r>
rafaelMOD: your SD card slot seems to eb working fine
<oliv3r>
rafaelMOD: you are loading up u-boot SPL and u-boot (for cubieboard2) which indicates that both bootloaders successfully loaded from the SD card
<oliv3r>
rafaelMOD: your issue seems to be purely software, for which a little reading effort on the wiki should fix things for you
<oliv3r>
rafaelMOD: you probably are missing ont he SD card, a fat partition on in the MBR (don't think we support GPT)
<oliv3r>
rafaelMOD: on the fat partition, uEnv.txt, script.bin, uImage, boot.scr
<oliv3r>
rafaelMOD: the pretty standard shazam
<rafaelMOD>
oliv3r: Thanks! I was wandering if the sdcard wireup was not working! I will read all again with calm.
<oliv3r>
rafaelMOD: anyhow, the moment you speak of livesuit, you curse yourself to be helped by allwinner :)
<oliv3r>
rafaelMOD: atleast you managed to write the bootloader(s) to the SD card properly :)
<oliv3r>
i'm sure those guys know what they are talking about most of the time :)
<rafaelMOD>
I am totally leaving the livesuit tool. Is a joke the combination of buttons pushing to start uploading the code. We couldnt get a deterministic way!
<oliv3r>
rafaelMOD: well you don't need a fat partition actually, ext* works just as well for u-boot :)
<oliv3r>
rafaelMOD: i'm going to be doing a similar thing
<oliv3r>
but we will be using the SD card to flash the nand :)
<rafaelMOD>
oliv3r: I thought that in production it would be easier to upload the code through USB. My mistake.
<rafaelMOD>
oliv3r: Do you think the best solution, like for 1000 units, is still the sdcard, then NAND aproach?
<oliv3r>
best software support (for now) is still SD imo
<oliv3r>
but we also need it ot be on nand, sd card is unprofessional :)
<oliv3r>
to flash? I think SD card will be much more efficient
<oliv3r>
if 1 engineer does the work, and your image is 250MB for example
<oliv3r>
get 20 sd cards (+ 10 'spares') all preloaded with the proper software (e.g. boot, then 'flash an image')
<oliv3r>
production employee inserts SD card in board 1, connects it and boots it
<oliv3r>
and then moves to next board, when he reaches board 20
<oliv3r>
board 1 should be finsihed
<oliv3r>
so he can then swap 1 out for 21
<oliv3r>
when that is done, move to swap 2 for 22
<oliv3r>
etc
<oliv3r>
with USB
<oliv3r>
heh
lkcl has joined #linux-sunxi
<oliv3r>
either get 20 USB ports and hope you can get the software to work
<oliv3r>
or get 20 pc's to work livesuit 20 times
<rafaelMOD>
Not saying the button pushing joke that is needed to enter the flashing mode with livesuit
<oliv3r>
either doesn't sound very appealign to me
<oliv3r>
and that
<oliv3r>
SD card boot works 99.99% of the time
<oliv3r>
the 0.01% is either wrongly created SD card, using unsupported SD card, or broken SD card
<rafaelMOD>
You are right man, SDcard is way faster. The only problem is the extra cost of the sdcard slot. It will cost me some audio capacitors, as i am in the budget limit! I will probably put it on external connector and develop small sdcard boards for flashing.
<oliv3r>
you just answered your own thing
<rafaelMOD>
:)
<oliv3r>
you could have made the board with a row of pins
<oliv3r>
have a breakout board for the SDcard
<rafaelMOD>
That I regreat!
<rafaelMOD>
Wiring up with 1mm pitch was a pain!
<oliv3r>
it would also mean less trouble with the ejecting mechanism that can fail (on big production runs)
<rafaelMOD>
But you confirmed that worked, thanks a lot.
<oliv3r>
now you have to wire up 1000 1mm cables :)
<oliv3r>
so yeah, don't remove the audio capacitors ;)
<oliv3r>
have a breakout board with uSD + UART0
<rafaelMOD>
No!! Its just the first release candidate. I have some toom for more prototypes!
<oliv3r>
you can have a 'programming and monitoring' station
<rafaelMOD>
And by the way. I am thinking in migrating from ITEAD A20 to the new MarsBoard A20.
<oliv3r>
so the cables for the UART are permanently connected to a terminal, sd card is permanently inserted
<oliv3r>
just swap breakout board after each program
<rafaelMOD>
I'll go from 1mm pitched to 1.27mm.
<oliv3r>
you can have 1 system with 20 /dev/ttyUSB's to monitor the serial ports easily :)
<oliv3r>
additionally
<rafaelMOD>
:)
<oliv3r>
you can make test 'points' rather then headers, and use a bed of nails to get to the contacts
<oliv3r>
much quicker and more reliable to connect
<rafaelMOD>
I will surelly develop a jig for that.
<oliv3r>
you probably have a jig to test the board anyway, no?
<oliv3r>
so adding the flashing pins for the sd interface is easy
<rafaelMOD>
No I dont! I am the jig man.
<rafaelMOD>
And I use the prototype word olny in the singular, one for each version. Its a kickstarter campaing with no money! Only hard work.
<oliv3r>
you do know there has been an audiofile 'board' for the cubieboard?
<rafaelMOD>
I already developed an A23 board. It is still in the schematic. It will be called Bubaboard. If we reach a strech goal on our campaing then I will develop it.
akaizen has joined #linux-sunxi
<rafaelMOD>
I know there is. But it uses a strange spdif conversion scheme, as the cubie doesnt have the I2S pins exposed.
<oliv3r>
ah
<oliv3r>
well the board was way way to expensive
<rafaelMOD>
And this board is for a pedalboard so musicians can use it on stage. We are bringing the LV2 audio processing plugins to the stage.
<oliv3r>
you should have used an olimex lime and put a shield on that :)
<rafaelMOD>
What i really want is to have an A33 on it!
<oliv3r>
we'll happily put them on dl.linux-sunxi.org
<rafaelMOD>
Even the reference board schematic
<rafaelMOD>
If it was my choice... i will put some pressure my CEO here.
<CaptHindsight>
rafaelMOD: do they have docs for all the registers for all the peripherals?
<rafaelMOD>
No, the datasheet an user manual is the same.
<CaptHindsight>
heh
<rafaelMOD>
How about an enterprise that breaks all those GPL and that forces you to sign an NDA to get the very needed docs for designing. I think thats becouse we are a small brazilian company.
<oliv3r>
ah brazil
<oliv3r>
you can just leak it, they won't do shit :p
konradoo77 has quit [Ping timeout: 268 seconds]
<CaptHindsight>
they will be angry and write you a letter telling you how angry they are, then not deal with you again unless you bring $$$$
<rafaelMOD>
I will do different. I will pass them to KiCad project and then set them free.
<oliv3r>
you work with KiCad?
<oliv3r>
i started with KiCad sunday :), i thought it would be super advanced compared to gEDA
<oliv3r>
i noticed that it's about the same
<oliv3r>
gEDA seems to be far more logical with their schematic UI
<rafaelMOD>
I dont know gEDA, but i am doing proffessional stuff with kicad for 4 years.
<rafaelMOD>
I really like it. The only problem is when i need to route DDR3 traces!!!
<CaptHindsight>
rafaelMOD: do they give you native Orcad files or just .pdf's?
<rafaelMOD>
Just pdfs
<CaptHindsight>
oh boy
<CaptHindsight>
so it's really just layout notes and a checklist
konradoo77 has joined #linux-sunxi
<rafaelMOD>
Yeah, and all in chinese! Google translator gives little help.
<oliv3r>
rafaelMOD: really? you should try gEDA, it seems to lack some polish here and there, but the 'core', the schematic drawing is solid, the PCB routing bit, is done reasonable (I can't compare those yet)
<oliv3r>
parts is probably better with kicad i expect
<oliv3r>
rafaelMOD: but doing ddr3 seems near impossible with either, since neither do trace length calculation, do they?
<rafaelMOD>
But what about routing rules for timing matching? KiCad doesn't do the calculations. It has a microstrip tool but i never worked with it.
<CaptHindsight>
people do DDR3 with kicad since they have no other option, it's just takes lots of time
<rafaelMOD>
By the way, it was Merrii that sent me the A23 docs, not Allwinner.
<rafaelMOD>
I was corrected here.
<rafaelMOD>
Allwinner passed us to Merrii
<CaptHindsight>
did Merrii make their dev board for the A80?
<oliv3r>
i think so
<CaptHindsight>
I'm starting to wonder who actually does their silicon design at allwinner
<rafaelMOD>
I have to go. Thanks a lot for the help. I will try again tomorrow.
<oliv3r>
rafaelMOD: good luck
<oliv3r>
rafaelMOD: i do hope they do that bit, as that's their core compentents, or should be
<oliv3r>
er CaptHindsight &
<oliv3r>
^^
<rafaelMOD>
Thanks oliv3r! Bye guys.
rafaelMOD has quit [Quit: Saindo]
konradoo77 has quit [Ping timeout: 255 seconds]
<CaptHindsight>
oliv3r: they don't seem to really do much besides glue ip blocks together
konradoo77 has joined #linux-sunxi
<oliv3r>
CaptHindsight: i was told that the VPU is their own dragon
<oliv3r>
hence the protection around it and the stolen code
physis has quit []
<oliv3r>
mripard_: what would happen, in theory, if I did not want to relicense my work under the X11 dual license?
<oliv3r>
mripard_: (I allready sent you the ack ;)
<mripard_>
oliv3r: we would have to revert your patches I guess
konradoo77 has quit [Ping timeout: 260 seconds]
<mripard_>
or we drop the relicensing
konradoo77 has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Skaag has quit [Quit: Leaving.]
deasy has joined #linux-sunxi
Skaag has joined #linux-sunxi
<oliv3r>
mripard_: well if you drop my patches, and add the same thing yourself, would that be allowed, since you'd add the exact same content?
<oliv3r>
i'm just playing devil's advocate here
<oliv3r>
since the content in my patches is so trivial, can you easily re-do it without infringing
<oliv3r>
mripard_: are all dts's files being relicensed? or just ours?
skaag1 has joined #linux-sunxi
Skaag has quit [Read error: Connection reset by peer]
skaag1 is now known as Skaag
<mripard_>
eventually, that should be all
<mripard_>
but since I would like to avoid the pain of doing it later, I'd prefer to do it right away :)
<mripard_>
it's less file and less people to ask to :)
pwhalen has quit [Ping timeout: 276 seconds]
<mripard_>
and as for your question on whether that would be allowed or not, I have no idea
<oliv3r>
mripard_: I mean from a pure copyrightable standpoint, it would be very hard to rewrite something so trivial
<oliv3r>
on the other hand, it's based on facts
<oliv3r>
how the hardware is connected etc, so may in fact, not even be copyrightable anyway
<mripard_>
honestly, I'm not enough of a lawyer to answer here, you're making a good point, but I've been proven wrong today on licenses, so... :)
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
Skaag has joined #linux-sunxi
FR^2 has quit [Quit: Leaving]
bengal has quit [Quit: Leaving]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
jinzo has quit [Quit: Leaving]
Skaag has quit [Quit: Leaving.]
imcsk8_ has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
dsont1 has joined #linux-sunxi
<dsont1>
Hey everyone, I'm really new to playing with hardware
bertrik has joined #linux-sunxi
<dsont1>
I want to learn more about it by deploying different versions of linux, and android onto different chipsets
<dsont1>
but I really know NOTHING
<dsont1>
except I'm a programmer
<dsont1>
anywhere I can start learning?
Andy-D has quit [Ping timeout: 245 seconds]
<dsont1>
good books? like, what's uboot do?
Skaag has joined #linux-sunxi
HeavyMetal has quit [Quit: BNC Services Provided by The ASoTnet IRC Network.]
HeavyMetal has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
bertrik has quit [Remote host closed the connection]
xavia has quit [Remote host closed the connection]
<dsont1>
When you take a new peice of hardware, that's has no port for linux on it... What needs to be done, at a high level?
gzamboni_ has quit [Ping timeout: 240 seconds]
gzamboni_ has joined #linux-sunxi
Skaag has quit [Read error: Connection reset by peer]
Skaag has joined #linux-sunxi
<Nyuutwo>
dsont1: get information
<Nyuutwo>
like SDK, datasheets
<dsont1>
hmm ok
<Nyuutwo>
get working JTAG
<dsont1>
ok
<dsont1>
thanks!
<Nyuutwo>
get something that setups DRAM and load linux to memory (like u-boot)
<Nyuutwo>
and then just coding
<dsont1>
ok so the uboot has to be customized for each hardware?
<Nyuutwo>
linux needs too - but with dtb it is easier
<dsont1>
what about the gcc compiler
<Nyuutwo>
u-boot boots on bare metal - you probably don't have even ram configured and you need interface with rom bootcode
<Nyuutwo>
dsont1: are we talking in general or arm or allwinner specific?
<dsont1>
in general
<dsont1>
oh I see
<dsont1>
wow, so uboot interfaces with the rom bootcode, and sets up the hardware to be ready to boot something
<Nyuutwo>
gcc is needed but your CPU will be supported (just linker scripts)
<dsont1>
cool
<Nyuutwo>
and load kernel from where you want
<dsont1>
the linux modifications, are they just driver issues? or does the hardware act so strange that the kernel needs to be fixed?
<dsont1>
i mean kernel*
<dsont1>
kernel modifications
<dsont1>
thanks alot, this is very informative
<Nyuutwo>
AFAIK when you work on platform which has supported cpu then you need just drivers and memory, irq mappings
<__builtin_yuno>
device tree
<dsont1>
oh, the irq mappings are because it's an unrecognized board, right?
<Nyuutwo>
memory, irq mappings are in device tree and some low level in linker scripts (but probably you don't need to touch it)
<dsont1>
so linux kernel normally knows what board is what, and what the mappings are?
<Nyuutwo>
dsont1: nope
<dsont1>
in a normal system, that is
<Nyuutwo>
you provide dtb with all things which are unprobable
<Nyuutwo>
and which drivers have exported
<Nyuutwo>
*unprobeable
<dsont1>
in a probeable system, the kernel can just probes it to find out what driver?
<Nyuutwo>
yup like devices on usb bus
<Nyuutwo>
but you cannot probe usb host controler
<Nyuutwo>
you need info where it is mapped in memory and its irq number
<Nyuutwo>
it is simplified example
<dsont1>
interesting
<dsont1>
How can I learn more?
<Nyuutwo>
good question
Andy-D has joined #linux-sunxi
<Nyuutwo>
you can read sources of other platforms
<dsont1>
Damn. Hardcore.
<Nyuutwo>
dsont1: in which languages have you programmed?
<dsont1>
alot. mostly web development. but I took game development in university. So I had some exposure to C, C++, Assembly, and GPU Shaders
<dsont1>
directx, opengl
<dsont1>
so I plan to take this wee little A20 board and make it do some swirly pixel shaders on my tv
<dsont1>
as my first project
<Nyuutwo>
pixel shaders ...
<dsont1>
yeah, the A20 has pixel shader support
<Nyuutwo>
so probably you have running board already
<Nyuutwo>
dsont1: in hardware yes, but in software ... hmm let me check wiki
<dsont1>
nope, me and my buddy are doing a startup in shenzhen, and I'm toying with his dev board to get the hang of it, before we get the real deal at our doorstep
Guest89285 is now known as buZz
<Nyuutwo>
dsont1: have good time setting up dram timings
<dsont1>
i read it had opengl es
<Nyuutwo>
on binary blob
<dsont1>
ohhhhhhhh....
<dsont1>
so when I put my new stuff in, that's all wiped
<Nyuutwo>
but there is project lima
<Nyuutwo>
dsont1: not necessary
<Nyuutwo>
when you use opengl API it should be doable
<dsont1>
sweet! as long as I have hardware acceleration drivers, right?
<dsont1>
or even software, if I wanted a painfully slow experience
<Nyuutwo>
yup that binary blob which provides hw acceleration
<Nyuutwo>
but every bug in blob you must workaround
<dsont1>
where did the binary blob come from?
<Nyuutwo>
I don't know - 3D support is something that I don't need
<dsont1>
ok, you said 'dtb' before
<dsont1>
what is that?
<dsont1>
(I'm taking notes, :p)
<Nyuutwo>
device tree binary
<Nyuutwo>
something in mainline - which on sunxi doesn't have good display driver
<Nyuutwo>
on 3.4 you don't have it - you have another devil called fex
<Nyuutwo>
fex - allwinner specific configuration (something simillar to dtb in principle)
<Nyuutwo>
many info about allwiner chips is on wiki
<dsont1>
That's why my friendn suggested I start with that
<dsont1>
Coolness!
<dsont1>
Hey Nyuu, what do you do for a living?
<dsont1>
may I ask?
<Nyuutwo>
I'm student, but I work also (hopping from heavily templated C++ down to low-level C (inhouse u-boot, kernel support and some cortex-m development))
Montjoie has quit [Ping timeout: 260 seconds]
<dsont1>
Cool
physis has joined #linux-sunxi
<dsont1>
I'm working for OnePlus currently, working with ecommerce web tools and stuff
<dsont1>
Cool company, but the work is so boring and tedious =[
Montjoie has joined #linux-sunxi
physis has quit [Client Quit]
<dsont1>
So for a supported CPU, you need drivers, memory, and IRQ numbers
<dsont1>
what do you need to know about the memory?
<Nyuutwo>
for u-boot - dram timings, measured skews, delays and where it is mapped to cpu
<Nyuutwo>
for kernel just where it is mapped to cpu (AFAIR u-boot provides this info by atags or dtb)
<dsont1>
'where it is mapped to cpu' is there a word for that?
<__builtin_yuno>
physical address of DRAM and its size?
<Nyuutwo>
__builtin_yuno++
<dsont1>
oh, cool. I'm learning the lingo :)
<dsont1>
Thanks so much for your help guys, Nyuutwo especially
<dsont1>
I think I'll roll with what I've got now and catch you later :D