mnemoc changed the topic of #arm-netbook to: EOMA: Embedded Open Modular Architecture - Don't ask to ask. Just ask! - http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 - ML arm-netbook@lists.phcomp.co.uk - Logs http://ibot.rikers.org/%23arm-netbook or http://irclog.whitequark.org/arm-netbook/ - http://rhombus-tech.net/
alcides has joined #arm-netbook
alcides has joined #arm-netbook
alcides has quit [Changing host]
alcides has quit [Quit: Fighter by day, lover by night, drunkard by choice! Ready to fight!]
drachensun has quit [Read error: Connection reset by peer]
tekzilla has quit [Read error: Operation timed out]
tekzilla has joined #arm-netbook
drachensun has joined #arm-netbook
t0dbld|work has joined #arm-netbook
t0dbld|work has quit [Ping timeout: 240 seconds]
ZaEarl has quit [Read error: Connection reset by peer]
ZaEarl has joined #arm-netbook
ssvb has quit [Remote host closed the connection]
gimli has joined #arm-netbook
ZaEarl has quit [Quit: Ex-Chat]
ZaEarl has joined #arm-netbook
ZaEarl has quit [Read error: Connection reset by peer]
t0dbld has joined #arm-netbook
gimli has quit [Quit: Verlassend]
<lundman> ah
rellla has joined #arm-netbook
L84Supper has quit [Ping timeout: 248 seconds]
L84Supper has joined #arm-netbook
sspiff has joined #arm-netbook
mSquare has joined #arm-netbook
<mnemoc> what? 1GB??
tzafrir_laptop has quit [Ping timeout: 255 seconds]
<RaYmAn> thats cool, although a tad expensive
<mnemoc> and a "recover" button under the SD...
<mnemoc> those remopes are heavily overpriced
<mnemoc> remotes*
<mnemoc> aha!, tom has the white variant on his shop
<RaYmAn> nice
arete74 has joined #arm-netbook
<RaYmAn> we really need to convince someone to push for CEC access :P would mostly make those remotes useless
<mnemoc> which is bad for business :p
<RaYmAn> :(
<hno> RaYmAn, most devices are wired for CEC access, but the only known documentation is which pin CEC connects to on the A10, nothing about registers or driver.
plan_b has joined #arm-netbook
hipboi has joined #arm-netbook
The-Compiler has quit [Remote host closed the connection]
popolon has joined #arm-netbook
The-Compiler has joined #arm-netbook
<Gumboot> steev the iMX expert: Do you know the situation with SATA support on iMX6? How's it wired in?
<RaYmAn> hno: indeed, hence the need for an allwinner customer (ok, I was unclear) to push for it =P
rm has quit [Quit: ZNC - http://znc.sourceforge.net]
mysteryname has joined #arm-netbook
rm has joined #arm-netbook
oliv3r has joined #arm-netbook
plan_b has quit [Ping timeout: 256 seconds]
plan_b_ has joined #arm-netbook
plan_b_ has quit [Quit: plan_b_]
Quarx has joined #arm-netbook
ssvb has joined #arm-netbook
lerc_ has joined #arm-netbook
lerc has quit [Ping timeout: 246 seconds]
pawel5870 has joined #arm-netbook
tzafrir_laptop has joined #arm-netbook
<TomNL> guys, r3p0 and r3p1 are only armhf right?
<TomNL> are these: https://github.com/cnxsoft/a10-bin the lastest armel libs?
<mnemoc> TomNL: yes, but also we don't have real 3d hw acceleration in r3 yet (next_mali branch)
<mnemoc> only with r2p4
<TomNL> ah ok :) thnx I managed to build rootfs..and building xbmc now..just wanted to make sure i use all latest files :)
<mnemoc> hopefully hipboi will get us armhf cedarx libs after the holidays
<TomNL> that would be great for sure :)
<rz2k> ...and fixed r3p0, again >.<
orly_owl has quit [Ping timeout: 245 seconds]
orly_owl has joined #arm-netbook
<mnemoc> rz2k: the missing symbol can't be workarounded with a dummy LD_PRELOAD?
<TomNL> lundman: your wemac kernel fix, is it available somewhere?
<mnemoc> it's in Turl's repo
<mnemoc> git://github.com/allwinner-dev-team/linux-allwinner.git
<lundman> yes github
<mnemoc> it would uber-awesome if you can split it and resubmit :<
<mnemoc> back in 30m
<lundman> thats the one
<TomNL> thnx lundman
<TomNL> let see if i can get it compiled against new kernel
<lundman> i remove "illegal" comments "//" and changed the delay timing
<lundman> ie, just removed the CPU busy loops
<TomNL> ok :) i just finished compiling xbmc
<TomNL> if you want i can compile a 1080p version for you...i saw you asked for this?
<lundman> that is sure to make you exhausted :)
<lundman> yeah been told GPu can not do 1080p, but I must admit I'd be curious to see
<TomNL> hehe i will do it later today, and upload the .deb file somewhere and let you know
<lundman> kelw
<RaYmAn> lundman: that would suck :/ even RPI can do 1080p, albeit at like 80% cpu :P
<lundman> hold on
<lundman> GPU to render 1080p polygons, is not the same as the VPU video processing 1080p, or even 2160p
<RaYmAn> (talking interface, not video decoding, right?)
<lundman> yeah
<RaYmAn> my rpi runs xbmc at 1080p
<lundman> but yes, admitedly, if mali was dual core... :)
<RaYmAn> interface
<lundman> or if we had vpu sources... :)
<RaYmAn> yeah - and CEC documentation would be a nice addition too :P
<jlj> is it possible to force an A10 board to activate usb OTG mode through software?
<lundman> and cash to lundman!"
<jlj> like without using a proper OTG cable (just a normal mini usb cable without the otg)
plan_b has joined #arm-netbook
cat1 has quit [Ping timeout: 252 seconds]
<hno> jlj, yes via /sys files or script.bin changes, assuming you ask forcing to device or host mode, not dynamic OTG.
mSquare has quit [Ping timeout: 240 seconds]
<jlj> hno: I meant forcing it into host mode. Do you know which sys file that controlls it?
plan_b has quit [Quit: plan_b]
<jlj> also do you know if the otg cable has to be plugged in at boot time for host mode to be availible (if using a real otg cable)
<hno> OTG is dynamic, based on voltage level of id pin.
cat1 has joined #arm-netbook
<hno> but many devices have the port forced as host or client.
Almamuetya has joined #arm-netbook
<hno> I don't remember the sys file for runtime override. But I do know you can hardcode the port as either in script.bin.
<jlj> hno: okay, thanks. I'll go see if I can look it up
mSquare has joined #arm-netbook
von_fritz has joined #arm-netbook
sspiff has quit [Remote host closed the connection]
sspiff has joined #arm-netbook
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
<mnemoc> lundman: http://sprunge.us/cKeE?diff <---- did I miss something?
<lundman> looks good, dummy read, use msleep() instead
<mnemoc> lundman: so the original code was correct? beside s/udelay/msleep/
<lundman> only changed I did, was remove the udelay from receive, replace with dummy read from dm9000 sources, then change the other udleys with msleep
pucko has quit [Remote host closed the connection]
pucko has joined #arm-netbook
<mnemoc> lundman: so you are ok if I commit http://sprunge.us/jZBG?diff as fix in your name?
<lundman> yeah please do
<lundman> I thought amery was upstream to us?
<mnemoc> ?
<RaYmAn> github has this neat cherry pick webbased feature - cherry pick from projects forked from you (or they can do pull request of course.)
<lundman> sent upstream pull request to amery at the start, I assumed that was the right thing to do
<mnemoc> lundman: sure
<mnemoc> lundman: problem was mixing code changes and style changes
<mnemoc> i'm splitting it now
<lundman> ah, one would argue "//" comments should not have made it into kernel to start with :)
<mnemoc> lundman: of course that patch is welcomed too
<mnemoc> lundman: just not mixed
<lundman> :)
<mnemoc> it makes harder to what are the real code fixes
<mnemoc> to see*
<lundman> sorry yeah, i did one that was just code changes
<mnemoc> lundman: do you still have it?
<lundman> then some more minor fixes, and started replacing the hard coded numbers with defines
<mnemoc> meh, back in 30m
<Turl> RaYmAn: there's git add interactive iirc, but I could never use it :P
Quarx has quit [Read error: Connection reset by peer]
<RaYmAn> Turl: yeah, that works..sometimes :P
Quarx has joined #arm-netbook
jelly has joined #arm-netbook
<cat1> oh! got wireless somewhat working with mainline rtlwifi driver. Though some hiccups are still happening, like this ones:
<cat1> 64 bytes from 192.168.1.1: icmp_req=79 ttl=64 time=2169 ms
<cat1> From 192.168.1.10 icmp_seq=203 Destination Host Unreachable
<cat1> 64 bytes from 192.168.1.1: icmp_req=80 ttl=64 time=1170 ms
<cat1> From 192.168.1.10 icmp_seq=202 Destination Host Unreachable
<cat1> in other words connection is not stable..
cat1 is now known as cat_x301_away
<mnemoc> 3.4 or 3.6?
<cat_x301_away> now for 3.6, but same should be true for 3.4. will check when come back.
<mnemoc> how did you solve the fw problem?
<cat_x301_away> in a very dirty way :) now really have to run!
<Turl> what fw problem? :O
<Turl> I ran that driver some time ago, didn't have any issues I noticed
<mnemoc> in 3.6 the available firmware isn't accepted
<cat_x301_away> mnemoc: http://sprunge.us/UFTD
cat_x301_away is now known as cat_x301_really_
<Turl> ah, I ran it on 3.0
cat_x301_really_ is now known as cat_x301_away
<mnemoc> cat_x301_away: o_O
<mnemoc> lundman: any idea why they commented out wemac_get_eeprom/wemac_set_eeprom ?
<lundman> yeah it doesnt work, like, at all
<mnemoc> :D
<lundman> basically, it uses byte access to read/write, but has to all be 32bit
<lundman> there is code that reads mac address elsewhere, so the source can probably be figured out
<mnemoc> but there is an "eeprom" we can eventually use, right?
<mnemoc> (a block of reserved persistant memory)
<lundman> hmm that is a good question.. we never found any docs for the wemac
<mnemoc> :)
<lundman> its sufficiently stripped down it might not have it, since it uses scripts
lerc_ has quit [Ping timeout: 252 seconds]
lerc has joined #arm-netbook
<TomNL> is there any good and simple file transfer site left?
<mnemoc> TomNL: http://filetea.me
ssvb has quit [Quit: Leaving]
<mnemoc> TomNL: it's secure, anon and non-storing
<TomNL> hehe cool, so when i close browser it's gone?
<mnemoc> yes
<TomNL> thnx
<mnemoc> yw
<hno> mnemoc, there is no MAC eeprom in the A10.
<mnemoc> so that dead code can safely be removed
<hno> the only programmable bits in the A10 is the security id bits.
<hno> (one time fuses)
<hno> Not entirely sure where mele etc stores the MAC.
<mnemoc> I bet it's together with boot0/boot1
<hno> don't think so.
<hno> maybe in the u-boot environment? Have never actually looked at what they do there.
<mnemoc> so nandb?
<mnemoc> uhm...
<hno> do you have access to yours? If so boot nand u-boot and issue "printenv"
<mnemoc> yes, give me some minutes to connect the stuff
<hno> Did Tom get any MACs for Cubieboard?
<mnemoc> i doubt it
<mnemoc> hno: yes, it's there
<mnemoc> mac=00:CE:39:B6:63:F8
<mnemoc> nand_root=/dev/nandd
<mnemoc> setargs=setenv bootargs console=${console} root=${nand_root} init=${init} loglevel=${loglevel} mac_addr=${mac}
<mnemoc> mmc_root=/dev/mmcblk0p7
<hno> That pretty much explains why there is an UART header mounted.
<mnemoc> to manually modify the env of each unit?
<hno> to modify the env during production yes.
<hno> doubt they do it manually.
<hno> but maybe they do.
<hno> someone is manually putting the MAC sticker there.
ssvb has joined #arm-netbook
jlj has quit [Ping timeout: 244 seconds]
alcides has joined #arm-netbook
alcides has joined #arm-netbook
alcides has quit [Changing host]
mikey_w has quit [Remote host closed the connection]
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
mysteryname has quit [Ping timeout: 256 seconds]
<steev> Gumboot: how is it wired on? schematics are available
mikey_w has quit [Remote host closed the connection]
n6pfk has quit [Remote host closed the connection]
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
n6pfk has quit [Remote host closed the connection]
mikey_w has quit [Read error: Connection reset by peer]
<mnemoc> lundman: 3 months late, but merged :)
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
<mnemoc> TomNL: btw, filetea.me means "cut me in steaks" in spanish... and the author/owner is from spain :p
<mnemoc> not sure what was his original intention for the domain
<drachensun> dont post any files with your home address I guess, unless your in to that kind of thing
<TomNL> hehe no worries ;-)
<jelly> mnemoc: filing tea _was_ weird
<mnemoc> :)
<mnemoc> it's pretty clear the domain wasn't bought for sharing files
<mnemoc> the most gory part is that the author/owner is from my town
<mnemoc> but i really like it for sharing files
<oliv3r> the A10 SPL, is it opensource? or a binary blob from allwinner?
<oliv3r> (I am browsing the SPL subdir on hno's allwinner tree)
<mnemoc> oliv3r: there is one open and one closed
<oliv3r> uboot-allwiner tree*
<mnemoc> uboot's is open
<oliv3r> but uboot requires SPL to chainloot it?
<mnemoc> from NAND they use boot0/boot1 for that
<mnemoc> which are closed
<oliv3r> oh :(
<mnemoc> from mmc we use u-boot's spl
<mnemoc> from hno's
<oliv3r> Ah, u-boot offers SPL, nice
<oliv3r> so why is boot0 and boot1 closed? And why can't SPL work from nand? (I have no technical background in this, just am curious)
<mnemoc> eventually one day we will get rid of boot0/boot1
<mnemoc> boot0/boot1 are closed because allwinner decided so
<oliv3r> duh :p but is there any technical reason to keep those closed? Would u-boot's nand-SPL replace them?
<mnemoc> eventually, it will
<mnemoc> once it matures enough
<oliv3r> So nand-SPL isn't as stable as the regular SPL (both from u-boot)?
<oliv3r> so in an opensource sense, mmc boot is prefered to nand boot?
<mnemoc> it's more about lack of time and documentation
<mnemoc> but yes, if you want to boot free, boot from mmc
<oliv3r> documentation from allwinner? or u-boot? (I assume lack of documentation of allwiner)
<mnemoc> there are other priorities at the moment than integrating sunxi-nand into out main uboot branch
<mnemoc> like proper dram and pmu initialization
<oliv3r> the leaked datasheet going to help with that?
<mnemoc> nope
<mnemoc> it has some info, but it's very incomplete in most areas
TomNL has quit [Quit: I don't like you. But Bersirc 2.2 does. Try it out now. [ http://www.bersirc.org/ - Open Source IRC ]]
<oliv3r> :(
<oliv3r> sad :(
<oliv3r> you'd wonder, who they did it; if their own documentation isn't up to snuff
<mnemoc> letting others do software for their chips is not interesting for their business model
<mnemoc> yet
<oliv3r> yet! :)
<oliv3r> time to go home :) tomorrow i'll try to wikify some more of the datasheet :)
<mnemoc> :)
<mnemoc> lundman: does the first always fail?
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
bsdfox has quit [Read error: Connection reset by peer]
alcides has quit [Ping timeout: 244 seconds]
t0dbld|work has joined #arm-netbook
t0dbld|work has quit [Changing host]
t0dbld|work has joined #arm-netbook
<Turl> mnemoc: what's the cmdline parameter to pass mac address?
jquip has joined #arm-netbook
<mnemoc> mac_addr=
<Turl> thx
<Turl> I was trying macaddr, no wonder it didn't work :)
<Turl> mnemoc: hm with this kernel built into archlinux I can reboot fine and serial doesn't break
<mnemoc> Turl: old uboot :)
<mnemoc> with the world hardcoded
<Turl> mnemoc: but it broke on linux, not uboot
<Turl> I'll try upgrading the kernel later and will let you know if it breaks
<mnemoc> Turl: we are clearly talking about different problems
* hno is using quite different clock settings in later u-boot versions.
Quarx has quit [Read error: Connection reset by peer]
Quarx has joined #arm-netbook
<mnemoc> hno: have you tested `sunxi` in your mele? does it survive reboot?
<mnemoc> i can try later today
L84Supper has quit [Ping timeout: 246 seconds]
L84Supper has joined #arm-netbook
hipboi has quit [Read error: Connection reset by peer]
mikey_w has quit [Remote host closed the connection]
n6pfk has quit [Read error: Connection reset by peer]
<Turl> WarheadsSE: so far so good, arch hasn't exploded my mele yet :P
mikey_w has joined #arm-netbook
<WarheadsSE> well good Turl
<Turl> WarheadsSE: apparently it's using the interactive governor though
<WarheadsSE> by default, that may be
<WarheadsSE> should be simple to change :)
<Turl> which prints a kernel warning every once in a while because some kthread is stuck :|
<Turl> yeah
<WarheadsSE> Thats whats causing that annoyance.
mikey_w has quit [Remote host closed the connection]
n6pfk has joined #arm-netbook
mikey_w has joined #arm-netbook
jquip has quit [Read error: Connection reset by peer]
cat_x301_away is now known as cat_x301
<Turl> WarheadsSE: what's 'the arch way' to handle kernels?
<Turl> (is there any?)
n6pfk has quit [Remote host closed the connection]
mikey_w has quit [Remote host closed the connection]
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
<WarheadsSE> Turl: simply put, see the github for the package.
<WarheadsSE> github.com/archlinuxarm/PKGBUILDs/blob/core/linux-sun4i/config
<WarheadsSE> there is the config file as I have it, I have personally buil 3.0.42, but havent gotten a lot of testing time into it yet
<WarheadsSE> Right now, Ihave it grabbing the tarball @ the commit target, and building from there.
<Turl> WarheadsSE: btw I noticed updating the kernel with pacman doesn't update it, I had to cp it manually to the other partition
<Turl> not sure if that's intended or not
<WarheadsSE> Yeah, it's as simple as an fstab entry
<WarheadsSE> It is semi-intended.
<WarheadsSE> Otherwise we'd have to make a zillion filesystem packages just to cover teh fstab entries.
<Turl> :)
<Turl> I guess I'll just scp my kernel to the first partition and skip arch for now :P
<WarheadsSE> ?
<WarheadsSE> You mean the in-the-repo kernels
<Turl> I can't make much sense of the scripts
<WarheadsSE> Yeah, you can always use your own kernels in the normal way. They just won't be tracked unless you make a package of it.
<Turl> I mean, in debian 'the right way' is using make-kpkg and installing the generated .deb
<Turl> to keep stuff clean
<WarheadsSE> thats the same way with Arch
<WarheadsSE> just makepkg
<WarheadsSE> and pkg.tar.xz
<Turl> hm interesting Last login: Thu Dec 31 18:51:17 2009 from laptop.lan
<Turl> I logged into my mele two years ago :P
* Turl installs ntpd
<WarheadsSE> ;)
<WarheadsSE> ntpd/openntpd
<Turl> $ sudo pacman -S ntpd
<Turl> error: target not found: ntpd
<Turl> $ sudo pacman -S ntpd/openntpd
<Turl> error: database not found: ntpd
<WarheadsSE> ntpd/openntpd .. was meant to be an either or.
<Turl> 'ntpd' doesn't exist apparently :P
<Turl> openntpd installed fine
<WarheadsSE> always have -Ss
<WarheadsSE> and search for what you ae looking for
<WarheadsSE> that might be helpful
<Turl> Warning: OpenNTPD is not currently maintained for Linux (see this thread): users interested in its functions should better use NTPd.
<Turl> hm
<cat_x301> mnemoc: 3.4 crashed when i enabled rtlwifi, look http://sprunge.us/LQSN
<WarheadsSE> ah, Turl ntpd is in the ntp package
<mnemoc> what the...
<Turl> WarheadsSE: does arch automatically set it up on start for me?
<WarheadsSE> You'll have to add it to the start config
<WarheadsSE> systemd or sysvinit ..
<Turl> systemctl enable ntpd.service according to the wiki
<WarheadsSE> ls /etc/rc.d/
<WarheadsSE> if that isnt found, systemd * might be in the image. I can't remember if I uploaded a new one.
<Turl> when I pacman -Syu it asked me if I wanted systemd I think
<WarheadsSE> Then you probably not that far along
<WarheadsSE> I need to clean /update that image
<Turl> how do you run it though?
<Turl> $ systemctl start ntpd
<Turl> Failed to get D-Bus connection: No connection to service manager.
<WarheadsSE> k
<WarheadsSE> /etc/rc.conf
<WarheadsSE> add it to the DAEMONS line after network
<WarheadsSE> The systemd conversion needs to be done on that rootfs
rellla has quit [Quit: rellla]
<hno> the DM9000 register names should not be there. It is not a DM9000 MAC.
<hno> And the specific line looks safe to me. But if you are worried then keep the if(!Rxcount) part.
<mnemoc> hno: the part that bothers me is the removal of the delay in the second try
<Turl> mnemoc: I've been using the patch on my repo for quite a bit on my mele
<Turl> doing heavy networking (torrents, nfs)
<Turl> and it's been fine
<Turl> mnemoc: and I have just built with yours and I can still ssh to it
<mnemoc> "it's good because it didn't crash" :)
<mnemoc> i did that test too
<Turl> mnemoc: you forgot the "and it performs better" bit :P
<mnemoc> :)
<mnemoc> and why do we need a dummy read at all if the second happens only some microseconds later
<mnemoc> i have no clue, but it feels wrong
<traeak> ahh nice, i sold off my rpi (whee!) one thing, at least they haven't lost value (hehe)
<hno> mnemoc, It's not a big deal if RxCount is missed there.
<hno> but a delay is unlikely to help when it is.
<Turl> WarheadsSE: hm, I cannot ping
<Turl> I need to run ping as root
<hno> I think I know what that is about. The second read is not needed either. Instead it should check the rx count ater enabling interrupts again in the if(!Rxcount) block further down.
pawel5870 has quit [Ping timeout: 240 seconds]
<mnemoc> Turl: android kernel on linux?
<Turl> mnemoc: I have paranoid network disabled, so it's not that
<WarheadsSE> might be something in the setopts turl
<Turl> apparently getcap should show some stuff
<hno> mnemoc, there is race window between reading the rx count register and enabling interrupts.
<Turl> but all I get is 'Failed to get capabilities of file `/usr/bin/ping' (Operation not supported)'
<mnemoc> hno: :(
<hno> mnemoc, why so sad?
<WarheadsSE> Turl: looks like an upstream issue :p
<hno> code is easy to follow.
<t0dbld|work> Turl broke it ...
<hno> Rxcount = readl(db->emac_vbase + EMAC_RX_FBC_REG);
<mnemoc> hno: haven't looked at it yet. only the diff
<WarheadsSE> Hmm.. looks like maybe caps arent set on the fs you as using/
<mnemoc> hno: no EINTR in this world?
<Turl> I followed the alarm instructions WarheadsSE
<hno> and then if(!Rxcount){ [..] writel(reg_val, db->emac_vbase + EMAC_INT_CTL_REG);
<mnemoc> hno: meh, ignore that
<WarheadsSE> Turl: I'll check my config
<Turl> /dev/root on / type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
<Turl> might be my kernel config though, do I need anything special?
<Turl> I reused my old mele-as-server config
<hno> mnemoc, and in wemac_interrupt, writel(0, db->emac_vbase + EMAC_INT_CTL_REG); /* Disable all interrupt */
<WarheadsSE> Ah, if your kernel config doesn't have ext4 filled out, then yes
<WarheadsSE> fill out for xattr/acl/security
<hno> The sleep (and retried read) most likely only changes timing so that one test pattern do not catch this race window.
<mnemoc> hno: shouldn't it solve itself in the next loop?
<hno> There is no next loop. It solves itself on next packet.
<hno> the loop is terminated on !Rxcount
<mnemoc> ah, got it
<hno> there is a receive queue of some (10+) KB of packets.
<hno> Rxcount is the number of packets in queue.
<mnemoc> right. so we remove the second readl() and let the second packet release the first
<hno> yes, but on a quiet network you never know when that is.
<hno> Better to close the race window, making sure the rxcount is checked again after enabling interrupts.
<Turl> WarheadsSE: yep that was it :) reinstalled ping and it works now
<Turl> wonder how many other tools I broke though :P
* WarheadsSE shrug
<WarheadsSE> the set/getopt are kernel level, not FS level.
<WarheadsSE> So, the data should still be in the file
<Turl> WarheadsSE: maybe my desktop didn't have it either when I made the image? idk
<Turl> ping on my desktop has +s
<Turl> 9/499MB of RAM used :)
<hno> Turl, how did you make the image?
<WarheadsSE> pretty much my base rootfs, plus his kernel
<Turl> hno: followed the guide on http://archlinuxarm.org/platforms/armv7/mele-a100
<Turl> then upgraded it with pacman -Syu to be on the latest
<Turl> then built a kernel with mali & all the others disabled and copied it on the boot partition as uImage
<Turl> and I disabled all the ttyX too
<Turl> left just the one on ttyS0
<WarheadsSE> Makes sense, there are several things we don't change from upstream Arch, such as that.
<mnemoc> hno: http://sprunge.us/hHEA ?
TomNL has joined #arm-netbook
<TomNL> lundman: still there?
<hno> mnemoc, plus adding code in the if (!RxCount) block to check again after enabling interrupts.
<mnemoc> hno: read + goto?
aaribaud has left #arm-netbook [#arm-netbook]
<hno> read and no return if not zero.
<mnemoc> ok
<WarheadsSE> Turl: looks good
<WarheadsSE> i know it is zippy as hell to boot on systemd
jquip has joined #arm-netbook
<TomNL> mnemoc is the nic patch already commited to allwinner-android-v2?
<mnemoc> TomNL: yes
<mnemoc> since ~1h ago
<TomNL> hehe cool, i will try it...as normally nic is really slow...also i saw fbconsole for the first time today
<mnemoc> i don't know why I don't get a penguin :< LOGO is enabled...
<TomNL> i dont know...but i kept seeing the cursur through xbmc ;-)
<mnemoc> :)
<hno> mnemoc, yes, should do it.
<hno> the sleep that was there only shrinks the race window by sacrifying general system performance under network load
<hno> now there is another race that may cause repeated interrupt on an already processed packet, but that should be harmless.
<hno> protected by skb_last=NULL in start of wemac_rx
<drachensun> I'm trying to up my kernel to the pull 1G of ram, is there a suggested way to do this?
<drachensun> I was reading the open issue about it but it looks like it still relied on the kernel hack
* mnemoc runs xubuntu on his cubieboard with 1GB with no hacks and a fully open bootchain
<drachensun> I'm using the hno uboot and the allwinner-v3.0-android-v2 kernel
lerc_ has joined #arm-netbook
<drachensun> so you are using those and it sees the whole memory?
<t0dbld|work> mnemoc: Did you come up with kind of case for it ? I am about to build one for NFC enabled electric door strikes but need to look at houseing
Almamuetya has quit [Read error: Connection reset by peer]
Almamuetya has joined #arm-netbook
TomNL has quit [Ping timeout: 246 seconds]
lerc has quit [Read error: Connection reset by peer]
<mnemoc> drachensun: and a little patch to uboot to use dram params generated from my script.fex
<WarheadsSE> drachensun: ^
<WarheadsSE> the uboot patch + kernel are needed.
gimli has joined #arm-netbook
<drachensun> excellent, can you point me toward the patch?
<drachensun> I think I see where to fix the fex
<mnemoc> what device?
<drachensun> Its an OEM A10 Tablet
<mnemoc> the patch WarheadsSE is refering to won't apply to a recent uboot
<WarheadsSE> mnemoc: so I should update the uboot I have, just to be sure?
<drachensun> I can always try to modify it, better than what i've got now
<mnemoc> WarheadsSE: it's safer to keep what you have, until all the new PMU setup matures a bit
<WarheadsSE> K
<mnemoc> drachensun: get a recent copy of sunxi-tools, from amery's github
<hno> drachensun, disable the kernel hack overriding memory configuration. Update u-boot arc/arm/cpu/armv7/sunxi/dram.c with your board details (thiss will move elsewhere shortly).
<hno> trouble is finding the right board details.
<drachensun> ok, so this all in the kernel not uboot?
<hno> it's both.
<mnemoc> hno: I started https://github.com/linux-sunxi/sunxi-boards with those I have... cubieboard NULLs got replaced by real values
<hno> uboot needs to configure the memory controller correctly for your dram.
<mnemoc> hno: but there are a couple hundred devices from which we don't have .fex files
<drachensun> I'm going to submit a few later today
<hno> mnemoc, i know.
<hno> we have a couple options there, nothing unsolvable.
<hno> one is using livesuite, another figuring out how to read the nand. a third is replicating the probing done by livesuit
<hno> a fourth is guessing. It's not rocket science.
<hno> if you know how many chips, what chips and the data which is available in the fex then you have all data needed.
<drachensun> I can see I've got 4 ram chips, so do I need to set for DCR_TWO_RANKS?
<hno> if those are 16 bit chips yes.
<hno> what device do you have?
<drachensun> oem A10 tablet, let me search the chip part numbers
<jquip> mnemoc, hno: There are a couple of fex files at https://github.com/cnxsoft/a10-config if you need em
<mnemoc> drachensun: the [dram_para] section of your script.bin has the data. and `fexc` from sunxi-tools can generate the struct for you
<hno> jquip, mnemoc ^^
<jquip> we can always ask everyone here to submit their fex files... we should have a lot more then :)
<mnemoc> jquip: thanks
<jquip> awww shucks
<hno> jquip, problem is that dram parameters in script.bin is optional and many new devices leave it blank.
<drachensun> the density, rank num, io width and bus width are all blank
<drachensun> yup like mine
<drachensun> ok, I found the chip, 2Gb
<hno> drachensun, if you have u-boot console then it's possible to dump them.
<drachensun> I have a console
<drachensun> hno: how can I do that?
<jquip> hno: so we need to have default params for them ? how are they being filled in by the android system?
<mnemoc> drachensun: that's why we don't only need to collect .fex files, but to fix them to be reliable :<
<hno> then boot to nand u-boot, and then dump the memory region where boot1 was loaded.
<mnemoc> jquip: livesuit (their NAND flashing too) detects the values
<mnemoc> tool*
<jquip> hrmm... we need our own then..
<hno> md.b 0x42400000 0x82d0
<jquip> i mean some probe of sorts...
<hno> convert the dump to a binary file and use bootinfo from sunxitools to decode.
<hno> or visually inspect. dram_para is at offset 0x4c.
<mnemoc> and don't forget to write down your new knowledge in http://linux-sunxi.org :)
<drachensun> ok
<drachensun> at 0x4c I've got 00 00 00 40
<hno> http://fpaste.org/MpEu/ is example data from an Olinuxino A13.
<hno> yes, that.s fine.
<hno> md.l might be easier to read actually.
<drachensun> 40000000
<mnemoc> baseaddr
<drachensun> I never figured out how to paste from Gtkterm
<drachensun> oh wait, I'll just save the log, hold on
<mnemoc> drachensun: but bootinfo from sunxi-tools can show it nicer
<hno> it maps 1-1 to the offsets shown in my paste.
<drachensun> how do I dump this data to file?
<mnemoc> copy&paste
<drachensun> ok, your paste is perfect, I'll compare
<drachensun> ok, so my bus width is 32
<drachensun> well the kernel is already set for that
<drachensun> here is mine
<drachensun> how does bootinfo expect the file to formatted
<mnemoc> bin only
cat_n9 has quit [Ping timeout: 245 seconds]
<mnemoc> drachensun: http://linux.die.net/man/1/xxd
Quarx has quit []
<drachensun> well I've gone through all the values manually and figured out what they were
<mnemoc> :)
<drachensun> the kernel setup looks like, the main difference with the paste info is the bus width but when I looked in the kernel config, that was already set
<mnemoc> those values go in uboot's dram.c
<hno> kernel config?
<drachensun> but yeah, I didn't know xxd could do a 'reverse dump' I guess you would call it
<mnemoc> nothing to do with the kernel
<drachensun> ah
<drachensun> wait
<mnemoc> you can also use them to fix your [dram_para] in script.fex
<drachensun> I've got too many windows open, give me a sec
<drachensun> yeah, I did that while I was converting the numbers
<hno> putting the hex in dram.c is fine.
<hno> even if some are normally seen as decimal numbers.
<drachensun> I am in the sunxi branch, not the sun4i branch, does that make a differnce? because the file I have is dram-sun4i.c
<hno> there is no dram-sun4i.c file since some days.
<drachensun> so thats not good, let me switch branches
<hno> sunxi is the right branch.
<hno> when did you last pull from github?
<drachensun> I'm actually in sun4i
<hno> there is no dram-sun4i.c in sun4i either. Only oldish sunxi.
<drachensun> I've only been at this for 2 weeks or so, I think I pulled originally on the 18th of sept
<drachensun> ok, let met just get it all caught up real quick
<hno> much happened since then.
<drachensun> fair enough
<hno> Date: Fri Sep 28 12:56:22 2012 +0200
<hno> sunxi: Unify DRAM config based on sun5i
<drachensun> lol
<drachensun> oops
<Turl> WarheadsSE: no eatmydata on arch? dealbreaker!
<hno> before sun4i had parameters coded at register format, not so easily changed
<WarheadsSE> Turl: que?
* WarheadsSE looks
<WarheadsSE> more specifically
<Turl> WarheadsSE: I suck at using the search then on pacman hm
<Turl> pacman -Qs was it?
<Turl> hm nope, Ss, but still no results
<WarheadsSE> -Q is local
<WarheadsSE> -S is repo
<WarheadsSE> thats an AUR package though
<Turl> not on pacman? :/
<drachensun> ok its freezing at 'jumping to U-boot'
<drachensun> weird, let me see if I didn't copy something right
<Turl> WarheadsSE: what does ' aur is up to date' on -Syu mean then?
<drachensun> hno: should I build for target sun4i or sunxi now?
<hno> sun4i for a10, sun5i for a13
<drachensun> ok, its an a10
<drachensun> did the default jump addresses change or anything?
<WarheadsSE> we have some packages from the AUR that are pulled from AUR into our Github and built, because of large changes that need made for arm, or because we have enough people trying to build a very large package
* Turl installs compilers on mele :P
<Turl> WarheadsSE: is there anything to be notified of updates to stuff on aur?
<WarheadsSE> I am not sure
<drachensun> did maybe the terminal output settings change?
<WarheadsSE> Turl: base-devel :)
<Turl> yeah that's what I'm installing :)
<Turl> takes a lot to install on my slow sdcard though :p
<hno> drachensun, much change, but if you see SPL output then the UART settings are right.
<hno> and I don't think I have broken sun4i after it was last tested.
<drachensun> ok, if I let my onboard system boot then reset I get a boot loop after spl, if I just hard reset with the card in it tries one and freezes after spl
<hno> hm.
<hno> not nice.
<drachensun> I mean the boot loop happens by putting in the sd card then resetting
<drachensun> if that gives any clues
<drachensun> ok
<hno> i understood that.
<drachensun> ok
<hno> sorry, not much ideas to try assuming you got the dram parameters right.
<drachensun> does u-boot try to do that setup before it post any messages?
<hno> yes, but SPL is running from SRAM mostly, while full u-boot is loaded into DRAM and executed from there.
<hno> SPL surives most DRAM configuration errors.
<hno> full u-boot some.
<hno> linux kernel very few.
<drachensun> something to start with then, ok
<hno> does it surive on the default parameters?
<hno> those should be the same as used in sun4i branch.
<drachensun> well at first I tried it before copying my new script.bin back
<drachensun> so with the factory script.bin it had the same behavior as my new one with the dram values filled in
<drachensun> is there another way to try and run with the default values?
<hno> do the sun4i branch work?
<hno> except for dram size
<drachensun> building now
<drachensun> hmmm no it doesn't and I see you have no new commits since before my previous work
<hno> Hm.. the dram clock in your boot1 data is very high. 432MHz.
<hno> And io_width also looks wrong. Should most likely be 8.
<hno> sun4i branch is only kept as reference.
<hno> have not settled 100% on style of dram.c yet. Might switch to the style in sun4i later. But first need to get stuff working right.
<mnemoc> hno: the cubies is 480
<hno> it is?
<mnemoc> initially it was 408, but they changed it to 480
<hno> data sheet says it supports up to 400. (400 DDR is 800)
<drachensun> well this make no sense, I reverted to sun4i which hasn't had updates and I reverted by bin file and still it wont start
<drachensun> heh and I just booted from nand to make nothing is fried, it boots right up
<drachensun> ugh
<rm> try pulling and reinserting the SD card
<rm> the card/slot can be ugh'y that's for sure
cat_n9 has joined #arm-netbook
<drachensun> its been in and out and bunch of times for all these versions I've been testing
<drachensun> my fork works
<drachensun> my fork doesn't seem to make since though, the branch is sun4i but if I look at the commits its looks like hno:sunxi splitting on sept 12
<drachensun> so I was really in sunxi from then
revident has joined #arm-netbook
<drachensun> I guess I will inch up the sunxi branch and see which commit it is
<hno> drachensun, "git config" shows which branch you are default pulling from.
<hno> git config -l
<hno> sun4i was pretty much unchanged in sunxi until Sep 29.
<drachensun> I was using sunxi, it just got mislabeled in my fork so yeah, the unify dram commit is when it stopped working
<drachensun> and something since fixed spl for me
<drachensun> so its looks like most of these values are still hardcoded, in sunxi_dram_init, are they changed later?
<drachensun> or wait, or is that where I need to put my custom settings?
<hno> yes.
<hno> It will move to a configurable header later on.
<hno> hopefully will have just one binary for sunxi with different parameters.
<hno> but at least just one binary for each cpu.
<mnemoc> can you read the brom early enough from u-boot to get the chip-id?
<hno> Yes, but still need the right DRAM parameters.
<hno> will not look into magic probing until we have everything working with configured parameters.
<mnemoc> yes, I was only thinking about branching sun4i vs sun5i before trying dram params
<hno> and not all parameters can be probed.
<mnemoc> sure
<mnemoc> if it doesn't work perfect with the blessed struct of parameters...
<hno> if we use the allwinner headers then brom based switch is needed. If using custom header no.
<mnemoc> :)
<hno> if having a single binary for both CPUs.
<mnemoc> that would be ideal
<hno> but as I said, not venturing into that before having things working well with.
<mnemoc> but then you still face the door with script.bin/.dts
hp__ has quit [Read error: Connection reset by peer]
<hno> Well, converting script.bin to dts is only little modification to your tool.
<mnemoc> no no
<mnemoc> I mean, the limit of the universal booting card
<hno> I wonder what phoenixcard is doing nowdays.
<mnemoc> even if u-boot and the kernel are multi-platform, one will still need to provide the right board config file
<hno> it's also using boot0/boot1. But if DRAM parameters is no longer in the firmware image, how do phoenixcard know how to configure dram?
<mnemoc> maybe the probing code isn't in livesuit but in the image
<hno> I don't think so. boot0/boot1 stored in nand have the parameters set.
<hno> and a phoenixcard created image boots via boot0 setting up DRAM and boot1 setting up the PMU & CPU clock like usual.
<hno> with boot1 running from DRAM.
<hno> tom published new tools?
<mnemoc> yes. they use that one to produce buildroot livesuit images for the cubie
<mnemoc> well... not tom, his friend "matson hall"
<mnemoc> bin/build.sh is the trigger
<drachensun> I've been wanting something like that, i tried building an image for livesuite and it was a disaster
<mnemoc> :)
<hno> the sdk have always had buildroot support.
<hno> for a10,
<mnemoc> allwinner-pack-tools, allwinner-buildroot and linux-allwinner in the same dir, and then ./allwinner-pack-tools/bin/build.sh to make it run
<drachensun> I didn't realize buildroot would put out an image livesuite could use
<mnemoc> hno: his allwinner-buildroot is actually a fork of yours
<mnemoc> drachensun: buildroot can't, their packing tool does
<hno> mine is just an import of the sdk.
<mnemoc> :)
<hno> haven't touched it at all.
<mnemoc> he made some fixes, in the cubieboard branch
jquip has quit [Quit: jquip]
<hno> mnemoc, also several kernel fixes.
<mnemoc> hno: the sata fix I sent to me ML was from there
<mnemoc> the other is a DMA related fix to the NAND I need to push
<mnemoc> the fixes to the core are already included
<mnemoc> the 8250 "fix" is... uhm
<mnemoc> I have a 3.0 branch named cubie built with those
<hno> any idea who it is?
<mnemoc> a friend of tom
<drachensun> are there any hardcodes outside of sunxi_dram_init I should check?
<hno> Yes, but the NAND & PLL6 changes can not be done without information from Allwinner.
<hno> drachensun, not really. The clock is still hardcoded in clock.c, but should be safe.
<hno> only a bit slow compared to before. Need the PMU working before increasing clock frequency.
<hno> that's the CPU clock, not the DRAM clock.
<drachensun> Looks like you dropped the N factor to 16 right?
<drachensun> oh wait, thats the nand clock
<hno> The PLL1 config is quite raw at the moment.
<hno> ccm->cpu_ahb_apb0_cfg = 0x00010010;
<hno> ccm->pll1_cfg = 0xa1005000;
<hno> "stolen" from boot0.
<hno> all temporary until PMU code is in place.
<mnemoc> techn_: what do you mean by "Expect"?
<techn_> ah :)
<techn_> except :)
<techn_> anyway I changed that gt818 commit and removed duplicate driver which came with
<techn_> it
<techn_> and disp commit is not there.. and I'm not sure if you want that debconfig change ?
<mnemoc> techn_: so first I need to remove some hashes from my branch. which?
<drachensun> alright well I'm not even sure how to debug this so I'm just going to revert and
<drachensun> wait and see if maybe something comes up
NAiL__ is now known as NAiL
NAiL has quit [Changing host]
NAiL has joined #arm-netbook
<techn_> mnemoc: what you mean? :/
<mnemoc> techn_: I have to remove those 3 hashes from my branch, right?
<NAiL> I've been away for a couple of weeks. Anyone mind giving me a /really/ quick update on A10?
<techn_> no.. what I'm missing..
<mnemoc> techn_: ok, lets rephrase. I have a branch you have a branch, which of mine conflict with yours?
<techn_> If you'll rebase You'll need to drop ffed85e52b9cee6f35992982ca68a1b65882167e and take this instead e691ffe.. then cherry pick 35ab609
grevaillot has quit [Ping timeout: 268 seconds]
<hno> NAiL, what happened in last three weeks? ̈́
<techn_> or just trash that sun5i branch and take pull request :p
<NAiL> hno: That's the shortest summary I've seen in a while ;)
<mnemoc> techn_: problem is yours isn't not properly rebased :)
<mnemoc> s/isn't/is/
<ibot> mnemoc meant: techn_: problem is yours is not properly rebased :)
<Turl> will this help with devices waking up by themselves? :)
<mnemoc> techn_: I'm confused by include/linux/drv_display_sun4i.h -> include/linux/drv_display_sunxi.h
<mnemoc> techn_: I don't see any #ifdef to deal with the diff between include/linux/drv_display_sun4i.h and include/linux/drv_display_sun5i.h
<hno> NAiL, lots happened in last weeks, or not much depending on who you ask and what you look for.
* mnemoc gets pissed off by people treating the community as their secretary
<NAiL> hno: Well, anything on A10 VPU stuff? I'm guessing I'll get no response if I ask gimli :-P
<hno> The biggest change for me (apart from u-boot stuff) is that there is now 3 channels and 3.5 lists to keep track of.
<drachensun> lol
<Turl> a guy named empat0 came one day out of nowhere with xbmc with cedar support :P
<mnemoc> hno: :D
<Turl> hno: 3 channels and 3.5 lists? o.O
<hno> 3 irc channels, 3 mailinglists and one forum.
<Turl> I'm missing a list and two channels
<drachensun> yeah me too, fill us in
<mnemoc> #arm-netbook, #cubieboard, #olimex
<hno> maybe it's only two lists. It's a little diffuse.
<NAiL> oh great
<Turl> I do keep track of ~10-15 channels and ~5-6 mailinglists a day
<mnemoc> and arm-netbook@ cubieboard@ linux-sunxi@
<hno> right, 3 lists.
<mnemoc> olimex switched to forum
<Turl> oh, didn't know of #cubieboard / cubieboard@
<hno> which is the .5
* mnemoc doesn't follow forums
<hno> and I round down.
<mnemoc> :)
<Turl> mnemoc: any important emails on cubieboard@ or is it customer support or the like?
<hno> There was one majorly important one at least.
<mnemoc> arm-netbook is talk about everything... while it should be eoma
<mnemoc> cubieboard, about the board
<mnemoc> olimex, the a13/a10 olinuxino boards
<Turl> got a link handy to it then?
* Turl just set up autojoin on #cubieboard
<hno> Turl, but apart from that one message it's mostly questions about when cubieboard gets delivered.
<mnemoc> and linux-sunxi... hopefully for developers and patch reviews
<Turl> hno: I'll join but autotag and check once in a while then
<mnemoc> Turl: cubieboard@ and linux-sunxi are in google groups
<mnemoc> but you can subscribe sending an email too
<Turl> cubieboard+subscribe@googlegroups.com I'm guessing
<mnemoc> yes
<techn_> mnemoc: ok.. I'll rebase that tomorrow
<mnemoc> techn_: I'm almost done
<mnemoc> techn_: just wondering about that header
<techn_> Thats from sun5i branch.. abit improved :p
<mnemoc> so I just git rm include/linux/drv_display_sun5i.h ? (got a conflict)
<techn_> in sun5i-import branch they just started to use sun4i header.. I changed sun4i to sunxi and removed sun5i
rsalveti has quit [Read error: Connection reset by peer]
<mnemoc> techn_: ok...
<mnemoc> techn_: and what about the rest of "touchscreen: import gt818, sw-ts and fixes from sun5i-import branch" ?
<mnemoc> your replacement only seems to include gt818
<techn_> sw-ts was duplicate for driver which we had.. but there is still other ts improvements left
gimli has quit [Quit: Verlassend]
arokux_h has joined #arm-netbook
rsalveti has joined #arm-netbook
<mnemoc> techn_: wip/linux-sunxi-3.0/sun5i updated
<mnemoc> techn_: but there are several parts that seem harmful for sun4i
<Turl> are the emails prefixed with "[cubieboard]" or something on subject line?
<mnemoc> Turl: yes
<techn_> mnemoc: thanks.. yep.. + c++ comments, tabs, .. :)
<mnemoc> techn_: it would be awesome if you could confirm all of yours is there and then start working upon that one
<Turl> mnemoc: what is it exactly? :)
<Turl> I'm making a filder
<Turl> filter*
<techn_> mnemoc: but I think thats good start to get stuff into mainline
<mnemoc> Turl: what is what?
<Turl> the prefix
<mnemoc> [cubieboard]
<mnemoc> Turl: but for the filter you can use mailing list headers
<RaYmAn> google lists also inserts a header with the listurl or soemthing like that
<RaYmAn> indeed
<mnemoc> List-ID: <cubieboard.googlegroups.com>
* hno have dropped most mailing list filters and filter manually, after forgetting he was subscribed to some important lists...
Almamuetya has quit [Ping timeout: 246 seconds]
<Turl> I'm subscribed to alsa-devel
<Turl> I should probably unsubscribe one day :P
von_fritz has quit [Quit: vonfritz leaves, don't panic]
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
eFfeM has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 248 seconds]
RITRedbeard has quit [Read error: Connection reset by peer]
RITRedbeard has joined #arm-netbook
arokux_h has quit [Remote host closed the connection]
mysteryname has joined #arm-netbook
eFfeM has quit [Quit: Leaving.]
akaizen has joined #arm-netbook
<lundman> TomNL: sup?
mysteryname has quit [Ping timeout: 246 seconds]
tzafrir_laptop has joined #arm-netbook
ZaEarl has joined #arm-netbook