<oliv3r>
ssvb: ahh, sorry for the confusion. Rudy claims he needs that fix or it won't even start
<ssvb>
hramrach__: if the duplex mode settings are fubared, then the transmission in one of the directions is going to be ridiculously poor (Kbit instead of Mbit speed)
tinti has joined #linux-sunxi
PiyushVerma has quit [Remote host closed the connection]
<hramrach__>
that should be noticable enough
PiyushVerma has joined #linux-sunxi
<oliv3r>
how is performance when forcing 100mbit half duplex?
<rellla>
i wonder what's rudi's fix for the blueish color? maybe only the "restart" workaround ...?
<oliv3r>
if i'm not mistaken, that's an 'allowed' usecase?
<oliv3r>
well they have pre-compiled geexbox images in their downloads snapshot area
<oliv3r>
rellla: mind you, his xbmc build is ontop of yours
<hramrach__>
well, I have some old irq patch to reduce system latency from wingrime but not phy patch
<hramrach__>
no, that was on the previous kernel
<ssvb>
hramrach__: please try the latest stage kernel and get the iperf numbers (the instructions for iperf benchmarking are provided in the mailing list)
<oliv3r>
always puts a sad smile on my face, if things aren't colleboratly solved, so there's appearantly a fix, sort of, and we don't even know it :(
<oliv3r>
while it's an ugly ugly hack
<oliv3r>
if it helps, its better then restarting
<ssvb>
hramrach__: in theory, it should perform better, in practice we need to confirm how it works on different devices
<hramrach__>
I did a merge of hansg 3.4 sun7i patches so I don't have the sources I used to build this kernel
<ssvb>
oliv3r: yes, it looks like a hack, which kinda simulates xmbc restart to get the desired effect :)
<ssvb>
rellla: thanks for the nice link
<hramrach__>
ssvb: the wait 5 secs patch is in sunxi already or needs to be added on top?
<ssvb>
hramrach__: it needs to be applied separately
PiyushVerma has quit [Quit: Konversation terminated!]
<hramrach__>
ssvb: is there some way to download a patch from gmane?
* lioka
.oO sure. X o in your gnus
<oliv3r>
what is nande for on cubie2?
<oliv3r>
when i try to mount it, it crashes pretty hard
<Turl>
oliv3r: thanks, but I'd say keep them, they'd probably arrive in 2 months' time or get lost in the mail :p
<oliv3r>
i'd be happy to part with them, i'm keeping the 2GB ones myself :p
<oliv3r>
i have about 15 uSD cards :)
<oliv3r>
18 if i'd keep them :p
<mripard>
Turl: that looks right
<Turl>
mripard: I always have a hard time dealing with before/after comparisons :)
vinifr has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
arokux2 has joined #linux-sunxi
<arokux2>
hno: hey, as far as I remeber you have also bought a Mele A1000. does it ethernet works with u-boot-sunxi/sunxi-current (or sunxi)? for me even port leds are not blinking. i've heard there is a gpio pin to be set, so that ethernet get power at all. can you comment on this? thanks!
<oliv3r>
arokux2: nofi but what has that to do specifically with hno?
<oliv3r>
the ethernet gpio pin might actually asked best at ssvb as he recently spent most time on it :)
<oliv3r>
in any case, u-boot-sunxi does not use the 'fex' file, so doens't care about the gpio setting of it either
<oliv3r>
afaik u-boot-current should work normally with ethernet
<arokux2>
hno was there from the very beginning, and I know he has a1000
<arokux2>
oliv3r, not with a1000, maybe because it needs this pin set.
<arokux2>
oliv3r, yes, these devs does need a pin to be set.
<oliv3r>
lets ask the one and only true source what it thinks :)
<arokux2>
ssvb? :)
<oliv3r>
github
<Turl>
oliv3r: it's a true fact that some boards need a pin configured to power the phy, I dunno if uboot is doing it though
<vinifr>
hi, is already possible to start the mainline kernel with sunxi board?
<oliv3r>
Turl: i'm checking it right now, i would assume there's a CONFIG for it or somesuch
<rellla>
ssvb, oliv3r: i think i get nearer, where the blue issue is coming from. vidonme-port has additional A10VLInit and A10VLExit, where the DISP-iotcl's are called.
<oliv3r>
what i'm even more supprised about is, that irssi lets me do that, normally if you paste more then 4 lines it gives you the 'ctrl-k to continue, ctrl-c to cancle'
<oliv3r>
which I did get after that blurb
<libv>
yeah, i was assuming that you weren't using irssi
<oliv3r>
i selected a line from github, and i guess github now has some feature that when you select slightly more to the left then the line, it selects the entire file or something
<Turl>
oliv3r: get a proper irc client that auto-holds you from doing that :p
<oliv3r>
Turl: like irssi?
<oliv3r>
15:03 < oliv3r> u32 mac_mcmd;I/* 0x80 */
<oliv3r>
15:03 -!- Irssi: Pasting 47 lines to #linux-sunxi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
<Turl>
oliv3r: ya :P
<Turl>
if you still read 47 and pressed ctrl+k.. :P
<oliv3r>
I did not press ctrl+k :p
<Turl>
oliv3r: it doesn't send unless you do :p
<oliv3r>
but what if there's a ctrl-p in the source mebedded!
<oliv3r>
i'm telling you, github spam IRC mode is what thi sis
<Turl>
excuses :p
<libv>
Turl: smells like an irssi bug, something to do with either the size or some character within this data
<Turl>
libv: irssi bug? blasphemy!
<arokux2>
oliv3r, are you sure about 17 here -- > sunxi_gpio_set_cfgpin(SUNXI_GPH(17, 1));
<mripard>
if you want the details on how clk_get works in such a case
<blunden>
oliv3r: you mean the guy who posted Samsung's proprietary exFAT driver on github and changed the license from "Samsung Proprietary" to GPL before doing so?
<oliv3r>
blunden: that's the one
<oliv3r>
but he claims it was gpl before samsung relicensed it
<oliv3r>
but yeah, nasty business
<blunden>
oliv3r: he doesn't have any proof of that. the changelog just refers to changing the license to proprietary
<blunden>
it says nothing about GPL
<oliv3r>
nobody has any proof at this moment
<oliv3r>
only samsung knows the truth
<blunden>
except that he changed the license in the files before uploading it
<blunden>
since we have an identical version of the driver committed 5 months earlier to another repo but with the license intact
<blunden>
and the link to the source code was removed from XDA after what was probably a a request from samsung
<blunden>
at least he didn't steal the code :)
<oliv3r>
:)
<blunden>
and samsung has a history of mistakenly releasing the source code for their proprietary software by mistake
vinifr has quit [Quit: Saindo]
<arokux2>
oliv3r, so what do you think about that table? specifically:is it for a particular board or for A10 in general?
<blunden>
- by mistake
<oliv3r>
arokux2: table should be very correct
<blunden>
oliv3r: what were you going to ask him anyway?
<libv>
pirea: have you seen the licensing terms for that one?
<pirea>
nope
<oliv3r>
blunden: oh we have someone here called rz2k which looks very similar is all
<libv>
pirea: high time that you do
<arokux2>
oliv3r, ah, I see now. it doesn't include mux 0 and 1, now it makes sense.
<oliv3r>
arokux2: yep :)
<libv>
our "own" binaries did not come with any licensing terms, which makes them pretty grey legally, and it makes us distributing those questionable, but not liable
<libv>
the odroid binaries do come with licensing terms which explicitely prohibit redistribution or repackaging
atiti__ has joined #linux-sunxi
<blunden>
libv: any idea why they have such a prohibitive license or why you can't get the same libs from allwinner with a more compatible license?
<libv>
blunden: someone built those binaries for us, he is not (or no longer) working for allwinner, but has become a device maker in the meantime
<libv>
he is chinese, so there is little that allwinner or arm can do against him, nor, i think, would they _really_ want to
<arokux2>
oliv3r, just curious, how many pins (balls) does A10 has in total? (approximately)
<blunden>
libv: but he no longer has access to the source code after leaving allwinner?
<libv>
the reason for the prohibitive license on the odroid binaries is that same reason why it took hardkernel 8 months to be given permission to build and distribute binaries for some debian versions
<WarheadsSE>
^ samsung= PITA
<libv>
samsung and arm were playing legal pinball, and when they agreed, they summed up the most prohibitive set of restrictions between them
<rz2k>
blunden: oliv3r: whats happening?
<libv>
blunden: i have no idea about the availability of newer driver code to this person
<libv>
blunden: but that simply does not matter
<libv>
i would have to go and find out for real, but i think our r3p0 might just as well use the full power of the mali400mp2 on the a20
<libv>
all you need to do is build an r3p0 kernel driver for it
<oliv3r>
arokux2: should be in the datasheet
<oliv3r>
rz2k: your name sounds like someone on github who's been relicencing propriatary code as GPL :)
<libv>
plus, our r3p0 binaries have been fixed
<libv>
i am not sure whether odroid is carrying my fixes or recommendations yet
<rz2k>
what?
<libv>
well, fix or recommendation
<libv>
no plural there
<blunden>
rz2k: your nick was close enough to the exfat-nofuse guy
<rz2k>
lol, that wasnt me
<oliv3r>
rz2k: how's mtd comming along?
<blunden>
rz2k: yeah, we figured that :)
<rz2k>
oliv3r: have different priorities right now, sorry
<rz2k>
too much $job
<rz2k>
have no free time for that :(
<rz2k>
but I proved it working and booting linaro from ubifs
<arokux2>
oliv3r, it says "TFBGA441 package", with BGA standing for Ball Grid Array. but the rest I cannot explain
<WarheadsSE>
I really need to find time to attempt to re-assmble part of my office so I can get bak to dev'ing .. farking annoying.
atiti__ has quit [Ping timeout: 240 seconds]
<arokux2>
oliv3r, 441 stands for the number of pins :)
<hno>
yes I do have an A1000, and it does require a gpio pin to be turned on for powering the ethernet PHY. I do not think u-boot does this automatically but can be done with the gpio command.
<hno>
pin number is shown in the board fex file.
<hno>
arokux2 ^^
<arokux2>
hno, thanks a lot. "gpio command" you mean in sources or on command line?
<hipboi>
rellla, they told me a guy is following this
<hipboi>
rellla, but now further news
* hramrach__
emerges with a hatchet dripping #defines
dwilkins has quit [Read error: Connection reset by peer]
dwilkins has joined #linux-sunxi
<hramrach__>
how could anybody ever build that hansg's a20 kernel O.o
nove has joined #linux-sunxi
pirea has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
zeRez_ has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
zeRez_ has quit [Client Quit]
drachensun has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
blunden_ has joined #linux-sunxi
blunden has quit [Ping timeout: 245 seconds]
pirea has quit [Quit: Leaving]
hipboi has quit [Quit: Leaving]
notmart has quit [Quit: notmart terminated!]
mouchon has joined #linux-sunxi
<mouchon>
hi, may be a stupid question, does A20 datasheet exist with registers/memory map information ?
<hramrach__>
it probably does exist. that does not mean AW released it to the public or it is bug-free
<mouchon>
hramhach__: ok so no know public one ;-)
<hramrach__>
mouchon: there is a20 'brief' and pin assigment doc
<hramrach__>
and some sources
<mouchon>
hramhach__: thanks for the info i have seen this one :-). I try find more information to try to help devloppement for A20. But seem that only source of information is the kernel provided by AW
<ssvb>
mouchon: you can also read A10 & A13 manuals, it is not like the hardware changed way too much in A20
<mouchon>
ssvb: can you point me to the source of A10 and A13 manual ?
<provel_>
Hi all.... someone can tell me the steps to have hardware watchdog running? I compiled in kernel and prepared boot.scr
<oliv3r>
ISOLATE: high to isolate the RTL8201CP from the MAC. This will also isolate the MDC/MDIO
<oliv3r>
management interface. In this mode, the power consumption is minimum. This pin can be
<oliv3r>
directly connected to GND or VCC.
<oliv3r>
provel_: it should run by default
<Turl>
provel_: run a watchdog daemon to enable and pet it
<arokux>
oliv3r, I'm sorry for being that ignorant, but you should speak an easier language
<provel_>
Turl: thank you
<oliv3r>
arokux: ok the cubieboard has an RTL8201cp PHY
<oliv3r>
so i assume the melee has it too
<oliv3r>
pin number 43 on the PHY is the 'ISOLATE' pin
<oliv3r>
which is an INPUT type to the PHY
<oliv3r>
you either put 0V (low) or 5V (high) on it
<provel_>
ah, anyone else esperiencing frequent (approx. one every day) freezes with A2000 ?
<oliv3r>
if you put the PHY in 'isolation' mode, the power consumption is minimum
<oliv3r>
provel_: what kernel
<oliv3r>
arokux: you set it to HIGH to isolate the PHY from the SoC, and LOW to let the SoC and the PHY communicate
<arokux>
oliv3r, ok, I'm following so far, found it in the data sheet also
<oliv3r>
so to enable the EMAC -> PHY (via mii) connection, you have to set GPIO on the SoC to OUTPUT and make it 'LOW'
<oliv3r>
the PHY will see that you are 'unisolating' it and thus have an mii connection
<oliv3r>
I'm assuming (hno and ssvb should confirm) that a) that is the pin that is connected to the 'power gpio' and b) this is some power saving method. The PHY can do autonegotiation without being connected to anything. So I assume, the PHY will do an interrupt, to which the SoC enables PH15 and communicates with the PHY
<hno>
arokux2, not sure where it should go, if at all.
<provel_>
hum, Does anyone knows if watchdog can be set to more than 20 seconds?
<hno>
oliv3r, there is no defined u-boot command syntax for setting pull up/down.
<oliv3r>
ah
<oliv3r>
well for internal use only
<arokux>
hno, but is this relevant for mele PHY?
<hno>
np
<hno>
no
<hno>
but it is relevant for what state the pin have when set as input.
<oliv3r>
and we could in theory use that when using buttons interacting with u-boot?
<hno>
?
<arokux>
hno, uboot says it is 1
<oliv3r>
setting a pull up/down
<arokux>
gpio input PH15
<arokux>
gpio: pin PH15 (gpio 239) value is 1
<hno>
oliv3r, yes.
<hno>
arokux, doesn't say much about the pin state really.
<arokux>
hno, ok.
<oliv3r>
hno: how big is your mailbox back read log?
<hno>
only that the current voltage at the pin makes the A10 read it as a 1.
<arokux>
hno, I do not understand how one can read from INPUT pin anyway......
<hno>
oliv3r, no idea.
<oliv3r>
haven't opened your mail yet? :)
<hno>
arokux, what do you mean?
<arokux>
if (sub_cmd == GPIO_INPUT) {
<arokux>
gpio_direction_input(gpio);
<arokux>
value = gpio_get_value(gpio);
<hno>
oliv3r, I have opened it many times during vacation.
<arokux>
hno, pin is set to input and then its value is read...
<hno>
arokux, yes. How is that strange?
<oliv3r>
i would have expected, that you configure the pin as input once; then read it when wanted
<arokux>
hno.. oh, never mind
<hno>
configuring a pin that already is input is still input.
<oliv3r>
won't that cause a big overhead setting those bits etc?
Rachie_85798 has joined #linux-sunxi
<hno>
overhead compared to what?
<Rachie_85798>
Hello, anyone on today?
<hno>
Rachie_85798, many here...
<Rachie_85798>
Ah, good.
<hno>
not everyone saying anything.
<Rachie_85798>
I'm hoping someone might be able to help me troubleshoot LVDS.
<hno>
Rachie_85798, see topic.
<hno>
oliv3r, we are talking about something called from the command line to check pin status here..
<oliv3r>
ah duh of course, sorry
<oliv3r>
too hot to think here
<oliv3r>
27C still here
<arokux>
hno, after power on:
<arokux>
gpio t PH15
<arokux>
gpio: pin PH15 (gpio 239) value is 0
<arokux>
(t - toggle)
<hno>
and even if it was something called rapidly it's 3 PIO operations in total, (read pin setting register, write pin setting register, read pin value register)
<hno>
arokux, yes, as it reads as 1 it toggles to 0..
<arokux>
hno, exactly. now PHY should work, but it does not
<Tartarus>
hno, plans on submitting allwinner support for the next u-boot release? merge window is open now :)
<hno>
Tartarus, always plans, but also need to get things in better shape before resubmission.
tzafrir has quit [Ping timeout: 256 seconds]
<oliv3r>
<output level> sets the initial output level for the port; 0 = low; 1 = high (only valid for outputs)
<Tartarus>
hno, ok
<hno>
yes, initial.
<Tartarus>
basics looked pretty good last I poked
Offshore has quit [Ping timeout: 240 seconds]
<hno>
Tartarus, yes, it's quite realistic to get the basic soc support resumitted.
<Tartarus>
hno, please? :)
<oliv3r>
lots and lots of work still need to be done (cleanup etc)
<arokux>
oliv3r, do you understand how fex script is not wrong?
<hno>
Tartarus, but not sure I will manage to get MMC or SPL support resubmitted in time.
zarei has quit [Ping timeout: 250 seconds]
<Tartarus>
hno, ok
<hno>
arokux, fex gives the initial value of the pin, no the final value.
<Tartarus>
Gotta start somewhere tho
<oliv3r>
arokux: not entirly no, but arokux it could be, that the kernel driver parses it, first sets it to 0 (initial state from fex) and then when needed sets it to 1
<arokux>
yessssss
<oliv3r>
Tartarus: why do you want it submitted to mainline so badly? :)
<arokux>
because: issuing gpio set PH15 WON'T enable phy
<oliv3r>
Tartarus: faik our u-boot tree is in sync iwth mainline
<hno>
arokux & oliv3r, the same code is in stage 3.4
<arokux>
only doing gpio clear PH15; gpio set PH15
<arokux>
will enable phy
<Tartarus>
oliv3r, why do you want to maintain a sub-tree? :)
<Tartarus>
I want to get the code upstream
<oliv3r>
Tartarus: nono, it's good what you want, but I think it should be reasonable quality to go with it :)
<hno>
Tartarus, we don't want to.
<hno>
maintain a sub-tree that is.
<Tartarus>
I'm happy to help where I can, too
<arokux>
hno why is kernel interested in the settings, it could read them off, if needed.
<hno>
arokux, read them off from where?
<hno>
the fex setting is the default when the gpio pin is configured, not the power-on default.
<arokux>
that is configured by uboot, for example
<Turl>
back
<oliv3r>
afaik u-boot doesn't parse the fex file and sets all pins to initial states from there?
<hno>
arokux, it's not configured by u-boot.
<Turl>
mripard: still playing borderlands? :)
<mripard>
Turl: yes :)
Soru has joined #linux-sunxi
<arokux>
hno, it is not power on default, it is configured, but before the kernel starts. who if not u-boot could do it?
<oliv3r>
in a richard stalman shaming way!
<hno>
arokux, the pin is configured with default setting when the kernel starts, and set to 1 when the emac is activated.
<hno>
there is nothing magic going on before kernel starts.
<arokux>
hno, so the fex script is for the kernel, so it sets defaults?!
<mripard>
oliv3r: richard stallman couldn't use his wifi.
<hno>
arokux, yes, when the emac driver requests the pin as a gpio pin.
<Turl>
oliv3r: they stole his computer over here, I wonder if he got another
<oliv3r>
mripard: he didn't have atheros
<arokux>
hno, and that is why gpio CLEAR ph15 is needed before gpio SET ph15
<oliv3r>
Turl: good question, he should get get an A10 based one
<arokux>
the first being what fex requires actually?
<hno>
arokux,default is set by wemac_probe. And then set to 1 by wemac_initi_wemac.
<Turl>
oliv3r: but mali and cedarx! :)
<oliv3r>
Turl: rms doesn't need mali nor cedarx :p
<hno>
arokux, I can't explain why you need to clear before set.
<oliv3r>
and cedarx -> cederus; mali -> lima
<arokux>
hno, why that? the kernel also does this!
<libv>
something with pvr should suit him best, seeing as pvr was the fsf priority project for ages, even with lima being worked on
<oliv3r>
maybe ensure the hardware is always in an off state, just in case; or hardware needs to be in a certain state initialized? hard to say
<arokux>
hno, in probe it will clear it (as given by fex) in init it will turn it on
<oliv3r>
it might not even be needed whatseover, maybe it actually slows things down
<oliv3r>
libv: lol; i wonder who decided for the PVR
<oliv3r>
is it still a prio project?
<oliv3r>
arokux: don't you mean, in probe it sets it to whatever fex file has?
<hno>
oliv3r, as far as I know it should be controlling a MOS transistor that controls the power to the PHY. It's either ON or OFF.
<libv>
me, and the pvr, have successfully managed to keep people away from it :)
<oliv3r>
arokux: remember, fex files are created by random monkeys on keyboards :p
<arokux>
oliv3r, yes, this is what I mean
<oliv3r>
hno: I would think, the default should be 1; have the PHY on asap so it can start auto negotiation asap
<oliv3r>
but I can think of 1 reason you might not want that
<oliv3r>
it probably also triggers an interrupt when done auto-neg, and the kernel might not be ready to respond to it
<hno>
oliv3r, on a mele I would agree. Maybe not on a tablet..
<hno>
not even sure there needs to be a phy power control on the mele tv box.
<hno>
but there is one.
<oliv3r>
well by disabling it, you could hide certain GUI bits showing stuff
<oliv3r>
i'm thinking 'cable is unplugged' messages from network manager or the like
<oliv3r>
then again, the MAC will still trigger that ... nvm then
<arokux>
hno, does it makes sense what I've said?
<hno>
arokux, what?
<arokux>
hno, fex says it should be set to 0, the kernel does it in probe. and this is what i do with clear. then the kernel turns it on, and in my case i do set
<arokux>
this would explain why i need clear before set
<oliv3r>
it seems to me, that there is potentially a hardware reason that you want it off atfirst; either that, or prevent IRQ's being missed/ignored
<hno>
that is what happens, but does not exaplain why you need to clear.
<oliv3r>
arokux: if you power on, and only do gpio set ph15
<oliv3r>
does it not work?
<arokux>
oliv3r, no, it does not
<oliv3r>
then it's a hardware reason
<oliv3r>
possibly specific to the mele
<arokux>
hno, and if kernel will only SET, then it won't (shouldn't) work too...
<oliv3r>
cubie 'works' without that
<arokux>
oliv3r, can you actually switch phy off on cubie?
* hno
needs to find a paperclip to force fel mode on his a1000... should solder a jumper there I think.
<oliv3r>
arokux: i don't think you can
<oliv3r>
but mine is broken :(
<arokux>
oliv3r, what happened?
<techn_>
hno: old amd turon trick was pencil :)
<hno>
arokux, cubieboard schematics have a mos transistor for power control, but was removed in final product. PHY is always powered on cubieboard.
<hno>
techn_, not sure how to do the trick with a pencil on a unsolderd 2.54mm jumper..
<oliv3r>
its strange though that you don't have to reset the PHY or something wtih the cubie; but with the melee you do have to power cycle the PHY
<oliv3r>
i wonder if the RESET pin is connected on the mele
<oliv3r>
hno: for some reason; the wemac rename patch left sunxi_wemac in place
<oliv3r>
pretty sure git mv should have deleted it thoug
<hno>
git mv deletes the old one..
<oliv3r>
yeah but sunxi-current has both files
<hno>
it does?
<hno>
That's most likely my fautl. wemac got merged mainline.
<hno>
so had to redo the rename.
<oliv3r>
ah
<oliv3r>
ok
<oliv3r>
patch wouldn't apply at all?
<hno>
git pull don't understand...
<oliv3r>
:S
<libv>
apparently aaron seigo claimed that the first spin of the vivaldi tablet has arrived for testing
<oliv3r>
wasn't that an eoma68 based tablet?
<libv>
if things haven't changed again, yes
<oliv3r>
interesting
<oliv3r>
i still like the concept
<hno>
arokux, looks like my mele powers the phy at power on. but need to verify.
<arokux>
hno, with u-boot/current?!
<hno>
arokux, phy looks powered before anything is loaded at all.
<oliv3r>
so by doing clear/set; you force a reset
<oliv3r>
i suppose this pin toggling, should go into a/the PHY driver
<arokux>
hno.. hm, how can I not load smth?
<oliv3r>
since you can configure reset, isolation, power, autoneg/10/100, duplex all via pins besdies mii
<oliv3r>
arokux: 'load'?
<arokux>
oliv3r, hno says phy is powered before uboot starts. i'm asking how can i not load u-boot
<arokux>
because if sd card is not there it will boot android
<hno>
arokux, by forcing fel mode.
<arokux>
hno, also, if it were powered from the very beginning where and what turned it off?
<hno>
Hmm... why is there no EMAC at all in this u-boot...
<arokux>
hno, drivers/net/sunxi_emac.c
<hno>
It's built.
<hno>
Never mind. It's just me not reading what's on the screen.
<oliv3r>
silly hno
<arokux>
ok, any idea why the power goes off?
<oliv3r>
maybe the power doesn't go off
<oliv3r>
maybe the chip is in an undifined state and needs to be reset
<oliv3r>
take a multimeter and probe the power pins to be 100% sure :)
<oliv3r>
i don't have a mele so can't test :(
<hno>
let me connect some network to this switch...
<arokux>
hno, saying that phy is powered before u-boot, have you seen leds blinking on the port?
<hno>
leds are on.
<hno>
and turns off if I set the gpio pin to 0.
<hno>
but likely not reliable if there is no pullup and the pin is set as input (power on default)
<arokux>
hno, you can set pin to 0 in FEL mode?!
<oliv3r>
arokux: of course, but takes some work to do
<hno>
arokux, I booted u-boot via FEL.
<hno>
arokux, but yes, it's also possible to set GPIO pins via FEL. See sunxi-tools.
<arokux>
hno, and after booting uboot via FEL the LEDS were ON?
<hno>
arokux, yes.
<arokux>
hno, I see.
<arokux>
hno, and uboot is the from the current branch?
<hno>
arokux, but as I said above, if there is no external pullup resistor then pin state is not reliable until the gpio pin is configured.
<arokux>
hno, ok.. but i still fail to understand why clear is needed before set?
<oliv3r>
arokux: don't think of it clear before set; think of it more 'poweroff PHY, power on PHY'
<oliv3r>
which smells like 'reset'
<oliv3r>
with the addition that you are able to turn it off to save power :)
<arokux>
oliv3r, ok. I will suggest to reset it as soon as possible in uboot (for mele) and have it running
<oliv3r>
yeah so far it's mele specific
Rachie_85798 has quit [Quit: Page closed]
<hno>
host 192.168.1.2 is alive
<hno>
without setting ph15 at all.
<hno>
on mine.
<arokux>
and without going through FEL?
<hno>
I don't have a free SD card to test with right now.
<hno>
or.. maybe I do. I do have a uSD adapter here..
<arokux>
I could test FEL on mine, if you tell me how to do it and how to boot u-boot afterwards...
<hno>
it's a bit of a mess to FEL boot a1000. You need a) A USB cable that fits the internal non-standard header. b) short a unsoldered jumper at poweron/reset.
shineworld has quit [Remote host closed the connection]
<arokux>
ok, so would be cool if you could test it with sd card.
<hno>
but it's very stange you need to power off yours first.
<arokux>
hno, meaning inside of sunxi_emac_initialize ?
<hno>
arokux, no, board_eth_init().
<hno>
see comment.
<hno>
but you could just as well do it with the gpio command, so not sure why spend time on doing it in code.
<arokux>
hno, tested it again. gpio set PH15 -- no reaction
<arokux>
hno, I could use it as a command, but can add patch easily, if you like
<hno>
arokux, same result booting from SD.
<arokux>
maybe the problem is with my serial2usb converter?
<arokux>
if i plug off the power and the converter is still connected to the device, then the leds of the device and phy are still on
<arokux>
the converter supplies the power.
<hno>
yes, having uard cable connected without power makes a bit of madness on most allwinner devices.
<arokux>
indeed!!!!
<arokux>
fuck
<hno>
have seen axp chips hang, and would not be supriced if it could also make phy chips in odd state.
<hno>
you can fix it with a diode on the RX wire.
<arokux>
without converter phy is powered!!!
<hno>
(RX from the A1000 point of view)
<arokux>
ok... but now i'm leaving to bed
<arokux>
thanks to all, especially to you hno!
<arokux>
hno, last remark, plugging converter i can see phy leds flushing once
<arokux>
good night
<hno>
arokux, add a schottky diode on the TX wire of your serial cable (RX pin on the Mele), blocking any current from entering the board. This protects you from oddness caused by the UARD cable.
<hno>
or make sure to connect UART cable after powering on the board.
<arokux>
hno, are there converters with diodes? :)
<hno>
don't know. But it's a very easy modification.
<arokux>
i do not have diode
<arokux>
and tools
<arokux>
ok, i'll go with second option
<arokux>
hno, you are electrical engineer?
<hno>
no, I am a programmer.
<hno>
but I do own a broken soldering iron.
<hno>
correction, broken soldering pen. It's not even an iron..
<arokux>
hno, in which book on programming have you learned about "high impedance input"? :P
<hno>
the life one..
<hno>
have not read that many books on programming.
<hno>
but been programming computers for more than 30 years.
<arokux>
ok :) good night!
<hno>
fact: Computers are not digital.
rings_IIV has joined #linux-sunxi
rings_VII has quit [Ping timeout: 240 seconds]
tinti_ has joined #linux-sunxi
arokux has quit [*.net *.split]
drachensun has quit [*.net *.split]
ojn has quit [*.net *.split]
arokux has joined #linux-sunxi
drachensun has joined #linux-sunxi
arokux has quit [Remote host closed the connection]
Dreadlish has quit [Read error: Connection reset by peer]
hramrach__ has quit [Ping timeout: 240 seconds]
yuuki has quit [Ping timeout: 256 seconds]
yuuki has joined #linux-sunxi
<Turl>
hno: that's why we have virtual machines :)
Dreadlish has joined #linux-sunxi
hramrach__ has joined #linux-sunxi
BJfreeman has quit [Read error: Connection reset by peer]