jeremb has quit [Remote host closed the connection]
Sternennebel has quit [Quit: Leaving.]
tuliom has quit [Quit: Konversation terminated!]
tuliom has joined #arm-netbook
avernos has joined #arm-netbook
<avernos>
are rockchips open source? like the RK3066? im wondering if is possible to run linux on it
<Marex>
whew
<Marex>
first day of ELCE/LinuxCon Europe is good
tuliom has quit [Quit: Konversation terminated!]
<projectgus>
avernos: afaik rockchip haven't released kernel source for any of their SoCs
<projectgus>
although my information is a bit old, maybe they've changed
jeremb has joined #arm-netbook
drachenphone has joined #arm-netbook
<avernos>
i recall reading that they havent released sources, but i am not sure.
<avernos>
i wonder if there is any linux image around
stefanro1 has joined #arm-netbook
stefanro has quit [Ping timeout: 252 seconds]
alcides has quit [Quit: There's no place like 127.0.0.1]
popolon has quit [Quit: Quitte]
benjamin__ has quit [Ping timeout: 264 seconds]
sdni has joined #arm-netbook
orly_owl has joined #arm-netbook
<jlj>
which ARM distro has support for the most hardware (webcams, wifi dongles etc)? the ones I've tested seem to have pretty limited drivers built in
<WarheadsSE>
jlj: on which device
<WarheadsSE>
there are some drivers that just don't work on ARM as well.
kaspter has joined #arm-netbook
mysteryname has quit [Quit: Leaving]
<Alex1269>
Hi, I heard that a10 emac driver (cubie, rpi, etc) works by interrupts only and doesn't use dma. So it slow on many small packets and use too much cpu. Is that true ?
slash_random has quit [Ping timeout: 240 seconds]
<xxiao>
Alex1269: that's worrisome...where did you hear that?
<xxiao>
you can easily run a network benchmark to test with 64bytes
<Alex1269>
:) on russian habrahabr - they told it doesn't use dma and eat cpu on small packets. So this is no true, right ? :)
wingrime has joined #arm-netbook
mSquare has joined #arm-netbook
kaspter has quit [Ping timeout: 265 seconds]
RITRedbeard_ has joined #arm-netbook
<xxiao>
Alex1269: i don't know, but 64Byte is challenging to all cpus
<xxiao>
never checked its emac driver
<Alex1269>
I found in irc logs that dma used only on rx packets greater than 2000 bytes. Internet packets allways < 1500 bytes so dma doesn't used on real network loads...
<xxiao>
normally for small packets the copy of packets is not the bottleneck, the heavy interrupts/processing is
<xxiao>
for large packets, the memory copy becomes a concern where dma is definitely preferred
<xxiao>
2000 is odd, i don't think for 100mbps interface there is jumbo frame for it
<xxiao>
let me have a quick look on the driver, need locate the source first...
Quarx has joined #arm-netbook
<rm>
every regular NIC works on an (at least one) interrupt per packet basis
<xxiao>
Alex1269: i found a readme in their ethernet driver directory saying "using cpu to read/write fifo, no dma"
<xxiao>
so you're right, this sucks
<rm>
I mean all the popular models for PCI; so interrupts are not the problem
<rm>
^^^^^^^^^^ this, on the other hand, could be
<xxiao>
rm: the ethernet port is part of the soc, why pci here, am I missing something?
<rm>
I was addressing the concern that the NIC "works by interrupts only"; all NICs work "by interrupts", even those you use on your desktop PC
<rm>
the difference is those fire an interrupt and then DMA the actual packet
<rm>
but with the A10 it seems like you have to use the CPU to do all the work to fetch it
<rm>
but anyways
<rm>
this did not show to be much of a problem
<rm>
lundman <- improved the driver somewhat and now it for example does not cause HD playback to skip
<oliv3r>
hipboi: appearantly t-online was blocking our entire IP range, that's fixed now and those requests went through. only at&t/bellsouth is now hodling, so that's 2 addresses. they shuld be going through soon too.
sspiff_ has joined #arm-netbook
bsdfox has quit [Ping timeout: 255 seconds]
rellla has joined #arm-netbook
Quarx has quit [Read error: Connection reset by peer]
<oliv3r>
i see some printk 'fixes' coming by on the list by using pr_debug; what's the difference with the dev_ debug printing things?
<mnemoc>
pr_debug() is the standard method, activated using #define DEBUG. dev_debug() is a wrapper around pr_debug() but takes a dev as first argument, to get pass a context
<mnemoc>
otoh allwinner code tends to add random wrappers directly around printk(), which is invalid
<mnemoc>
like sun4i_gpio_dbg()
<mnemoc>
and for prefixing the right way is to define pr_fmt, normally as DRIVER_NAME ": " fmt
<oliv3r>
so pr_debug() is preffered over dev_debug? I would think in combination with the dev_err etc entries it would be nice and homogenous :)
<oliv3r>
just wondering is all
<mnemoc>
if there is a struct device *dev; in the context dev_debug is preferred
<mnemoc>
i doubt it's used for anything already, but more of a future proof good practice thingy
<slapin_>
oliv3r: if you can use dev_debug, you should use dev_debug, otherwise use pr_debug
<mnemoc>
that's what I tried to say :|
<slapin_>
if you have sane dev struct at sane place that is
slash_random has joined #arm-netbook
<libv>
oliv3r: dev_debug is preferred
dfletcher_ has quit [Read error: Connection reset by peer]
<slapin_>
so if you need to find which dev struct to use and it is not obvious from context, better use pr_debug.
<libv>
oliv3r: but it requires a dev to be passed
dfletcher_ has joined #arm-netbook
<libv>
oliv3r: which would require a massive rewrite of everything
<libv>
oliv3r: goal is to get there though, but it is a bit far away
<mnemoc>
most of the times it's hidden inside another dev struct, like &pdev->dev or so
<slapin_>
I think such changes hould be passed as one single piece, because it is show-stopper for upstreaming
<libv>
it it were only that easy :)
<slapin_>
it should be done early
<libv>
slapin_: dream on
<libv>
slapin_: about upstreaming
<slapin_>
libv: why not?
<libv>
and the other requires a massive restructure first.
<slapin_>
that is intended target, is it not? otherwise why struggle?
pawel5870 has quit [Ping timeout: 240 seconds]
<libv>
slapin_: and the timeframe for that is?
<libv>
structure comes first
<slapin_>
upstreaming is interactive process, hence not ime frame
<mnemoc>
slapin_: it is the ultimate goal, yes. but on a very long run
<libv>
otherwise you are further complicating matters artificially trying to get a dev everywhere
<slapin_>
I mean, you can upstream piece by pice
<mnemoc>
slapin_: there is nothing in our kernel that is even near been acceptable to be presented to lkml
<slapin_>
like, from basic SoC things
<mnemoc>
nothing acceptable in basic SoC support either
<mnemoc>
and we don't know enough to reimplement
<libv>
honestly, these are quick fixes
<libv>
to make sure that the crap allwinner code at least passes logging levels
<libv>
and doesn't just do printk everywhere
<mnemoc>
we don't even know how the clocks work
<slapin_>
mnemoc: this is why upstreaming process should be started so a lot more people will look into code and will advice.
<slapin_>
Marex: say something, you
<libv>
slapin_: with what?
<mnemoc>
the sata/mali pll4/pll6 issue showed that the documentation is useless and the code is not reliable either
<libv>
slapin_: what should upstreaming be started with?
<libv>
slapin_: and feel free to go at it.
<libv>
and the best of luck to you too
<slapin_>
libv: SoC + basic board support. To base all next development on.
<mnemoc>
I started doing a pinctrl driver, but $work$ has me neutralized
<libv>
slapin_: go do it, now.
<mnemoc>
the clocks need to be migrated to the common framework
<slapin_>
libv: I'm too lazy for that now, I have enough with u-boot + NAND + mtd thing. :-P
<mnemoc>
the mach-sun*i need to be made multiplatform
<mnemoc>
the cpufreq needs to be made a driver
<mnemoc>
etc etc etc etc
<libv>
then don't complain when people who are actually working on restructuring things are not too worried about upstreaming
<slapin_>
mnemoc: these could be planned on wiki and implemented step by step
<libv>
that upstreaming would now just be a useless extra burden
<hipboi>
yes
<mnemoc>
libv: +1
<hipboi>
a to do list on the wiki
<mnemoc>
todo 1: unify all drivers
sdni has quit [Ping timeout: 245 seconds]
<slapin_>
libv: restructuring for restructuring is not a good motivation for improving, upstreaming is.
<mnemoc>
todo 2: make usb-slave not-android-centric
<libv>
slapin_: ?
<mnemoc>
slapin_: restructuring is the first step toward upstreaming
<libv>
slapin_: you've never properly refactored a large piece of code, have you?
<stefanro1>
i think slapin_ is not wrong - trying to get very basic SoC support upstream is a good thing (tm)
<libv>
slapin_: you've never wanted to see something clearly expose its inner workings and become massively hackable?
<slapin_>
libv: I did a lot of refactoring, why?
<libv>
slapin_: i did.
<stefanro1>
i might give it a try in the next few days - not sure how far i can get with it
<libv>
slapin_: it's why there is RandR1.2 and kms today
<libv>
slapin_: i did so for a huge pile of .tw crap called via.
<libv>
and it is where the base ideas behind randr1.2 and kms come from
<mnemoc>
the only thing we will get by trying to mainline the plat core is to split the resources
<mnemoc>
which are already very limited
<libv>
slapin_: i have a very shrewd idea of what i am doing, and i know what this disp code could look like.
<libv>
and what it could do
<libv>
and i know: upstreaming is a long term goal, but nothign to worry about too much today
<libv>
first we need to make proper sense out of this crap
<libv>
and the code will naturally become upstreamable along the way.
<mnemoc>
+1
<stefanro1>
i have seen many vendor linux kernels which didn't bother too much with upstreaming - they always were is quite bad shape
<libv>
stefanro1: you inversed cause and effect there.
<libv>
code was in bad shape beforehand
<libv>
and the extra effort of cleaning it up prohibited upstreaming
<stefanro1>
libv: yes sure - i'm still quite new to this allwinner sunxi stuff
<libv>
and if the extra effort of upstreaming is already too much, then moving on to the next soc will definitely mean that all further maintenance is dropped
<libv>
the reasons for not upstreaming are also the reasons for the code being in bad shape today
<libv>
not what you said.
<mnemoc>
stefanro1: they provide partial access to their "proprietary" kernel to each customer depending what each buys which is the result of mashing up pieces from different separated maintainers working on separated trees
<libv>
if there is no maintainer for the code in the kernel, it will get tossed.
<mnemoc>
stefanro1: then any code they can cut out is cut out. and mach-foo and cedarx provided in binary-only form
<stefanro1>
okay, i agree that allwinner is the root cause of this "bad shape"
<mnemoc>
the sun5i tree for A13 is incompatible with the sun5i tree for A10s
<mnemoc>
from "upstream"
<mnemoc>
that's why restructuring and unification is critical
<mnemoc>
more than mainlining the core
<stefanro1>
might be - i still think that mainlining SoC core and later porting and pushing drivers bit by bit is good - even though this will bind some "resouces" of course
<slapin_>
I'm really sorry what I was not clear about what I mean. I just mean that upstreaming is non-atomic interactive process, it is generally done step-by-step, piece-by-piece. It is not possible to just make it all upstreamable at once. While we prepare code, the kernel will evolve, and we will need to do it all again, and we'll never approach proper stage. It is best to prepare small pieces and upstream them, there are pro's like this *visibility*
<libv>
slapin_: wrong.
<libv>
slapin_: with clean, structured code, it is very very easy to adapt to infrastructure changes.
<mnemoc>
stefanro1: we have two paths, refactoring everything toward a mainlinable core, or making a new mainlinable core totally separated to the real world
<mnemoc>
the first is what we are trying, starting from the bottom, fixing and unifying drivers
<libv>
slapin_: cfr my unichrome driver, which was backwards compatible until xfree86 4.3 (released in the summer of 2003) in 2010 still, after which i limited myself only to the X version in debian old-stable
<mnemoc>
the second implies splitting the resources and making the real world have no benefit from the cleanup until a future when the sunxi is not relevant anymore
<slapin_>
what about trying to get more resources from kernel community with upstreaming?
<mnemoc>
but also we don't know enough to make decent core either
<stefanro1>
mnemoc: yes, that might be the case - but i fear that the kernel will then be never be pushed upstream as you (we) are always a step behind mainline and never catch up
<slapin_>
Also, some todo list in wiki would be nice thing to have regardless of whatever.
<stefanro1>
please bear with me, i still havent looked too deep into the sunxi kernel code yet
<RaYmAn>
It certainly wouldn't be bad for someone *cough* slapin_ *cough* to put in writing the goals for each stage of mainlining :) E.g. GPIO/pinctrl, pm, basic fb disp or similar
<libv>
slapin_: what resources does the kernel community have?
<mnemoc>
slapin_: start it, priority one. unify all drivers
<RaYmAn>
:P
<libv>
slapin_: feel free to mail lkml and ask for help cleaning up this chinese mess
<mnemoc>
*g*
<slapin_>
mnemoc: I think people who know what to write in TODO better do it.
<RaYmAn>
tegra2 has been mainlined for like..a year. Yet, it's only recently actually become vaguely usable on any device (and certainly still not properly usable yet)
<RaYmAn>
I don't really think that's a much better situation :P
<libv>
slapin_: all you get by upstreaming is forcing others to change infrastructure to also match our usecase, and to have them adapt our code too
<slapin_>
libv: generally kernel community works a different way - you provide patches and people suggest how to make it properly.
<libv>
slapin_: this massive burden, nothing compared to the work we have ahead, we will have to bear on our own now
<libv>
slapin_: for existing code, yes
<libv>
slapin_: for new code you end up having to redesign the whole thing
<libv>
slapin_: which is the restructuring we are doing now anyway
<libv>
once the structure is clear for this disp driver, i can throw stuff around quite easily without breaking things, matching whatever demands anyone upstream will have
<libv>
slapin_: check out my radeonhd code, i wrote that to be quickly and easily portable for the next two decades
<slapin_>
ok, I see.
<libv>
but it was easy to do that as we wrote that from scrap
<libv>
i spent ages picking at unichrome code until it was vaguely in a similar state
<libv>
structure and sanity is the goal, and it is the same goal the people on lkml have, they might have different views on some details though
<RaYmAn>
to be fair- is there any reason we can't try and mainline without e.g. disp? iirc that was the case on tegra2 for a long time.
<libv>
RaYmAn: i am just a graphics driver guy
<libv>
RaYmAn: which is why i am playing with disp
<RaYmAn>
to allow disp to be restructured/rewritten seperately from mainlining?
<libv>
RaYmAn: i expect others to do similar work on other subsystems
<libv>
again...
<mnemoc>
usb is the next in priority. help wanted
<libv>
try mainlining those other bits.
<libv>
the same work needs to happen everywhere.
<mnemoc>
even our gpio driver is crap. it only works for outputs, not for inputs
<oliv3r>
what's the big difference between the a1000 and a2000? Why would i want the a2000? seems the a1000 seems more interesting
<mnemoc>
oliv3r: only different case
<mnemoc>
oliv3r: there are 1GB variants these days. not sure if the pcb is the same
<RaYmAn>
libv: my point was primarily that e.g. it will impact disp driver if mainlining was started - e.g. gpio driver changing => issue with disp changes..Taking pieces out of the equation and defining a minimum would allow these changes to be done, without touching $old_disp allowing for easier merging later.
<RaYmAn>
or something
<RaYmAn>
:)
<mnemoc>
slapin_: in your case the best thing you can do to help (after the fel tool to extract boot0/boot1) is the mtd driver
<oliv3r>
the sata/mali pll4/pll6 issue makes me cry and cringe, more cry really. we have the code (that's buggy) we have leaked docs (that are wrong) and allwinner will never admit or fix either I bet
<mnemoc>
RaYmAn: to mainline anything we need a new core. using DT, common clock framework, pinctrl, gpiolib, multiplatform
<libv>
RaYmAn: i am here, i can easily take changes in to disp
<libv>
RaYmAn: and the gpio code is really minimal
<libv>
there really is amazingly little arch stuff that i depend on.
<RaYmAn>
mnemoc: I know
<RaYmAn>
mnemoc: defining a minimal set of components that need to be rewritten could be useful though
<RaYmAn>
a common subset of truly *minimal*
<mnemoc>
personally I prefer to find people to focus in usb and nand
<libv>
this whole discussion is pretty pointless really
<libv>
we know there is tons of shit to do
<libv>
go do some.
<mnemoc>
RaYmAn: drivers can't be useful without a core
<RaYmAn>
sure, but it's not strictly required for minimal. By defining a minimal + having seperate work on larger parts could allow proper dual-work
<RaYmAn>
Clearly we have people who want to work on mainlining + people who want to rewrite and make drivers better. My point is that it's not necessarily mutually exclusive
<mnemoc>
problem is people who insists in mainlining isn't helping in fixing anything
<mnemoc>
just asking for mainlining
<libv>
mnemoc: +1
<RaYmAn>
sure, in that case they should just shut up :)
<libv>
mainlining will magically solve everything, right?
<RaYmAn>
Of course not :)
<mnemoc>
tegra is the best example for that
<mnemoc>
mainlined code was useless in reality
<libv>
then what needs to be done, and can it be done separate of mainlining, and why are you not doing that?
<RaYmAn>
lack of time :)
<mnemoc>
pick usb or mmc or nand and do what libv is doing in disp
<slapin_>
lack of TODO
<mnemoc>
slapin_: I'm giving you the TODO. pick one and start doing it
<RaYmAn>
slapin_: that's just a amtter of starting a wiki entry - then people can help fill it out/remove stuff.
<slapin_>
mnemoc: I'm not wiki guy - all I write is crap.
<libv>
RaYmAn: it is a matter of having chat with mnemoc
<libv>
a chat even
<mnemoc>
slapin_: you like nand, then start working on it. you don't need a wiki page telling you for that
<slapin_>
mnemoc: agreed
<libv>
mnemoc tends to have a shrewd idea of who is playing where
<mnemoc>
:)
<RaYmAn>
It makes no sense to expect people already working on stuff to change their priorities - and I don't think anyone expects that really
<mnemoc>
rz2k has mali, libv has disp, slapin has nand, hno has u-boot, I have endless chats on irc, .... anyone takes usb or mmc?
<libv>
mnemoc: you can pretty much call yourself manager here
<slapin_>
RaYmAn: but I'd be happy if somebody added some A1x SoC code to mainline, and would donate $100 to appropriate paypal account.
<mnemoc>
doh
<libv>
mnemoc: now approve my holidays and expenses!
<RaYmAn>
I wish I had time to properly take up something :/ But, for now I'll start by whipping up a wiki page for minimal mainlining
<libv>
RaYmAn: how very helpful
<mnemoc>
i want to finish the pio stuff :<
<libv>
RaYmAn: after this whole discussion here...
<RaYmAn>
libv: :)
<RaYmAn>
libv: I'm *np
<RaYmAn>
libv: I'm *not* saying it has to be done that way. But it makes sense to have a set a goals and milestones for mainlining.Even if it's not necessarily right now
<slapin_>
everybody likes to slack, don't blame people for that...
<RaYmAn>
Not everyone can just see something e.g. USB and then just start rewriting it to make sense. Organization does help then.
<libv>
RaYmAn: again, people turn up on irc here
<libv>
RaYmAn: and start asking around
<libv>
RaYmAn: and i have seen mnemoc guide people in the right direction several times already
<RaYmAn>
sure
<libv>
RaYmAn: this system works.
<libv>
and much better than a wiki, as with a wiki you get 50 people starting this stuff and all giving up after Lindent
<mnemoc>
libv: not sure if i'm happy been called manager :|
<libv>
mnemoc: wake up and smell the coffee managerboy :p
<mnemoc>
:)
<slapin_>
ah, cofeeeeeeee..... hmmm...
<libv>
mnemoc: i need more hw, please do all the paperwork for getting the new budget approved :p
<mnemoc>
narf
<mnemoc>
but I'll go for another coffee :)
<oliv3r>
mnemoc: that list is good for the wiki :D
<mnemoc>
I forgot! oliv3r is our wiki master :)
<RaYmAn>
libv: lets say someone wants to work on mainlining as a personal goal. Then they show up here and get told they should do USB or MMC. How does that help if that's not what they want to do? People don't necessarily have the overview of the platform sufficient to figure out where to start. But nevermind. Clearly *your* way is the only way ;)
<RaYmAn>
(Yes, that's kind of trolling, but my point is that one singular way might not work for everyone.)
<mnemoc>
I someone really wants to focus in mainlining, refactoring the clock stuff is his first step
<oliv3r>
finally, i'm all read up
<oliv3r>
you people talk to much
<oliv3r>
go write some code :p
<mnemoc>
i should have been coding :<
<oliv3r>
mnemoc: what did you mean btw, that your work didn't allow you to write gpio stuff
<oliv3r>
i'll go work :(
<mnemoc>
too much $work$ to do
<oliv3r>
i'll continue writing on the clocking stuff :)
<oliv3r>
mnemoc: lies! you are here on IRC! all those words could have been code!
<oliv3r>
:p
<mnemoc>
i don't need to think to talk here
<mnemoc>
i need to think and focus to write code
<mnemoc>
like a low prio thread
<oliv3r>
i jest, i jest
<RaYmAn>
slapin_: also, "not a wiki guy" is bullshit. It takes 5 minutes to figure out how to do the most important things wrt. writing on a wiki
<oliv3r>
i've been putting off the wiki stuff too long too
<oliv3r>
i'ts boring :S and annoying to write wiki stuff
<RaYmAn>
sure
<oliv3r>
just plain text is enough imo, doens't need wikification right away if you can't do it
<oliv3r>
anyway, back to register documenting after bathroom break :)
<RaYmAn>
but for e.g. writing a todo, all you really need is to know prefixing * means list item ;)
<libv>
oliv3r: plain text, and then pasting in the wiki in ... whatever syntax mediawiki uses again for direct quoting :)
<RaYmAn>
I figured someone else should look at it first and see if there are changes before making it linkable from anywhere
orly_owl has quit [Ping timeout: 252 seconds]
<slapin_>
RaYmAn: thanks. not a wiki guy means as soon as I get to write wiki, or some other doc, I immediately get writer's block and whole effort becomes too complicated to handle. I know a technical side of things and remember some of mediawiki from 2006-2007,
<oliv3r>
any text is better then no text :)
<oliv3r>
people expand it if needed
orly_owl has joined #arm-netbook
<slapin_>
how do you register in wiki by the way?
<RaYmAn>
click register
<RaYmAn>
:P
<RaYmAn>
well "Create account"
<mnemoc>
top right corner
<slapin_>
thanks
drachensun has joined #arm-netbook
<drachensun>
turl, or anyone else who knows, I understand cm10 is working for the A10s, how can I get an image of it to try? Does it boot from SD or internal flash?
<hno>
RaYmAn, Milestone 1 can be a lot smaller. No need for PMU, PINCTRL, Clock or GPIO in first stage.
<RaYmAn>
hno: milestones are intended as "take stock kernel - add these things" - Can we boot without those things?
<hno>
Yes.
<hno>
they are all configured in a usable state before kernel is started.
<RaYmAn>
hno: so uhm..what's left? :P
<hno>
Timer. Core SoC support. UART.
<stefanro1>
hno: plus interrupt controller
<hno>
yes
<hno>
and fdt.
<hno>
then pinnux, clock.
<hno>
then more drivers.
<RaYmAn>
ok, updated a bit
<hno>
PMU is not needed until milestone 3 the earliest.
<hno>
it is needed by cpufreq mainly.
<Turl>
drachensun: usually from nand, but it can boot from SD too if you wish to
<Turl>
drachensun: make a device tree and build it manually or using the BSP
<drachensun>
turl: Ok, so in your github I see a few different related sounded packages
<drachensun>
turl: I built CM for my galaxy nexus before but its far enough back its all a little vague now :-)
<drachensun>
turl: Do I need all the android repos in there?
<drachensun>
turl: I found the wiki info
<drachensun>
turl: just now, I guess is that all up to date?
<mnemoc>
I still find pretty useless to implement DT before having platform drivers to configure using it
<drachensun>
turl: So nevermind, I'll run through the guide and see what I get, thanks
<RaYmAn>
mnemoc: I guess my idea was to make the milestones such that each could potentially be accepted into mainline
<mnemoc>
ok. np. I just don't see the point of the race to mainline when there is so much work to do in other areas
<RaYmAn>
There's no race :)
<mnemoc>
but I've already wasted too much time arguing that
<RaYmAn>
I'm mostly just trying to formalize the pieces of the puzzle, so it's clear
<mnemoc>
for me the priorities are from the bottom, drivers, to the top, core
<mnemoc>
but the tree is open and anyone can work on whatever he likes
<mnemoc>
so for /me the milestone 1 is driver unification, then getting important drivers in good shape
<RaYmAn>
If the drivers are done properly, there is no dependency on any non-standard system things anyways ;)
<RaYmAn>
driver unification is just rather..vague imo
<mnemoc>
it means not having almost identical sun3i/sun4i/sun5i/sun6i/... drovers for every controller
<mnemoc>
but having a single sunxi driver
<mnemoc>
and THEN clean it
<RaYmAn>
yeah
<RaYmAn>
that makes sense
<mnemoc>
disp has unified, now it's been cleaned
<Turl>
drachensun: the guides aim at ICS/CM9, but JB is not that much different
<mnemoc>
same needs to be done for the other drivers
<mnemoc>
the value is in been able to use the code on real devices
<mnemoc>
and eventually, getting it mainlined
<drachensun>
turl: Ok excellent
<mnemoc>
but everyone is free to work on whatever part he likes
<mnemoc>
the only possible value I could see in mainlining a useless core is to send a message to allwinner
<mnemoc>
which is not a bad thing
<libv>
who will accept useless code?
<RaYmAn>
useless is a matter of perspective
<mnemoc>
useless as not usable to get a prompt
<RaYmAn>
which is why UART is included :P
<mnemoc>
:)
<RaYmAn>
in first milestone
<RaYmAn>
sure, it's not useful for e.g. running android or regular linux on for production usage
<libv>
RaYmAn: why do _you_ need upstreaming?
<RaYmAn>
I don't *need* anything
<libv>
RaYmAn: because you keep on coming back, but are only willing to throw stuff into the wiki
<libv>
oh, and talking on irc
<mnemoc>
me too :p
<RaYmAn>
I'm kind of at work ;P
<RaYmAn>
Also, note I'm not complaining nor pushing anyone towards doing it this way.
<libv>
then what are you doing?
<RaYmAn>
discussing.
<libv>
discussing with what purpose?
<libv>
or just discussing for no reason?
<RaYmAn>
enlightenment :)
<libv>
of whom?
<libv>
and for what?
<RaYmAn>
Me, mostly. And whoever else gets something out of discussing how to do things best.
<libv>
i am doing things.
<libv>
others are doing things
<RaYmAn>
So don't argue if you don't care? :)
<libv>
i know how i should be doing things, as i only have been doing them for the last decade
<libv>
RaYmAn: seems like you need to start using facebook or google+ or something
* RaYmAn
sighs
<mnemoc>
or diving into the usb drivers :)
<RaYmAn>
libv: A discussion can be valid to have even if one or more people disagree.
<libv>
RaYmAn: but you just disagree, and ignore the datapoints we provide
<libv>
RaYmAn: and you simply continue
<libv>
RaYmAn: take it to facebook
<libv>
when we state "if you really believe so, go and do it, but stop whinging", but all you do is continue whinging
<mnemoc>
:(
<RaYmAn>
libv: do feel free to read the backlog. I didn't continue arguing at all - I replied to people's comments. And comments like "take it to facebook" is really just a great way to make a good community. Could we please keep it to actual relevant discussions?
<libv>
haha
<libv>
actual relevant discussions
<libv>
sure :)
<slapin_>
ah, don't do that, please, having some plan is cool and important.
<rz2k>
DRAMA
* rz2k
opens a can of cola
* RaYmAn
sighs
<slapin_>
you can't make people work by whip only, you need some candie on other end...
<RaYmAn>
I'll stop and go back to working. There's no point in arguing if we have to stoop to poorly disguised insults.
<slapin_>
don't take all fun out of it
<hno>
Everyone scratches their own itch. Why arguing whos itch is best?
<slapin_>
RaYmAn: your contribution is appreciated, seriously
<libv>
ah, but i do care about people actually scratching their itches, not about whinging about which itch to scratch
<slapin_>
libv: it is good sometimes to step back and look at the proceedings, now I have more or less overview of the situction, thanks to the discussion
<slapin_>
libv: you can't just do your things w/o looking what others do, and what are plans and goals.
specing has joined #arm-netbook
specing has quit [Changing host]
specing has joined #arm-netbook
<libv>
slapin_: code talks.
<slapin_>
libv: in OSS world everybody do what they like doing, as you remove fun - nobody will do anything
<slapin_>
blah-blah-blah
* slapin_
gets back to $coding$
specing_ has joined #arm-netbook
<mnemoc>
more than a TODO for mainlining (from the minimalest core with UART) it could be helpful a summary of the state of each driver/subsystem and what each need to become mainlinable
specing has quit [Client Quit]
specing_ is now known as specing
<mnemoc>
from a refactoring it as whole point-of-view
<mnemoc>
but.. well... back to $coding$
wingrime has joined #arm-netbook
erc_ has joined #arm-netbook
<erc_>
hi
<erc_>
anybody using A10 cpu for development ?
ercani has joined #arm-netbook
ercani has left #arm-netbook [#arm-netbook]
<slapin_>
erc_: which kind of development?
<erc_>
I have a question about rootfs on A10
<erc_>
I wrote a driver and I can not find its location when I boot the device
<erc_>
there are 2 rootfs and one is hidden ( not accessable )
<erc_>
any idea how to access?
<mnemoc>
mount?
<erc_>
cannot load rootfs that has /lib/modules
<mnemoc>
what do you mean by "load"?
<erc_>
load means in boot stage
<erc_>
when I log as root, I only rootfs which is inside sun4i_rootfs.cpio.gz
<erc_>
and this file is prebuilt
<RaYmAn>
it kind of sounds like you're getting the ramdisk and you want another
<erc_>
and given in lichee/linux-3.0/rootfs
<erc_>
even before you build, this rootfs is not generated by building
<erc_>
it contains the minimum working.
<erc_>
and after building I get another rootfs
<erc_>
it is located in bsp lichee/out/rootfs.ext4
<erc_>
this one is I want to load
<erc_>
clear ?
andoma has quit [Remote host closed the connection]
<mnemoc>
i doubt anyone here is using the original lichee sdk
<L84Supper>
anyone have a fully functional i.mx6 board or device yet?
<L84Supper>
any OS?
<mnemoc>
popolon: then go and ask allwinner for the specs or to buy samples
<mnemoc>
popolon: it's not ready yet
<erc_>
mnemoc: ok
<specing>
L84Supper: yup, steev
<erc_>
mnemoc: this is sun3i ? the link
<L84Supper>
oh they finally got some good silicon
<mnemoc>
erc_: no, sunxi in general. sun3i doesn't even compile :|
<L84Supper>
I'll have to keep an eye out for i.mx6 parts on the broker sites
<specing>
L84Supper: not sure how functional it is
<L84Supper>
I'd like to see a comparison between the the new dual core a15 exynos and the quad core i.mx6
<L84Supper>
Freescale looks late to the party again
<mnemoc>
popolon: it is confirmed they are working on a new quad-core soc since the begining of the year, code-wise called sun6i, but nothing else has be told. there are pictures of banners showing it as A15X instead of A40. it's not a rumour that something exists. the vague part is the specs. what is sure is that it's not on sale yet
<popolon>
Thanks for your answers :)
<popolon>
a7 can be in big.LITTLE and support 4 A7 core at the same time I seen on wikipedia
<popolon>
but the 8 GPU cores ? Mali 450 or Mali 6xx ?
<popolon>
well need to wait until they release final informations
<mnemoc>
a7 is equivalent instrutions-wise to a15, intended as the little brother. but it's also a very cheap way to have a quad core
<mnemoc>
it's doubtful they'll give mali 6xx to a chinese. so 450 is more probable
<mnemoc>
but some people says it's not mali at all
<libv>
what else is commonly labelled with X cores?
<libv>
you do not tend to see that for vivante
<libv>
and pvr also tends to have different marketing
<Turl>
chinese abuse specs for marketing though
<mnemoc>
some claim the mali on the A10 is dual...
<Turl>
like, if you've got a 300Mhz gpu and 1Ghz CPU the thing has "1.3GHz processor"
<libv>
yes, but have you seen X gpu cores on vivante or pvr?
<rz2k>
did vivante release something for X11?
<Turl>
and it's "many core" (which is correct, but not the typical usage)
<rz2k>
freescale is member of linaro, right/
<rz2k>
?
<libv>
i have so far only noticed that for mali
<libv>
and even on mali it is off
<libv>
4 core mali is actually 5. 1gp, 4pp
<libv>
official marketing is mali400mp4
<libv>
anyway, if they state 8 core gpu, then i think it will be a mali450
<jelly>
Turl: so my i3 and entry level nvidia is like 2 cpu + meager 24 vector/shader units = 26 cores!!! ?
<rm>
jelly, don't forget to add up all the MHz
<jelly>
I'm guessing it's over 9000
* slapin_
hates green LEDs :(
<Turl>
jelly ofc
<specing>
jelly: I heard nowadays desktop GPUs have hundreds of cores
cat_x301 has quit [Ping timeout: 276 seconds]
erc_ has quit [Ping timeout: 245 seconds]
<alcides>
specing its true
<libv>
specing: radeons were hitting 1TFlop in single precision when i was still doing radeonhd
<libv>
now the top end are hitting that in double precision
<libv>
back then top end radeons had like 320 shaders
<libv>
my guess is that we are now looking at 640 or above for radeons
<libv>
ah, 2k
<libv>
for TFlop double precision
<libv>
1 tflop even
<libv>
draws more than 250W though
hipboi has left #arm-netbook ["Leaving"]
gimli has joined #arm-netbook
gimli has quit [Read error: Connection reset by peer]
gimli has joined #arm-netbook
ol1ver has quit [Ping timeout: 255 seconds]
slash_random has quit [Ping timeout: 240 seconds]
bsdfox has joined #arm-netbook
bsdfox has quit [Changing host]
bsdfox has joined #arm-netbook
cat_x301 has joined #arm-netbook
rellla has quit [Quit: rellla]
ol1ver has joined #arm-netbook
pawel5870 has joined #arm-netbook
<traeak>
youch mips is toast
<traeak>
lovely the powervr guys acquiring mips
<traeak>
almost worst case
<libv>
yikes
<libv>
or yippie.
<libv>
now arm will sell even more mali :)
<libv>
but yes, byebye mips
<specing>
Not sure how MIPS failed...
* mnemoc
looks at his gdium and his see mips run linux book with nostalgia
<mnemoc>
not sure about others, but the loongson was cpu-only and the result is a board that consumes and weights as much as an intel board, with a very crappy performance
<L84Supper>
mips is big in China, they are even using them for their petaflop clusters
<mnemoc>
is the loongson 3 used in SoCs or CPU-only?
<mnemoc>
mine was a crappy 2f
<mnemoc>
and a power hungry beast
gsilvis has quit [Read error: Connection reset by peer]
gsilvis has joined #arm-netbook
pawel5870 has quit [Quit: Leaving.]
<mnemoc>
the routerboards are nice
<libv>
now arm will undersell pvr with mali big time :)
RaYmAn has quit [Ping timeout: 276 seconds]
RaYmAn has joined #arm-netbook
<hno>
mnemoc, would be nice if Apache file types knew about .tgz and some other common extensions on linux-sunxi.org sites.
<mnemoc>
it's nginx.... what other extension is not defined?
<mnemoc>
meh... the default list is pretty short
<hno>
.bin .tar.gz .tgz tar.xz, etc etc..
<hno>
noticed on dl. and tom.
<mnemoc>
.bin should be fine as application/octet-stream
<hno>
Right, it is... Firefox is just being stupid there.
<mnemoc>
the default is application/octet-stream, not sure what to use for the compressed ones. will find out and add explicit rules for those
<hno>
.tar.gz (and .tgz) is best as application/x-tar with Content-encoding: gzip
<mnemoc>
and for the bz2 and xz variants?
<traeak>
intresting...one of arm's holdoing companies bought most of the patents
pawel5870 has joined #arm-netbook
Quarx has quit []
<mnemoc>
to save from from trolls hopefully
<mnemoc>
s/from/them/
<ibot>
mnemoc meant: to save them from trolls hopefully
<mnemoc>
it's kind of weird to use tom's surname as a thing, but yes :)
<mnemoc>
tinti: yes
<tinti>
mnemoc: he will be rich and happy with it for sure :)
<mnemoc>
eventually :)
<mnemoc>
he didn't believe he was going to be able to get the 50k in indiegogo. he still doesn't believe that can become 100k
<mnemoc>
but i'm sure he will do quite well
<mnemoc>
hno: made the change for .tar.gz/.tgz
<mnemoc>
hno: are you sure it's the right thing to do? I always assumed "Content-Encoding: gzip" as a only-for-the-wire thing
<tinti>
mnemoc: I think he will reach with ease the 100k
<tinti>
mnemoc: specially because cubieboard looks more like arduino in shield system
<mnemoc>
start desiging a cap to plug arduino shields ;-)
<tinti>
and put it in indigo
<mnemoc>
:)
gzamboni has quit [Ping timeout: 276 seconds]
gzamboni has joined #arm-netbook
wingrime has quit [Ping timeout: 255 seconds]
Sternennebel has joined #arm-netbook
ol1ver has joined #arm-netbook
benjamin__ has joined #arm-netbook
slash_random has joined #arm-netbook
<hno>
mnemoc, Transfer-Encoding is "for the wire". Content-Encoding is how the data is encoded on the server.
<mnemoc>
ah
<mnemoc>
hno: works ok now?
jas-hacks has joined #arm-netbook
<hno>
.tgz and .tar.gz works fine. tar.xz not.
<mnemoc>
i had no idea what mime type to use for that one
<hno>
but have no idea what is suitable for tar.xz.
<mnemoc>
:)
<hno>
there is no content-encoding for xz.
<mnemoc>
is there a more generic "compressed tarball" mime type?
<RaYmAn>
I'd imagine application/octet-stream would work?
<mnemoc>
that is what it gives currently
<RaYmAn>
and that causes issues?
<mnemoc>
don't know, but I won't argue with the squid master :)
<mnemoc>
it's like trying to argue about graphic drivers with libv :p
<mnemoc>
i just shut up, and accept what told as been said by God
<RaYmAn>
:P
<jas-hacks>
hno: new uboot prints "Net: wemac" on hackberry, can take out my kernel wemac patches to if wemacs works without them?
<mnemoc>
fortunatelly arnd didn't give any commandment while he was idling here :)
<hno>
jas-hacks, do you get link?
<hno>
you need to set a suitable mac address by "setenv ethaddr ......"
<hno>
Which reminds me... should change wemac kernel driver to check if there is a MAC in the registers already and use that instead of random.
<jas-hacks>
hno: I need to remove my wemacs patches for PH19 and then test.
<hno>
Do you get link in u-boot?
<jas-hacks>
hno: How can prove in u-boot?
<hno>
configure the network and try to ping?
<techn>
mnemoc: what of those 1st phase mainlining tasks can be done to 3.0 kernel?
<hno>
techn, is it meaningful to do any of those in 3.0?
<hno>
it's more 3.7 candidates.
<techn>
hno: yep.. you can have testing for those.. and other drivers can be adapted
<mnemoc>
all cleanup/fixing in the drivers should start in 3.0 and then forward ported to 3.4
<mnemoc>
for the core, I've been doing the stuff in 3.4
<mnemoc>
don't really want to push farther until the usb driver gets fixed
<hno>
What's up with the USB driver?
<mnemoc>
forward porting is still incomplete
<mnemoc>
it's heavily coupled to android
<hno>
Is it? Didn't smell much android when I looked at it, but maybe overlooked something.
<mnemoc>
specially the gadget part
<hno>
Ah, that yes.
<techn>
if something can be done on working kernel and verified that it wont break something.. I think that's good thing.. and makes easier forward porting, no need to change so many things
<bfree>
out of curiousity, does everyone cross-compile or does anyone compile a kernel natively? I'm mainly curious how long a native kernel compile takes (I'm thinking cubieboard)
<mnemoc>
looooong
<mnemoc>
mine crashes while compiling anyway
<mnemoc>
so I can't tell a real `time`
<hno>
I am crosscompiling, but I would guess 4 hours for a full kernel build natively.
<mnemoc>
techn: btw, go the A10s SDK.... more sun5i random changes :<
<bfree>
ok not only curiousity, I got a first cubie-kernel.deb to build. I was failing cross-compiling it and it took just about 4 hours in qemu-system-arm (no -j2 or anything though so any error would be clear, presumably/hopefully would be 3h or less with -j2) :-o
<mnemoc>
techn: but sure, tested patches are welcomed
<bfree>
facing a 3-4 hour compile time though really makes you think twice about what you are doing :-p
andoma__ has joined #arm-netbook
<mnemoc>
cross compiling in monster i7 machines is simpler :p
<mnemoc>
2-3 minutes and done
<traeak>
monster?
<traeak>
heh
<mnemoc>
some have monster i7 machines at home. not my case
<bfree>
yep, I got a plain debian kernel to cross-compile ... and a stock linux-sunxi (3.4) one ... but I kept breaking it trying to cross compile a "cubie deb" :-/
<mnemoc>
I use a humble amd e350
<hno>
techn, I have downloaded that. Seems to be mostly driver additions, but haven't filtered it down much yet.
tzafrir_laptop has quit [Ping timeout: 255 seconds]
<jas-hacks>
hno: ENET Speed is 10 Mbps - HALF duplex connection, I set ethaddr as A6:B5:C4:D3:E2:D1, ipaddr as 192.168.1.68. Ping fails even to 192.168.1.68
<techn>
hno: mnemoc: atleast hdmi module seems to be older than ours :/
<mnemoc>
in sun4i we have history, you can compare
<mnemoc>
but it's hard to impossible to try to diff :|
<techn>
mnemoc: I'm diffing first the codes I know :p
<techn>
but sure it's easier to compare to lichee-3.0.8-sun4i :p
rellla has joined #arm-netbook
<jas-hacks>
hno: in uboot we probably need to change wemac_phy_read and wemac_phy_read to use something like udelay(150) not msleep, as this working on hackberry for setting 100Mbps.
Almamuetya10 has quit [Ping timeout: 244 seconds]
arokux has quit [Ping timeout: 276 seconds]
arokux has joined #arm-netbook
<techn>
mnemoc: there is new gpio driver :/
<techn>
2 touchscreen drivers
<techn>
improvements here and there
<mnemoc>
sounds like fun
<rz2k>
also headers in mach-sun4i are different from ours
<rz2k>
GPL headers I mean.
<jas-hacks>
hno: uboot is also missing code to initialise gpio PHY19, maybe this would be board specific?
<mnemoc>
ours were added in our repo
<mnemoc>
jas-hacks: yes
<rellla>
hi all, a bit offtopic: which (printed) book do you recommend for learning and diving into git? i'm sick off online reading...
<rz2k>
we should push that to lichee-3.0.8-sun4i-new or something
<rellla>
focussed "pro git" from apress
<bfree>
if I'm trying to produce some deb packaging which might be useful (for the kernel) what branch should I be packaging? sunxi-3.0? sunxi-3.4? I was using sunxi-3.4 but am getting the impression I should be still focused on 3.0?
<mnemoc>
bfree: 3.0 is still preferred unless you want to fix the usb driver
<bfree>
mnemoc: thanks. I'm afraid the chances of me fixing anything useful inside the kernel is bloody slim to none :-( I'm pushing it a bit trying to handle kernel packaging really ;)
vinifm has quit [Read error: Connection reset by peer]
<bfree>
mnemoc: I've heard this ;-) I don't even have any hardware (yet) though :-p
<mnemoc>
well.... /anything
<techn>
rz2k: +1
<bfree>
mnemoc: and to be honest I'm not sure I want (or would be sane for me or you) to take up long term maintaining of it ... but I'm trying to see if I can help get /debian moving ;-) I've no interest in Ubuntu myself (but probably not too hard to do any adapting needed for debian sid packages)
<techn>
rz2k: also I'd like to see new drivers separated :)
<techn>
rather than huge blop
tinti has quit [Read error: Operation timed out]
<bfree>
mnemoc: hehe, well I might be able to motivate myself to write a quick "debootstrap foreign + qemu" guide for armhf for that Debian page to unempty it ;-) next stop when I'm not too snoozy though will be to try and do a slightly better version of what I did to get kernel debs and do it with sunxi-3.0
popolon has quit [Quit: Quitte]
freakazoid0223 has quit [Read error: Connection reset by peer]
tzafrir_laptop has joined #arm-netbook
tuliom has joined #arm-netbook
pawel5870 has quit [Ping timeout: 265 seconds]
hno has quit [Excess Flood]
hno has joined #arm-netbook
<hno>
<hno> jas-hacks, odd. It detects 100Mbps just fine on cubie.
<hno>
<hno> jas-hacks, which GPIO pin to use is board specific.
<hno>
<hno> The PHY power control clearly do not work at all on my Cubie.
<hno>
<hno> gpio clear ph19
<hno>
<hno> everything still works
<hno>
<hno> gpio set ph19
<hno>
<hno> everything still works.
<hno>
<hno> gpio set ph20 (and 21) works fine, controls two leds available on cubieboard.
<hno>
sun4i#ping 172.16.0.1
<hno>
Using wemac device
<hno>
host 172.16.0.1 is alive
<hno>
but there is no loopback in u-boot so pinging oneself do not work
<jas-hacks>
hno: after setting gpio ph19, ping works host 192.168.1.254 is alive :)
<hno>
jas-hacks, did it work setting it with gpio command, or did you need enabling it in code?
<jas-hacks>
hno, by gpio command
<hno>
ok.
<jas-hacks>
<hno> sun4i#gpio set ph19
<jas-hacks>
gpio: pin ph19 (gpio 243) value is 1
<hno>
I guss it's a friendly phy not really needing any initialization.
<jas-hacks>
hno: the order is important, if I set gpio 1st, then set ethaddr & ipaddr. Ping reports :sun4i#ping 192.168.1.254
<jas-hacks>
ENET Speed is 100 Mbps - FULL duplex connection
<jas-hacks>
Using wemac device
<jas-hacks>
host 192.168.1.254 is alive
<jas-hacks>
hno: seems wemac registers half work without power to PHY
<jas-hacks>
hno: or may be after power up requires a bit of time to settle.
<jas-hacks>
hno : Will tfptboot work?
popolon has joined #arm-netbook
<hno>
Ok. That makes sense. I think the wemac isn't initialized if there is no macaddr set.
rellla has quit [Quit: rellla]
<jas-hacks>
Any plans to get uboot to read mac from script.bin?
<hno>
jas-hacks, I assume "mii info" reports nothing until you power it on?
<jas-hacks>
hno: I tried mii info, only after power up.
<hno>
jas-hacks, there is no plans for script.bin support in this u-boot. There will be devicetree support at some point however.
<jas-hacks>
hno, so we will have netconsole at some stage?
<hno>
jas-hacks, regarding macaddr: <hno> Which reminds me... should change wemac kernel driver to check if there is a MAC in the registers already and use that instead of random.
gimli has quit [Quit: Verlassend]
<hno>
netconsole probably works already if enabled.
<jas-hacks>
hno: great
<jas-hacks>
hno: with this uboot can I set gpio and mac+ipaddr as command line options? Or won't they be set in the correct sequence.
<mnemoc>
we need per-board dram info, adding a couple of lines for wemac/phy in the same board file shouldn't be a problem
<mnemoc>
mac/ip is another story.... uEnv.txt?
slash_random has quit [Ping timeout: 240 seconds]
<mnemoc>
we can receive the mac via kernel command line, so it might be good to have it up there and pass it along
<mnemoc>
isn't the ip command line argument only used for kernel-side nfs rootfs?
<mnemoc>
bbl
<jas-hacks>
I thought uboot would read mac/ip from some file?? and pass to the kernel.
<mnemoc>
uboot knows to read files, uEnv.txt and boot.scr
<mnemoc>
the mele gets it written on the u-boot env partition directly, on each device
<mnemoc>
but I doubt the hackberry comes with it's own mac
<mnemoc>
we only need to keep it fixed
<mnemoc>
afaik there is no command line argument to pass the ip to the kernel, except for some nfs related voodoo
<mnemoc>
so it would be up to the userspace to extract it from /proc/cmdline
<mnemoc>
which doesn't sound reliable at all
<mnemoc>
but passing mac_addr= sounds fair
<mnemoc>
or sunxi-wemac.mac_addr if we make the driver upstreamable
<jas-hacks>
The mac we can read for uEnv.txt/boot.scr. hno suggestion was to change wemac to detect if it had already been set by uboot.
<mnemoc>
why not passing it?
<mnemoc>
sounds less hackish
cat_x301 has quit [Ping timeout: 276 seconds]
<jas-hacks>
because its already been is set in the wemac registers by uboot.
<mnemoc>
can we distinguish it from garbage?
<jas-hacks>
good point, not sure, would have to look at the code.
jas-hacks has left #arm-netbook [#arm-netbook]
<mnemoc>
the driver just writes on the registry. it would be interesting to know what is the value before. zero or garbage
<mnemoc>
meh
<mnemoc>
he left :<
<mnemoc>
i have the feeling it comes with a random value, will test
<hno>
mnemoc, I would think default is zero.
<mnemoc>
we actually write zero if mac_addr= or dynamic.MAC is zero
<Marex>
slapin_: somrthing
<Marex>
*something
<mnemoc>
i mean, not defined
<hno>
mnemoc, passing it in the command line also works obviously. It's available to bootscripts as $macaddr
<mnemoc>
but where does it come from?
<hno>
and probably that's what we have to do. I don't think the MAC gets configured in the registers until wemac is actually used.
<hno>
Comes from u-boot environment
<mnemoc>
hno: you are right, it comes zeroed
<mnemoc>
currently mac_addr wins over script.bin
<mnemoc>
should u-boot win against both?
<mnemoc>
or mac_addr > u-boot > script.bin ?
Sternennebel has quit [Quit: Leaving.]
slash_random has joined #arm-netbook
<mnemoc>
i.e. only using script.bin's value if it hasn't been initialized already. but always honoring mac_addr= param
<Marex>
slapin_: not really ... I had quite a lot of fun on the ELCE here in Barcelona
<slapin_>
good night, all!
RITRedbeard has quit [Read error: No route to host]
RITRedbeard has joined #arm-netbook
<hno>
mnemoc, <hno> mnemoc, passing it in the command line also works obviously. It's available to bootscripts as $macaddr, and probably that's what we have to do. I don't think the MAC gets configured in the registers until wemac is actually used.
<mnemoc>
it gets configured right after the nand driver and before usb :p
<mnemoc>
at least my debugging printk()s are there
<mnemoc>
i still don't see what you are trying to tell me, but I'm quite ill and brain not working at all. good night. I'll reread it tomorrow and alter the driver accordingly
<hno>
slapin_, nice.
<hno>
mnemoc, I am telling you that in most cases u-boot won't configure the wemac MAC even if a MAC address is configured in u-boot. So pointless to try to read it from the registers.
<hno>
and trivial to pass it to kernel in kernel command line. No need to spend any brain cycles on this.