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/
DEAT_ has quit [Read error: Connection reset by peer]
DEAT_ has joined #arm-netbook
traeak has quit [*.net *.split]
hno has quit [*.net *.split]
<ManoftheSea> truecrypt?
<ManoftheSea> Bleh at truecrypt.
traeak has joined #arm-netbook
hno has joined #arm-netbook
<Turl> RaYmAn: ping me when around
<lundman> doont do it!
Boulet has joined #arm-netbook
<Boulet> all sleeping?
<ManoftheSea> no.
<orly_owl> yes, sssssh
<lundman> WHAT?
<Turl> hey lundman
<Turl> lundman: what's the network perf of wemac like for you?
<Turl> trying to figure out if I need to blame the wifi or something else without running any actual tests
ManoftheSea has quit [Ping timeout: 252 seconds]
hno has quit [Ping timeout: 260 seconds]
rmull has left #arm-netbook [#arm-netbook]
hno has joined #arm-netbook
hipboi has joined #arm-netbook
ManoftheSea has joined #arm-netbook
<WarheadsSE> X11: I hate you
<WarheadsSE> X: malloc.c:2810: mremap_chunk: Assertion `((size + offset) & (_rtld_global_ro._dl_pagesize-1)) == 0' failed.
<hipboi> : D
<WarheadsSE> xxiao & hno : its not like these things are expensive
<WarheadsSE> dupe & ship
tuliom has quit [Quit: Konversation terminated!]
tallnerd1985 has joined #arm-netbook
<WarheadsSE> hipboi: thanks for straightening out the name.. but seriously ""Arch Linux ARM""
<hipboi> ok
<hipboi> changed
<hipboi> i may take a while to change in the foregroud
<WarheadsSE> :)
<WarheadsSE> heh
<WarheadsSE> "mele a100 arch"
<WarheadsSE> platform page, smack in front :)
<WarheadsSE> You can add this whenever you want :) http://archlinuxarm.org/platforms/armv7/mele-a100
<hipboi> aha
<hipboi> good
tallnerd1985 has quit [Quit: Colloquy for iPad - http://colloquy.mobi]
hipboi has quit [Quit: Leaving]
<Turl> WarheadsSE: am I the only one that doesn't get /dev/mmcblk* stuff?
<Turl> on all my systems and devices it's /dev/*block*/mmcblk*
<rz2k> tons of bots registrated again http://linux-sunxi.org/Special:RecentChanges
<rz2k> we need captcha or something
<Turl> yeah
<Turl> as long as they don't spam it's not so bad though
<CIA-121> rhombus-tech: Jean-Luc_Aufranc master * r29b539205ccb /allwinner_a10/nightly_build_images.mdwn: Removed text about download hardfloat libs, since the build has been updated to use those.
<WarheadsSE> Turl: let me boot it back up...
<Turl> WarheadsSE: yeah but it's /dev/block/NAME over here
<WarheadsSE> what kernel
<WarheadsSE> anroid/linux
<Turl> the A10 one for example
<WarheadsSE> well yeah..
<WarheadsSE> anroid or linux though ?
<WarheadsSE> And I suppose it depends a bit on the distribution and devtmpfs + udev rules
<Turl> the kernel is the same? :P
<Turl> hmm
<Turl> my mele has weirdo num:num entries on /dev/block/ only
<Turl> all my android phones use /dev/block/
<WarheadsSE> might be an android thing then
<Turl> my pc has /dev/block/ too with the weird numbers :P
<xxiao> WarheadsSE: see quite a few of your posts in archlinux on pogoplug
<xxiao> i have not used archlinux, what's the advantage of it?
<WarheadsSE> well, yeah
<WarheadsSE> I'm a core developer.
<xxiao> smaller? faster? more stable? more hackish?
<xxiao> looks like archlinux replaces other projects for all sorts of 'plug' computers
<WarheadsSE> as compared to...
<xxiao> debian
<xxiao> debian stable
<WarheadsSE> much more up to date
<xxiao> sid?
<WarheadsSE> the front page covers ut really
<WarheadsSE> i have to go to bed
<xxiao> ok, thanks, will check out
<Turl> as far as I understand it, Arch is like Gentoo but without the "build all the things" part
<furan> heh
<furan> here I am scrounging for the kernel and it's u-boot.bin
qubits has joined #arm-netbook
qubits has quit [Changing host]
qubits has joined #arm-netbook
<furan> is there source for the silabs f76x?
<qubits> will the lapdock and mele a2000 work well
<qubits> or is there a better combo like the bluetooth minikb with trackpad
<qubits> im thinking a 4 inch screen would be too small to see a shell on?
qubits has quit [Ping timeout: 256 seconds]
MMlosh has quit [Ping timeout: 248 seconds]
Quarx has joined #arm-netbook
gimli has joined #arm-netbook
<RaYmAn> turl: dev block names are ueventd or udev
<RaYmAn> Turl: also, I didn't write that dump_atags tool... but the headers are from linux kernel, so..I guess we GPL it? :P
<mnemoc> everytging else in sunxi-tools is gplv2+ too
<RaYmAn> 'k
<RaYmAn> I did actually write a dumpatags (I didn't know this one was out there at the time), but I can't find my source anymore :(
<RaYmAn> you wouldn't happen to have a linux dist for arm that's small enough to fit in ramdisk? :>
MMlosh has joined #arm-netbook
arokux_h has joined #arm-netbook
<mnemoc> rayman: rob landley's linux has minimal rootfs-s
<mnemoc> RaYmAn: ----^
<Boulet> i'm also interested in a very very very small linux dist like this :)
<mnemoc> irc on android sucks even with znc
<RaYmAn> mnemoc: irssi + irssi-connectbot is decent :>
<RaYmAn> mnemoc: ah, cool - I'll try it out.. I was considering going custom with buildroot
<Boulet> mnemoc this is for armv4 ???
<Boulet> what's armv4 ? hum arm7 ? ;)
<mnemoc> one tarball per optimization
<Boulet> oh sorry, did not see, for some reasons the names don't appear correctly
<mnemoc> too long
<Boulet> he does not have armv7 though
<mnemoc> poke him on #elinux or #edev
<Boulet> bah i don't know how to use all this anyways
<mnemoc> just extract it and the cpio + gz
<mnemoc> bbl
<RaYmAn> Boulet: armv7 is backwards compatible
<RaYmAn> so it can run armv4 just fine
<Boulet> yes i am sure
<Boulet> but maybe it's not as optimized
<Boulet> and in armv7 if the CPU supports NEON, some basic stuff like string compare, copy, memset, memcpy can be even faster
<hno> RaYmAn, who wrote dump_atags?
<arokux_h> mnemoc, hi, what is going on with kernel development?
<Boulet> just trying to save some precious cycles .... haahha
<RaYmAn> I doubt there's anything preventing you from using NEON in your own app
<Boulet> yes
<hno> arokux_h, we are getting a hang on booting A10 b& A13 nicely
<Boulet> no problem with that
<arokux_h> hno, which branch are you working on?
<hno> arokux_h, none.
<hno> RaYmAn, ok, if the new tool is baeed on that then we need to ask if it's GPL before slapping a license on it. Most likely is.
<arokux_h> hno, ok, let's put the question the other way. I've compiled and booted 3.0.x kernel and willing to do smth. is there anything you can point me to?
<RaYmAn> hno: depending on whether Turl read the code or not :> The atag.h is verbatim from linux kernel source, so he definitely has no say over that
<RaYmAn> hno: but yeah
<hno> RaYmAn, ofcourse. Only if anything of the .c is used.
<RaYmAn> hno: to be completely honest, I doubt any of the actual sourcecode in dumpatags would be useful for creating createatags. And it's clearly based off the kernel code that parses those tags :)
<hno> arokux_h, mnemoc is the man to answer that, but you could try looking in the issue tracker.
<specing> RaYmAn: compress whatever you have now with squashfs and upload it
<RaYmAn> specing: If I had anything, that'd be what I would do ;)
<RaYmAn> specing: also, can linux kernel use that from memory entirely?
<specing> yes
<specing> I've booted Gentoo over PXE like this before
<RaYmAn> hm
<hno> Yes. atag is just a TLV. Hard to fail writing one.
<RaYmAn> how though? I mean, a cpio'd gzipped bundle I can just upload to memory and set initrd2 tag and it'll *poof* work :P
<hno> RaYmAn, squashfs can be run from a ramdisk, so initrd mechanism works.
<RaYmAn> what advantage does it have over a cpio'ed gzipped image?
<specing> moar compression
<hno> it stays compressed in memory, decompressed on access.
<hno> runs slower
<RaYmAn> ah
<hno> much harder to extend
<arokux_h> sun3i <--- is that of interested or is it some older code?
<hno> the initramfs images is trivial to extend. Just concat another cpio.gz archive with the changes.
<hno> arokux_h, that's the older F20 chips.
<hno> not sure if there is any activity on those at the moment.
* RaYmAn pokes Turl
ibrah has joined #arm-netbook
gimli has quit [Quit: Verlassend]
madmalkav has joined #arm-netbook
madmalkav has quit [Client Quit]
madmalkav has joined #arm-netbook
Quarx|2 has joined #arm-netbook
arokux_h has quit [*.net *.split]
Quarx has quit [*.net *.split]
arokux_h has joined #arm-netbook
<arokux_h> hno, I'm somehow confused. how is the mainlining done in general? fixing some issues on the github means backporting of some bug fixes from the upstream. but is this mainlining?
<rz2k> mainlining is getting rid of all allwinnerization of kernel, unification of platform/machine specific stuff. long story short: getting code to kernel standards. only when code is done like other machines/platforms for archeticture it can be added to upstream kernel.
<rz2k> usually its done by SoC/CPU manufacturers themselves.
<arokux_h> rz2k, for example there is the following issue, which describes the possible bug in the ibm_newemac: https://github.com/amery/linux-allwinner/issues/49
<arokux_h> however, such a driver exists in the mainline. so should we really need to care about fixing this?
<arokux_h> isn't the first priority just to get vanilla kernel running on the allwinner and only after that to fix all the bugs left?
<RaYmAn> arokux_h: I don't see any reference to ibm_newemac anywhere in that bug?
<RaYmAn> arokux_h: also, keep in mind that mainlining is a *huge* effort
<RaYmAn> Allwinner has done a lot of things in their own ways, so things have to be rewritten to use mainline ways
<arokux_h> ibm_newemac = wemac
<RaYmAn> yeah, I figured that what was you meant, but are you sure that's the case? =P
<arokux_h> oh.. probably not!
<arokux_h> shit, I haven't scrolled the grep results till to the end.
<Boulet> RaYmAn, so when fel execute some code, MMU is enabled ?
<arokux_h> there is sun4i_wemac too. ok. so in this case will be the right mainlining way to mainline this driver and push it upstream?
<RaYmAn> arokux_h: yeah - that's the plan.
<arokux_h> I'm just confused as what is the correct workflow...
<RaYmAn> Boulet: seems like it. But I guess someone has to write code to verify.
<arokux_h> RaYmAn, another stupid question: suppose I've rewritten sun4i_wemac to be a shiny canonical driver. how could I test it? could I use this driver together with allwinner-v3.0-android-v2 or it depends?
<RaYmAn> SHould be possible, I'd say
<arokux_h> basically the question is if the inner APIs of the ethernet drivers changed between 3.0.0 and linux-torvalds.
<RaYmAn> The big problem is, does it make sense & would it be accepted to submit such a driver by itself? It's for an allwinner specific builtin device
<RaYmAn> e.g. do we need basic support for allwinner a10/a13 in kernel first before we can start submitting drivers
<arokux_h> I see. I'm just looking for a corner for me to hack.
<RaYmAn> I'm not trying to discourage you, it's just not easy to find out where it makes sense to work
<arokux_h> also: in the driver module it says: Davicom wemac network driver. could it be that this device is used *only* on allwinner boards?!
<RaYmAn> though, I believe most of the mainlining effort goes on in the 3.4 branch
<RaYmAn> arokux_h: that's my theory :P (on allwinner, it's actually part of the SoC, NOT an external component)
<arokux_h> RaYmAn, hm.. isn't it the same with normal intel ethernet modules which are also builtin into the motherboard?
<rz2k> arokux_h: ping rm about davicom, I remember he said something about allwinner grabbing some IP core for ethernet and public driver for it
<arokux_h> IP core?
<RaYmAn> arokux_h: mm, it's possible. It's a bit more integrated when it's actually in the SoC, rather than on the board.
<rz2k> instead of making own ethernet, they just buy core and integrate it with their ASIC
<arokux_h> rz2k, ok, but the buy only the logic and produce the hardware themselves?
<arokux_h> RaYmAn, what falls under "basic" support? and what happens currently if vanilla kernel is booted on A10? :)
<RaYmAn> arokux_h: try it! :)
<arokux_h> I work on it remotely.. :)
<RaYmAn> embedded devices are quite different than normal x86 systems
<rz2k> they integrate IP core in their design, usually core has in/out ports and needs only light customization/configuration, then they grab public linux driver for that core and ethernet is done.
<rz2k> fast and simple.
<RaYmAn> while obviously some of the code will work (because it's arm), it won't know how to talk to anything. Register mappings are per-SoC etc - and arm has no real "auto-configuration" support
<RaYmAn> arokux_h: so basically, you'll mostly see nothing happening
<rz2k> lets bring device tree support to sun4i
<RaYmAn> of course that's part of the plan =P
<rz2k> then mainline guys will be interested in us, because its sorta, bleeding edge technology.
<RaYmAn> I think device tree support is required for new devices, isn't it?
<rz2k> yes
<rz2k> for all of them, I have pretty dumb situation here regarding device tree, Renesas officially added EV2 support to mainline in 3.5, BUT they didnt release U-Boot with device tree support for EV2.
<rz2k> so basically I cant even load it right without JTAG :3
<RaYmAn> sucks :(
<RaYmAn> I saw on tegra, they made a 'hack' (iirc mainline), where it uses a kernel-appended device tree and then merges it with bootloader provided (old) values
<arokux_h> what is done of the "basic support"?
<arokux_h> RaYmAn, and what is the relation of the linux-sunxi-3.4 to the android kernel? :)
<RaYmAn> no idea
<RaYmAn> "the android kernel"
<RaYmAn> that's a really broad non-specific term .P
<arokux_h> RaYmAn, so do you do some kernel development yourself?
<RaYmAn> yes - haven't done a lot wrt allwinner yet though.
<rm> arokux, afaik Allwinner's wemac is not a derivative of a Davicom chip, it's just vaguely similar and the Davicom driver was used as a template for the wemac driver
<lkcl> arokux: the ethernet driver looks very much like it's a DM9000, with the registers being slightly different due to the way that allwinner connected them together
<rm> but the way hardware is controlled is quite different, afaik lundman done some comparison of these drivers
<rm> thanks lkcl :)
<lkcl> i believe it was established that yes, the hardware is the same but the connectivity is different from a "DM9000-as-sold-as-a-separate-integrated-IC" and "DM9000-circuits-as-used-inside-the-A10"
<arokux_h> let me understand some another thing guys: is a purpose to mainline into vanilla linux or vanilla android kernel?
<RaYmAn> linux. Android kernel is just addons on top of linux
<lkcl> so, allwinner went "hmm, if we wire this DM9000 circuit up onto the AMBA bus, we're going to have to make register1,2,3 and 4 all addressable on the same 32-bit memory location"
<lkcl> etc. etc. blah blah :)
<RaYmAn> so if we get a10/a13 support into mainline linux, it will automatically (kind of) show up in new android kernels :P (eventually)
<lkcl> RaYmAn: well... maybe, and maybe not. the allwinner team *might* decide that the code isn't right for them, strip it all out, start using different subdirectory names and continue on their existing (isolated) path
<RaYmAn> lkcl: sure, I didn't mean allwinner kernel,I meant google android kernels.
<lkcl> same thing.
<RaYmAn> how so?
<lkcl> doesn't make any difference. yes, sure, it would "turn up" in the kernel.org and/or code.google.com "official" android sources
<RaYmAn> As far as I'm concerned the goal is to ignore allwinner mostly and only pull in any fixes we might get from them by accident
<lkcl> but what good does that do you for a *specific* device?
<lkcl> oh, ok - great! :)
<RaYmAn> It certainly makes the process easier for supporting new devices
<RaYmAn> if we have generic allwinner in mainline + google android kernels
<lkcl> i thought you meant "show up in new android kernels i.e. in mass-volume hardware products i.e. in binary form i.e. as sold"
<RaYmAn> especially with device tree support
<RaYmAn> oh, nah
<RaYmAn> I was purely talking about the kernel source
<lkcl> sorry, jumped ahead a step there
<RaYmAn> I'm not expecting allwinner to use "our" code
<RaYmAn> I have little faith in allwinner, other than hipboi
<RaYmAn> heh
<arokux_h> why then android kernel is merged into linux tree?! https://github.com/amery/linux-allwinner/commit/6fe780051563e857d3892d19559054a74393457f
<RaYmAn> lkcl: your notes on your site makes allwinner seem so nice, yet in practice it's nowhere near as nice ;) (the comments about board of directors and gpl)
<RaYmAn> </random comment>
<RaYmAn> :)
<RaYmAn> arokux_h: so we can use android? :)
<arokux_h> RaYmAn, so it could be merged very easily..?
<lkcl> RaYmAn: directors aren't the ones who have to action their decisions.... :)
<lkcl> ok, not in huge companies...
<RaYmAn> arokux_h: as I said, android parts are (mostly) just extra drivers and a few differences in setup. It's still a linux kernel.
<RaYmAn> lkcl: mmm, but they decide to make silly (illegal) NDA's with their customers still.
<RaYmAn> :)
<arokux_h> RaYmAn, so the current development branch is linux-sunxi-3.4 and allwinner-v3.0-android-v2 being a legacy stable one?
<RaYmAn> both are actively developed (linux-sunxi-3.4 mostly in seperate topic branches)
<RaYmAn> mainlining is longterm
<arokux_h> RaYmAn, why is 3.0 still developed?
<RaYmAn> presumably because it's the most complete branch. :)
<arokux_h> ok, this was my guess to.
<arokux_h> too*
<RaYmAn> hno: you happen to know the C entry point of u-boot?
<arokux_h> RaYmAn, what does the prefix "wip/" at the number of branches mean?
<RaYmAn> work in progress
<techn> whee.. I got first output from fbcon :)
<RaYmAn> oh, cool! on a10?
<techn> yep.. a10
<RaYmAn> awesome! :)
<techn> still bit slow, but just proof of concept
<RaYmAn> it's certainly better than blank :)
<techn> trying to clean it today and send patch if u are interested
<arokux_h> techn, on 3.4 branch?
<techn> i'm using androidv2
<rz2k> awesome techn
<arokux_h> does anyone knows if linux-sunxi-3.4 is bootable on A10?
<arokux_h> and if it will have ethernet?
<techn> after decre
<techn> after decreasing prints.. it's pretty fast.. :)
<rz2k> afaik, 3.4 has a weird bug regarding memory mapping, some time ago I've tried to boot it and it always failed at LCD memory initialization
<rz2k> on mele it worked
<techn> btw.. can I put disp, hdmi etc drivers inside kernel? So that we'll get boot traces?
<arokux_h> rz2k, what was the other device you were booting it on?
<RaYmAn> I think previous attempts have shown failures wrt initializing mali stuff if you do that?
<rz2k> techn: you need correct modules order to make mali work
<rz2k> arokux_h: LY-F1 tablet, http://linux-sunxi.org/LY-F1
<techn> so inorder to get bootlogs, we'll need to refactor codes.. cleanup dependencies?
<techn> or would initramfs help as workaround?
<rz2k> j1nx did initramfs support for a10
<rz2k> it was in his blog
<rz2k> with examples and everything
<techn> k
<arokux_h> another stupid question guys..: what is the status of http://linux-sunxi.org and rhombus-tech websites?
<arokux_h> hm.. doe cubieboard has something in common with Tom Cubie aka. hipboi?
<RaYmAn> yeah, he's making it
<RaYmAn> :P
<rm> i.e. has everything in common :)
<arokux_h> what about websites?
pwhalen has quit [Ping timeout: 276 seconds]
<hno> techn, what is problem with getting logs when having kernel modules? Have never heard of such problems before.
<hno> arokux_h, what about the web sites? Both are alive and kicking.
<techn> hno: just verifying, that modules can be loaded early enough :)
<arokux_h> hno, but duplicating each other a bit.
<hno> early enough for what?
<techn> to get boot logs
<hno> arokux_h, it's a web.
<hno> Why can't you get logs when loading modules?
<techn> I mean logs to fbcon
<hno> There is no fbcon on A1x yet.
<techn> hno: I have :)
<hno> you have?
<techn> prototype currently
<hno> please push any changes to mnemoc.
<hno> arokux_h, we work on reducing the duplication. But there will always be some, even if there was just one web side for all.
<techn> I'll send patch/push when everything is ok for me.. There is propably still some things to do after that.. I'm currently newbie with kernel coding ;)
<hno> techn, it's fine to push early.
<hno> actually preferred even.
<arokux_h> hno, what component of the kernel has the best chance of accepting in upstream?
<RaYmAn> hno: u-boot actually gets surprisingly far on a13 - it fails completely at mmc, presumably because I'm using it for console and jtag ;)
<RaYmAn> hno: do I need a specific branch to be able to use nand from it? or even just completely ignore storage
<hno> arokux_h, mach-sunXi has reasonable chance. Most drivers not..
<arokux_h> hno, by mach-sunXi, do you mean arch/arm/mach-sun4i/* ?
<hno> arokux_h, yes.
<hno> RaYmAn, I have a wip/explorenand branch.
<hno> but license header on u-boot nand driver have not been updated. Now most of it is the same as in kernel, but need allwinner to slap a suitable license on some u-boot unique files.
ibrah has quit [Ping timeout: 260 seconds]
<RaYmAn> hno: hmm..Aren't they by definition GPL though? :)
<RaYmAn> but I get your point
* WarheadsSE @ #fosscon
<hno> RaYmAn, licensing do no work that way.
<RaYmAn> hno: mm. I guess. But legally speaking, it's either GPL or illegal.
<RaYmAn> given they've released binaries based upon it
<hno> something non-GPL do not get GPL license only because you mix them. What you get is a mess that can not be redistributed in compliance with GPL.
<hno> and only copyright owners can assign license
<RaYmAn> I get your point - and I know technically speaking, you're of course right
<RaYmAn> You just get the urge to say fuck you to GPL violating companies and go "if they can break license, so can I" :) But I know- two wrongs doesn't make a right. :)
<WarheadsSE> it just means they can't rightfully sue you for it
Quarx|2 has quit []
<WarheadsSE> doesnt mean they wont try
Quarx has joined #arm-netbook
<xenoxaos> we may be working with some lawyers to poke at gpl violators for arm targeted devices
<RaYmAn> The issue, as usual, is that most of these chinese companies couldn't care less, because you are so unlikely to 1) even get them in court 2) win in china
ibrah has joined #arm-netbook
ZaEarl has quit [Ping timeout: 252 seconds]
<xenoxaos> we'll still try working with some of them
<RaYmAn> sure :)
<WarheadsSE> True, but when they officially become an american-selling business, they come into our jurisidction
* xenoxaos is actually making headway with via/wondermedia
<RaYmAn> via has a fairly large american side don't they?
<xenoxaos> ya
<WarheadsSE> yup
<WarheadsSE> and now the APC.IO
<WarheadsSE> which is american targetted
<WarheadsSE> ding!
<Boulet> should allwinner open CedarX ?
<RaYmAn> that's probably one of the few things they aren't required to
<Boulet> how so ?
<RaYmAn> there's no evidence CedarX is GPL violating afaik
<Boulet> so they can create .so libraries and not open them because "it seems like" they are not violating GPL ?
<Boulet> i thought as soon as you had a user-mode application, you had to publish its source code, even the dynamic libraries
<RaYmAn> no
ka6sox-away is now known as ka6sox
<arokux_h> the prefix "mach-" means micro arch or what?
<RaYmAn> that's completely wrong
<WarheadsSE> no, thats not how it works
<Boulet> RaYmAn, so someone who creates a dynamic library that is not based on anything does not need to publish its source code ?
<WarheadsSE> just because you link against the glibc does not make it free
<RaYmAn> Boulet: user-mode applications can be any license they want to be. *IF* they use GPL libraries they have to be GPL
<WarheadsSE> re: ati & nvidia video drivers
<WarheadsSE> and *using* does not mean linking to.
<WarheadsSE> if they incorporate the code library.
<RaYmAn> really? that sounds wrong.
<Boulet> RaYmAn, if a main application loads some dyn lib that are GPL and some dyn lib that are non-GPL, the main app needs to have its source code published ?
<RaYmAn> Boulet: yes, read the GPL.
<WarheadsSE> you can use an API without being required to use that API's library
<WarheadsSE> it depends on the licenses really
<RaYmAn> Boulet: it doesn't matter whether it's dynamically loaded or not.
<RaYmAn> Boulet: it depends on license. Glibc for example is LGPL, not GPL.
<RaYmAn> LGPL specifically allows dynamic linking
<RaYmAn> so if you use an LGPL library, you're only required to publish any changes you make to the library itself
<Boulet> i understand, but one could publish the code of a main app that uses GPL stuff, and not publish the code of a dynamically loaded library that is based on nothing
<WarheadsSE> ^ like cedar x
<Boulet> right, so cedar x is not violating anything
<Boulet> ok
<RaYmAn> I believe that's kind of a gray area, lol
<Boulet> well it should not
<Boulet> it should be black or white !
<RaYmAn> legal is never black or white.
<WarheadsSE> nor is morality, so
<WarheadsSE> welcome to earth
<RaYmAn> indeed
<RaYmAn> Boulet: also, keep in mind android is Apache licensed, not GPL.
<RaYmAn> So GPL things do not apply to CedarX
<Boulet> can't you use cedarx libs without android ?
<RaYmAn> probably, but that's not how licenses work
<RaYmAn> I mean, if you make an app that uses cedarx lib and you GPL it, it won't suddenly apply CedarX...
<WarheadsSE> ah the joys of licensing....
<RaYmAn> indeed
<Boulet> it seems really a big pain in the ....
<RaYmAn> really, you need a lawyer to be sure of anything
<Boulet> soon any small software company will need some lawyers to deciphers those things
<Boulet> and he will say "that's a gray area"
<Boulet> and thank you
<RaYmAn> any small software company that intends to "get around" legal licenses to software.
<RaYmAn> Everyone else is fine.
<Boulet> personally, i don't want to get around legal licenses
<Boulet> but i'd like to make sure i understand
<RaYmAn> did you read GPL, LGP and similar? :)
<RaYmAn> that's a good start
<Boulet> too complex for me hahahahah
<Boulet> so i assumed, i'll always give my source code away
<arokux_h> the prefix "mach-" means micro arch or what?
<WarheadsSE> machine
<Boulet> RaYmAn are you going to try that small linux that fits in a ramdisk ?
<RaYmAn> Boulet: yeah, whenever I get a chance to uhm, create my atags. Waiting for Turl ;)
<Boulet> i'm curious to know how fast that thing can boot
<Boulet> although i guess things can be improved, like initializing DDR3 and CPU with faster clocks
<WarheadsSE> eh
<Boulet> i haven't tried to go above 360 MHz yet
<WarheadsSE> my a100 hits console in ~ 4 seconds
<Boulet> and i wonder if one has to play with AXP209 to give more current
<Boulet> WarheadsSE, not bad !
<WarheadsSE> class 10 sd
<Boulet> ah you boot it all from SD ?
<WarheadsSE> yes
<Boulet> neat :)
<Boulet> what file system you have on it
<WarheadsSE> ext4 noatime
<arokux_h> any idea why early_print needed to be changed for A10? https://github.com/amery/linux-allwinner/commit/941fe44a605833895fb5d75a0869237d015dc6b3#diff-4
QingPei has quit [Remote host closed the connection]
tuliom has joined #arm-netbook
gimli has joined #arm-netbook
gimli has quit [Client Quit]
gimli has joined #arm-netbook
gimli has quit [Client Quit]
gimli has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 244 seconds]
tzafrir_laptop has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 240 seconds]
tzafrir_laptop has joined #arm-netbook
ibrah has quit [Ping timeout: 260 seconds]
Vayun has joined #arm-netbook
pwhalen has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 260 seconds]
ka6sox is now known as ka6sox-away
<Turl> ohai RaYmAn ;)
<RaYmAn> hno: here?
<blahee> I did aquire a Alink Smart TV. Runs android by default and of course i did open it. Does have AMlogic AML8726-M (soemthing like 800Mhz Cortex-A9)
Boulet has quit [Remote host closed the connection]
<blahee> That does have a RF-connected keyboard + mouse which does have internal reciver in just internal USB-port, so the keyboard is usable for anything. Tested that the keyboard just works with my PC desktoip too
Boulet has joined #arm-netbook
* xenoxaos is working on the amlogic chip
<hno> RaYmAn, barely here.
* hno is outside at the grill
<RaYmAn> hno: 'k, nevermind :) was just wondering if you knew how much data there were before nanda - the answer is 0xFFFFF bytes
<RaYmAn> hno: also, u-boot compiled for a10 runs just fine on a13 :) Booting from fel after running test1 that is.
<specing> 2M?
<RaYmAn> isn't it more like 1MB?
<specing> yeah, sorry
<RaYmAn> I guess technically speaking it's actually 0x100000 bytes
<RaYmAn> with the last byte being at 0xFFFFF
<Turl> 0x100000 bytes = 1 megabyte
<hno> RaYmAn, you got access to the boot blocks?
<RaYmAn> hno: yes - I just applied the sun4i patch to the sun5i driver
<hno> The MBR one? That's not the boot blocks..
<RaYmAn> oh, hmm
<RaYmAn> I assumed the point of that patch was to expose the full nand
<RaYmAn> but now that you mention it, is does seem completely empty after the MBR data
<hno> It exposes the full logical block device. Below it there is wear levelling, and raw nand. The boot blocks is in the first erase blocks.
<RaYmAn> hm
<RaYmAn> so uhm, is there any way to access those? :P
<hno> sure. just haven't succeded in doing so yet...
<RaYmAn> fair enough
<RaYmAn> heh
<RaYmAn> So I guess I'm not homefree just yet :(
<RaYmAn> The whole point of getting this kernel booting over fel was so I could dump using serial-over-sd without flashing a possibly non-working kernel to device :S
<hno> there is code in the u-boot nand driver tat is supposed to give a reasonable api for accessing those block, but only got garbage when trying to use it
<hno> RaYmAn, you don't need the boot blocks for that.
madmalkav has quit [Quit: Leaving]
<RaYmAn> hno: Can I count on the boot blocks being identical across different a13 devices?
<hno> no, they contain DDR setup etc.
<RaYmAn> cause the issue is, I only have a somewhat generic livesuit image for a13...
<RaYmAn> so if I break it, I can't really recover
<RaYmAn> (well, ok - that's not really true - Now I can that boot kernel over fel, I can really just boot and revert things to stock)
penguin42 has joined #arm-netbook
<RaYmAn> So that works ok :) Can boot kernel, incl. ramdisk from fel
gimli has quit [Quit: gimli]
<Quarx> someone pro in linux kernel modules?
<Turl> Quarx: I'm not 'pro' but maybe I can help?
<Quarx> Turl: yea, i want make KSM module... almost part already in kernek except ksm.c. errors: http://epsy.ath.cx:888/paste/?783 this symbols already in kernel, but how say this to compiler.
<Turl> Quarx: epsy paste not working? :/
<Quarx> linker problems..
<Turl> you need to export the symbols
<Quarx> in ksm.c?
<Turl> EXPORT_SYMBOL(munlock_vma_page) etc
<Turl> in the file where munlock_vma_page is defined and used
<Turl> etc
<Turl> Quarx: for example
<Turl> http://lxr.linux.no/#linux+v3.3/mm/mlock.c#L106
<Turl> add EXPORT_SYMBOL(munlock_vma_page) after that declaration
<Quarx> and i should include this file to obj?
<Turl> hm?
<RaYmAn> Quarx: it's functions your module needs to CALL in the kernel in order to work properly
<RaYmAn> so they need to be available for calling from external => EXPORT_SYMBOL
<Quarx> i added EXPORT_SYMBOL(munlock_vma_page);
<Quarx> recompiled kernel with it, then i tried compile module and got this error again
<RaYmAn> for same symbol?
<Quarx> yes ERROR: "munlock_vma_page" [mm/ksm.ko] undefined!
<RaYmAn> you need to do it for all the symbols it's complaining about
<RaYmAn> you might need to make clean if you haven't
<Quarx> ok, now module compiled without errors, but module can't find this symbols in kernel
<Quarx> <4>[ 930.767181] ksm: Unknown symbol page_address_in_vma
<Quarx> cat /proc/kallsyms | grep page_address_in_vma
<Quarx> c00c084c T page_address_in_vma
<RaYmAn> and you are booting the kernel you just compiled?
<Quarx> i can't use custom kernel...
<Quarx> i can use only modules
<RaYmAn> ok, that's your issue then.
<RaYmAn> You didn't give enough information for us to provide a suitable answer ;)
<Quarx> i'm think me need use SYMSEARCH
<RaYmAn> then you're mostly screwed tbh. Depending on what the missing symbols do, it may or may not be possible to 'reimplement' them in your module - or call them by address if that's possible
<Turl> RaYmAn: that's what symsearch does I believe
<RaYmAn> yeah, I kind of figured
<RaYmAn> :P
<CIA-121> rhombus-tech: Nguyen master * r08429bdbfb27 /allwinner_a10/orders/snowflake.mdwn:
tzafrir_laptop has joined #arm-netbook
<Quarx> yea, symsearch works:)
<Quarx> thanks guys:)
<RaYmAn> what device is it?
<Turl> RaYmAn: defy most likely
<Quarx> yes, defy
gimli has joined #arm-netbook
eFfeM has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 276 seconds]
Quarx has quit []
<hno> RaYmAn, livesuit for A13 should auto-detect your hardware and configure the boot blocks accordingly
tzafrir_laptop has joined #arm-netbook
<RaYmAn> hno: hm, ok.
<RaYmAn> hno: I guess even if it doesn't I should be relatively ok when the test1 app successfully initializes the ram, shouldn't I?
<RaYmAn> hm - I guess if ram paramenters is all that's different, I should be able to dump those from "live" registers after booting with boot0
<hno> RaYmAn, yes
<hno> or use JTAG to dump boot0 after BROM have loaded it.
<RaYmAn> hm
<hno> a breakpoint @0 shuld do the trick.
<RaYmAn> yeah, except that doesn't work :/
<hno> why?
<RaYmAn> it looses connection when device reboots and it seems like it isn't really able to reconnect properly
<RaYmAn> and breakpoints definitely aren't preserved across reboots
<ManoftheSea> loses
eFfeM has quit [Ping timeout: 272 seconds]
<RaYmAn> I guess best bet is replacing uboot with a simple app that just loops forever, so I can break on that and hope that LR is preserved =P
<hno> RaYmAn, not even on a reset triggered via jtag?
<RaYmAn> hno: there's no JTAG reset signal brought out
<RaYmAn> I tried the watchdog reboot method, but seemed to have same issue there
<RaYmAn> so I need a better way to reboot for that to work I guess
<RaYmAn> alternatively, maybe brom doesn't mind running again ;P e.g. just jump to brom entry point
<hno> RaYmAn, I do mean reset via JTAG. You can reset the CPU by JTAG commands.
<RaYmAn> in that case openocd doesn't seem to know about it.
<RaYmAn> The config files I've rummaged through, all either use the jtag RESET pin or per-SoC specific commands for reboot
<arokux_h> hno, sorry for a long break. what is the point of mainlining if there is a little or no chance the code to be accepted upstream?
<RaYmAn> Now you're starting to see why this is a long process.
<RaYmAn> Mainlining == rewriting code to be acceptable
<arokux_h> RaYmAn, no, not only.. for example, wemac driver couldn't be accepted because it is special to A10
<RaYmAn> I'm sure there are plenty of device-specific drivers in kernel already
<RaYmAn> There's just no chance it would be accepted if a10 support isn't already in kernel.
<penguin42> lots of them
<penguin42> it's only a problem if it's obviously a copy of another driver - like if all it took was a slight tweak to another driver then there isn't much point in a whole new driver
_whitelogger has joined #arm-netbook
<hno> I don't think they have touched the NAND controller in a long time.
<RaYmAn> I was considering just removing sun5i driver and setting up hidden compat config's that auto-selects SUNXI_NAND (so current .config's still work)
<hno> For the DRAM controller the most difference is in connection to CCM (clock controller)
<hno> yes, we need to eleminate much of the duplication.
<arokux_h> RaYmAn, so the kernel should be developed per SoC, not per board, right?
<RaYmAn> arokux_h: it's kind of..inbetween
<RaYmAn> obviously SoC support predates board support. With Device tree the per-board stuff has been minimized a hell of a lot
<hno> I would not say it's inbetween. Kernels are developed for SoCs, then mutilated by board vendors.
<RaYmAn> lol
<RaYmAn> well, ideally
<hno> fantastic connection tonight. Been able to view 75% of that linaro video since link was posted here.
gimli_ has quit [Quit: Verlassend]
<arokux_h> hno, you connection is normally not that good?!
<arokux_h> s/you/your
<hno> 10min youtube in 45 minutes. Almost streaming.
<arokux_h> mm.. haven't got it, sorry
<hno> Connection quality varies a lot here. On the edge of 3G connectivity due to a piece of rock shielding me from the radio mast..
<arokux_h> you do not have wired connection?!
<hno> not at the family summer house in stockholm archipelago no.
<arokux_h> ah, ok :)
<hno> at home I have some kind of ADSL which delivers 60% of promised quality.
<Turl> hno: 60% of how much?
<Turl> at my parent's house I barely get 1Mbit ADSL :P
<hno> Turl, of what the operator says they can deliver, so I get about 12Mbit.
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #arm-netbook
<arokux_h> poor you are guys
<Turl> I currently use a 6Mbit cable connection