ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
<hno> as long as you leave the nanda partition alone (or make sure to restore epected files there) you can repartition as you like with nand-part command.
<hno> the MTD u-boot is still a bit experimental and not polished up for general consumption on any device.
<libv> ah, i see
<hno> and should you by accident destroy nanda then just recreate it.
<hno> the tricky-to-install parts of the bootloader is outside the logical nand visible to userspace.
<hno> nanda is just a plain fat partition.
<Turl> apparently you can skip until it says "The next step is to get the Debian system onto the internal NAND."
<Turl> that page needs some headings to make it readable
<hno> And it you try following the first part then you'll destroy your nanda overwriting it with cubieboard data.
<hno> easily fixed by making sure there is the right script.bin.
<hno> Turl, you likely need to repartiition first if not overwriting the whole nand including MBR.
<hno> and changing the u-boot env to boot the epected kernel (+initramfs if any) and bootargs.
<hno> Don't we have a page on manual installation?
<libv> nothing involving nand
<Turl> git rules, Successfully rebased and updated refs/heads/sunxi-clk.
tinti has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
tinti has quit [Quit: Leaving]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<CaCtus491> so, I'm having trouble getting a precompiled image to boot from SD on this A10 board. The kernel loads, but gets stuck at 'Waiting for rood device /dev/mmcblk0p2'.
<CaCtus491> earlier on in the boot, I see: '[mmc_pm]: no sdio card used in configuration' which doesn't sound too good
rz2k has joined #linux-sunxi
rz2k has quit []
BJfreeman has quit [Quit: had a good time]
<Turl> CaCtus491: does your card have two partitions?
<Turl> other than that, I'd check the script.bin mmc configuration
theOzzieRat has quit []
rellla has joined #linux-sunxi
wingrime-android has quit [Ping timeout: 276 seconds]
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 260 seconds]
shineworld has joined #linux-sunxi
n01|afk is now known as n01
rellla2 is now known as rellla
eebrah|away is now known as eebrah
<oliv3r> lo
<oliv3r> Turl: if my driver needs clocks setup, do I need devm_clk_get()? of is ther esome of_ function? Just curious, don't need cocks yet
<oliv3r> cLocks*
booss has joined #linux-sunxi
Tartarus has quit [Ping timeout: 256 seconds]
Tartarus has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
<oliv3r> anbody know where /proc/cpuinfo is 'created/filled'?
eebrah_ has joined #linux-sunxi
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-sunxi
shineworld has joined #linux-sunxi
anunnaki has quit [Quit: Leaving]
eebrah_ has quit [Ping timeout: 252 seconds]
<hno> oliv3r, arch/arm/kernel/setup.c
<oliv3r> we don't have any sunxi specific stuff (yet)?
<oliv3r> i'm after the serial and revision, possibly name too
<oliv3r> ------seq_printf(m, "Serial\t\t: %08x%08x\n",
<oliv3r> >------->------- system_serial_high, system_serial_low);
<oliv3r> found that bit though :)
<hno> then you found the other two as well.
<oliv3r> yep
cajg has quit [Ping timeout: 252 seconds]
<oliv3r> but can those be filled by sunxi stuff, or is it generic arm stuff that we shouldn't touch?
<hno> those are all machine specific.
<oliv3r> yeah, machine, platform, m-architecture, those names are all a little confusing still
<oliv3r> arm being machine, sunxi being platform?
<oliv3r> or is it vice versa?
<oliv3r> Serial, revision, appear to be simple exported ints, name is .. i'll find out ;)
<hno> The machine is declared in plat-suni/core.c
<hno> plat-sunxi/..
<oliv3r> ah ok
<oliv3r> so what is mach-sunxi? (machine or machine architecture?)
<oliv3r> and why do we have both?
<hno> there is no mach-sunxi.
<oliv3r> i only really know that arch is arm, x86 etc
<hno> there is mach-sun4i, mach-sun5i and plat-sunx (plat == platform, common)
<oliv3r> ohh
<oliv3r> so you have the sunxi platform, which consists of mach-sun4i and mach-sun5i, who all have the arm arch
<oliv3r> or rather, arch-arm/plat-sunxi/mach-sun4i I suppose
<oliv3r> thanks hno
<hno> and some code which can't decide where it belongs, like the machine declarations which imho should be i mach-... but right now is in plat-sunxi/core.c
<hno> all three is under arch/arm/
<oliv3r> ok but
<oliv3r> in the mainline kernel, we currently have mach-sunxo
<oliv3r> and no plat-sunxi
<hno> odd.
<oliv3r> mach-sunxi holds restart code only, so in the end, we'd have mach-sun4i/5i for specific details to those, mach-sunxi for things that are unified/generic, and platform-sunxi for?
<oliv3r> or does that need to be renamed?
<oliv3r> mripard: did we miss-name mach-sunxi and should it have been plat-sunxi?
<hno> well, I suppose things are more generalised in mainline, driven by dt.
<oliv3r> ok so then setup of name, revision and serial, should be done in mach-sunxi/core.c (or mach-sunxi/sunxi.c as we have now)
<hno> name of the .c doesn't matter.
<oliv3r> hmm, machine_name appears to be what is setup in the dt
<hno> should be.
<oliv3r> I would have thought there's a field that names the CPU
<oliv3r> system_cpu_name or something along those lines
<hno> the CPU is the ARM Cortex A8.
<oliv3r> I was thinking a field, that would read 'Allwinner A10 (sun4i)' for example
<oliv3r> (well i'd want to make that read it)
<oliv3r> I would have thought we have a field for that; pre-fdt it simply reads 'sun4i'
<hno> That's the machine name.
<oliv3r> but that's parsed from the fdt, I would have guessed it should get that from the chip (id)
cajg has joined #linux-sunxi
<oliv3r> but that's fine, I was mostly after the serial and revision atm
<hno> chip id should be used to set up the dt match table.
<hno> and guess it's appropriate to have revision set to chipid as well.
<oliv3r> hno: not sure what to use for the revision
<mripard> oliv3r: plat-* are being removed, and eventually, only mach-* will be there
<oliv3r> either we can probe the sram controller
<oliv3r> hno: or rather, that new register we exposed; or use 'sid', for the serial i want to use sid
<oliv3r> mripard: I think I've found a use for the sid :)
<hno> serial is sid.
<oliv3r> mripard: grep serial /proc/cpuinfo
<oliv3r> hno: not only, but it's to big to fit into /proc/cpuinfo; it also contains chip 'id' sort of
<mripard> ok
<oliv3r> hno: our serial is 128bit, and serial is only hmm, maybe it does fit, serial is only 2 bytes
<oliv3r> erm does nto*
<oliv3r> not*!
<oliv3r> mripard: what do you want me to do with the msb/LSB thing? I simply made the output match what u-boot told me
<mripard> I already told you what I wanted.
<oliv3r> make it print MSB, even it it then no longer matches what u-boot tells us?
<oliv3r> i'm fine with that, i even said, in the end, it doesn't matter much how it is represented
<oliv3r> as long as its consitant
<hno> system_serial is 64-bit. system_rev is 32-bit (but formatted as 16-bit)
<mripard> byte 0 would be bits 0-7, byte 1 8-15, etc.
<mripard> -> LSB first
<oliv3r> mripard: ok, then i'll do that
<oliv3r> for system_revision?
dl9pf has quit [Ping timeout: 240 seconds]
<hno> oliv3r, thats for revisions of the A10 only.
<hno> we also need to indicate A10/A13/A20/whatever somehow.
<oliv3r> hno: very true :S i'll leave that up for mnemoc SoC detect
<oliv3r> hno: ideally, we'd ask the question to allwinner, if this is somehow stored in the SID
<hno> oliv3r, my understanding is tha the SID is fully programmable.
<oliv3r> I agree
<hno> but we already have the chip id.
<mnemoc> but chip_id only gives the sunNi part
<hno> are you sure? What is returned on A10s?
<mnemoc> same as A13
<oliv3r> well the full chip id, is 162542, 162541, 162565 etc actually
<oliv3r> and we don't even know what A12 is :)
<oliv3r> but there exists A12
<oliv3r> though chipid for a13(a/b) is the same for A12(a/b)
<mnemoc> and same for A10s(a/b)
<oliv3r> in 'sid' we _should_ atleast have the "die bonding id"
<mnemoc> the soc-detect branch dumps the sid when fails to detect
<oliv3r> ideally; we'd want a shitload of sid dumps
<oliv3r> to compare them at the very least
<mnemoc> that's the point
<oliv3r> but other then my tablet/cubie; i have nothing else
<oliv3r> and nobody has reported any id's
<mnemoc> wingrime also suggests to dump a checksum of the brom
<oliv3r> we'd need a wiki page with a table for people to fill in
<hno> If the SID is programmable then it's not good for chip id detection.
<mnemoc> allwinner uses SSE reg to distinguish sun5i socs
<mnemoc> and SID only for the rev
<hno> where is that allwinner code?
<oliv3r> very true; but we don't know how to program it yet, so for now, it's all pre-programmed :(
<oliv3r> mnemoc: SS* (it is renamed later to match the datasheet)
<oliv3r> mnemoc: i was reading that SS register check, it looks like they check "A disable on this bit overrides any other block and flushes all FIFOs." bit from what I saw
<oliv3r> no wait
<oliv3r> i saw wrong
<oliv3r> the 'die bonding id' is also in the SS bit
<oliv3r> they check the 'key size for aes' default parameter, 128-bits is default for a12; 192-bits is default for A13
<oliv3r> of course, once you engage the crypto engine, and set it to 256-bits, that function no longer works reliably
<oliv3r> that sun7i link is a20 sdk
<oliv3r> which is the same still
<oliv3r> funny fact is, that that file (name) is new, yet content all lists a10s, a12 and a13 code; not even a10/20
egbert has left #linux-sunxi [#linux-sunxi]
<mnemoc> let's get soc-detect working for a10/a13/a10s first and then we care about other socs :p
<mnemoc> chip-id is enough for early detection, per-soc is only needed by higher level drivers
<mnemoc> and we can finally unify sun[45]i entirely
<mnemoc> to the level of same-bin probably
<mnemoc> any news from olimex's a10s boards?
<oliv3r> how will this soc detect thing work on 3.9+
<mnemoc> mainline doesn't want magic. only dtb :(
<oliv3r> i mean, DT describes hardware, but, looking at sunxi-audio for example
<oliv3r> that driver works on both platforms, but may have certain differences
<oliv3r> only audio in, only audio out
<oliv3r> just to name something
<oliv3r> how is that handled with dt?
<mnemoc> in soc-detect I have sunxi_is_a13() ... macros
<mnemoc> oliv3r: using the compatible with string
<oliv3r> ok, i guess I should see how the dts defines what you have available then
<oliv3r> audio in/out in this example
<hno> mnemoc, are you absolutely sure mainline do not want chip revision magics? Some things can't fly without it.
<oliv3r> i would have thought so too hno, but i'm far from an expert
<hno> imho it should be an input to the dtb to select compatible nodes.
<mnemoc> hno: revsision magic is probably mandatory on code, only soc can be given from .dtb
<oliv3r> well you'd want revision magic to define system_rev?
<oliv3r> i mean, if you have 1 board, 1 kernel, 1 dtb, but different revisions soc (since that's what you are supplied with)
<oliv3r> and no way to check your stock (your not gonna check revisions and write specific dtb for 1 half of your 2 mil stock)
<hno> or ask customers to carefully verify the serial number before they apply the next software upgrade (including dtb)
<oliv3r> what if you don't have a serial number, our SoC's currently all read 0
<oliv3r> cubieboards don't have a serial
tinti has joined #linux-sunxi
<hno> I would stuff SUNXI_VER_xxxx into system_rev.
<oliv3r> that's what I said too; but then you'll need soc_detect() :p
<oliv3r> and thus magic in mainline :D
<oliv3r> hno: as for system_serial; we have 128 bits, and only 64bits available. only output the 64 LSB, do some 'compression' on them? any idea?
<hno> yes, and I would not think that magic as such is a problem. But should use the DTB to find the registers.
<hno> oliv3r, no bright idea.
<hno> leave it unset for now. Not sure SID is appropriate there. It's also meant to be used as encryption key and what not.
<oliv3r> 'from the factory' they do appear set something that resembles a serial
rz2k has joined #linux-sunxi
dl9pf has joined #linux-sunxi
dl9pf has quit [Changing host]
dl9pf has joined #linux-sunxi
rz2k has quit []
<hno> oliv3r, yes, and also includes chip id. Didn't notice that before.
<mnemoc> anyone with an A10S around?
<oliv3r> theres (from the factory) quite some interesting info there
<oliv3r> i should really e-mail aw and ask if they could give us some details what is stored in there
<andoma> what's the status of linux for A10s these days?
<oliv3r> hansg is working on it afaik, but it's getting there, slowly however
<mnemoc> andoma: if you can help testing it will improve faster, we don't have hw
<mnemoc> uart required
<andoma> i've never been able to figure how to solder an UART on the a10s sticks i've got
<mnemoc> :(
<oliv3r> mnemoc: did you read about libv and my talk about fosdem 2014 yesterday?
<mnemoc> oliv3r: i saw the traveling costs part only
<oliv3r> backread the 'devroom' section :p
<mnemoc> timestamp?
<hno> 01c23800: 16236747 80728452 50574848 064163d5 Gg#.R.r.HHWP.cA. (cubie)
<hno> 01c23800: 16254147 50475838 36313030 0341b75d GA%.8XGP0016].A. (A13 OlinuxIno)
<hno> Looks like only the last 32-bit is unique. the middle part seems to be a string on A13, and even the last 32 bit isn't very keyish. Do not look random.
<hno> 01c23800: 16254158 504b4e39 35303030 0a0185f5 XA%.9NKP0005....(A13 OlinuXIno)
<hno> 01c23800: 16254159 50475838 36313030 0b4181e9 YA%.8XGP0016..A. (A13 OlinuXIno)
<oliv3r> that is from u-boot it assumes
<oliv3r> i'll copy paste that info into a table on the wiki
<hno> yes it's md.l from u-boot.
<oliv3r> md 0x01c23800 1
<hno> sunxi#md.l 1c23800 4
<hno> 01c23800: 00000000 00000000 00000000 00000000 ................
<hno> hmm...
<oliv3r> erm, 4 yes
<oliv3r> reset it :p
<hno> thats from the mele.
<oliv3r> btw, MSB are interesting, seem to match A10, A13
<oliv3r> even the '41' bit for the revision seems to be there
<hno> never seen anything but 0 on the mele.
<oliv3r> i don't have a melee
<oliv3r> soc_id fails or they have special kernel
<oliv3r> mnemoc: dont' you have a mele
<hno> oliv3r, kernel not loaded
<oliv3r> well with u-boot no; but once you load the kernel ..
<mnemoc> oliv3r: had 2. none with me atm
<oliv3r> hno: you could try my kernel, it exposes sid in sysfs;
<oliv3r> that one should work iirc
knoppix has joined #linux-sunxi
<mnemoc> oliv3r: could you add a sunxi-sid to 3.4?
knoppix has quit [Client Quit]
<oliv3r> mnemoc: not sure how to backport it :p
LoCoZe has joined #linux-sunxi
<oliv3r> mnemoc: but once it's accepted by mripard; absolutly, haven't had feedback in a few days, so I"ll resubmit v2 very soon
LoCoZe has quit [Client Quit]
LoCoZeNoz_ZUE has joined #linux-sunxi
<hno> oliv3r, i kind of doubt another kernel makes much difference if reading the registers returns all 0
<oliv3r> hno: i completly agree
<oliv3r> hno: but even audio drivers have machine_sun4i() stuff in it
<oliv3r> well i guess melee could be using custom built kernel or something
<hno> There was nothing using the SID in 3.0.8 kernel from what I can recall.
<oliv3r> i'll check a really old AW lichee tree
<mnemoc> 2.6.36 had sid stuff in /proc/cpuinfo
<oliv3r> really?
<oliv3r> i'm looking at that tree right now
<hno> Current A10 3.0 tree only checks the CCM register for A10 revision.
<hno> err TIMER regiser.
<oliv3r> 0x13c; but only partially, no
<hno> yes
<oliv3r> that only gives 'chip revision' but hardly anything reasonable
<oliv3r> why can't i grep on github :S
<hno> what do you mean?
<oliv3r> those 2 bits, is only 'rev A, rev B, rev C1 or rev C2'
<hno> yes. but it's already known it is an A10.
<hno> in that tree.
<oliv3r> well back then, they didn't have anything else
<oliv3r> fair nuff
<oliv3r> maybe you accidentally somehow earased your sid!
<hno> From what I remember it showed a SID 0 from first day.
<hno> it is printed by the kernel.
<oliv3r> ah ok
<hno> #ifdef CONFIG_ARCH_SUN4I
<hno> seq_printf(m, "Serial\t\t: %08x%08x%08x%08x\n", chip_id.sid_rkey3,
<hno> #else
<hno> seq_printf(m, "Serial\t\t: %08x%08x\n",
<hno> chip_id.sid_rkey2, chip_id.sid_rkey1, chip_id.sid_rkey0);
<hno> system_serial_high, system_serial_low);
<hno> #endif
LoCoZeNoz_ZUE has quit [Remote host closed the connection]
<oliv3r> indeed
<oliv3r> need someone else with a mele now :(
<oliv3r> hno: that in arm/kernel/setup.c? i would say that's quite nasty, no?
<oliv3r> hno: i take it you've sent back the emo68 allready?
<oliv3r> those A13's all completly identical?
shineworld has quit [Read error: Connection reset by peer]
shineworld has joined #linux-sunxi
<hramrach_> I have serial 0 on cubie
<hno> oliv3r, yes the EOMA68 is sent. But it's just another A10 device, only a bit newer than the cubieboard.
<hno> The A13 is at least 2 different runs. 2 have identical chip markings and is likely from the same order batch or very close in time. The third is much newer and have a different chip marking.
<oliv3r> could explain the bigger difference in keys
<mnemoc> hno: does the rev detection code in soc-detect works on those?
<hno> The first is the an early A13 OLinuXIno Rev-A boart. The second is a early Rev-C and the third is a fairly recent Rev-C.
<oliv3r> hramrach_: could you boot 'u-boot' and run md.l 0x01c23800 4
<hno> mnemoc, haven't tried yet.
LoCoZe has joined #linux-sunxi
LoCoZe is now known as LoCoZeNoz_ZUE
* hno starts an A13 kernel build
hipboi|cubie has joined #linux-sunxi
<hno> hi hipboi|cubie
<oliv3r> Hey tom
eebrah is now known as eebrah|away
<hno> oliv3r, same result in a 100% controlled boot via FEL, using the exact same SPL + u-boot on both mele and cubie. 0 on mele, filled in on the cubie
<oliv3r> maybe it has been accidentally reset?
<oliv3r> hno: but 'ouch'
<hno> I think it was never programmed.
* hno is preparing to play with the program register a bit.
<oliv3r> what's the worst that can happen ;)
<hno> that I lock the device.. there is some hints that there is JTAG secirty flags and other stuff there..
<hno> but it has done it's purpose already, so..
<oliv3r> the only thing really missing now, is where the 32 bits are stored that get written
<oliv3r> i haven't done a 'fill all with 1' thing, was a little hesistant
<hno> There is a register at 0x40.
<hno> but have not managed to program the SID on the mele yet.
<oliv3r> i bet those 32bits get programmed to macrocell 0-3
<hno> very likely.
<hno> but something more seems to be needed.
<hno> and the control register have 4 bits for addressing. That's 16 addresses.
<oliv3r> so filling 0x40, then setting 1 to 0x44 isn't enough?
<oliv3r> well only 16 attempts required :)
<oliv3r> btw, the manual doesn' say how the addressing works, just says 'program index, value of 32-bits elecitrcal fuses harware macrocell'
hglm has joined #linux-sunxi
<hno> oliv3r, yes, but nothing happens other han bit 0 getting cleared.
<oliv3r> :S
paulk-desktop has joined #linux-sunxi
* slapin_nb loudly rants about monkeys, stm32, chibios, freertos and deadlines
<slapin_nb> hi, all!
<oliv3r> slapin_nb: did you make your encoder deadline :p
<oliv3r> hi slapin_nb !!
<slapin_nb> oliv3r: I have pulled the deadline till after next weekend
<oliv3r> lol lucky :)
<slapin_nb> hno: you can easily replace the processor if you manage to lock it down
<shineworld> I don't know what happens. I've set cubieboard_defconfig to support HID and Mouse works but none about PenMouth USB touch screen:
<shineworld> Logitech mouse is see and /dev/input open but not for penmount touchscreen (I've checked on firmware the VID AND PID are right)
<hno> mnemoc, did I compile kernel wrong or is things broken on A13? <6>chip-id: Unknown (AW1625)
<mnemoc> hno: that means the detection failed, can you give me more output?
<hno> What output do you want?
<mnemoc> the first "page" of printk()s
<mnemoc> don't know.. 20 lines?
<mnemoc> it should have dumped the sids too, maybe something extra
<mnemoc> is it the same with all your A13-s ?
<mnemoc> amery's wip/sunxi-3.4/soc-detect ?
<hno> Erhm... no. This is stage-3.4
<mnemoc> :)
<mnemoc> wip/sunxi-3.4/soc-detect is based upon stage/sunxi-3.4, but the stuff is there. not in stage until tested. cleaned. submited for comments :)
<hno> so is it good or bad that stage/sunxi-3.4 crashes for me on A13?
<mnemoc> i suppose it's bad
<mnemoc> there is a pending patchset from hangs which might fix things. haven't been able to look at it yet
<oliv3r> mnemoc: is that the audio patchset?
<mnemoc> yes
<oliv3r> cause that's been pending for a few months
<mnemoc> there is a new one
<oliv3r> hangs, me, hansg :)
<oliv3r> yeah, he rebased it, but left out my fixes
<mnemoc> :p
<oliv3r> so you need to merge the patches; then apply :D
<oliv3r> though I think mine should still apply cleanly
<oliv3r> haven't seen many patches on ML
<mnemoc> i kind of want to get soc-detect in before adding more unification...
<mnemoc> #ifdef exceptions stink
<mnemoc> and can't deal with a13 vs a10s
<hno> mnemoc, ok, runnin a new test, this time using your soc-detect branch (ceecaa4b235b4c1cf10ab2c49463222e738fcfe0) and sun5i_defconfig.
* hno needs a better kernel build host..
<mnemoc> a13_defcinfig can be better
<mnemoc> I'll give you access to my build server in 15m. walking back to the hostel
wingrime has joined #linux-sunxi
<wingrime> mnemoc: are you here:
<wingrime> ?
<hno> wingrime, see two lines up.
<hno> ah, you joined after.
<hno> he will be back in maybe 10 min.
<shineworld> YEAH WORKS !!!
<shineworld> Penmount 1201 multitouch screen capacitive works fine on cubieboard
<hramrach_> oliv3r: don't have anything to connect the serila console atm
<hno> mnemoc, not much better.. still fails to detect the A13 proper, and then a little later the board resets when USB power gets enabled.
<mnemoc> hno: paste?
<hno> mnemoc,
<mnemoc> hno: what rev of A13 is this?
<hno> This is the A13 OlinuXIno micro Rev-A board. Not sure which A13 rev it is.
<mnemoc> may you do the same with your other A13-s ?
shineworld has quit [Quit: Leaving]
<mnemoc> well... not yet
<mnemoc> wingrime:
<hno> not now. Need to go.
<mnemoc> hno: please poke me when you are back.
<wingrime> mnemoc: have we some boot menu?
<mnemoc> not that I know
<wingrime> also I now load new stage-4.3 and test wifi soon
<wingrime> mnemoc: only clock are in /arch/arm/march[54] are not merged
<wingrime> what do you do when it will be merged with this dirs
<wingrime> to plat-sunxi
<mnemoc> have very slim mach-sunNi :p
<wingrime> sun[45] look like will be empty
<mnemoc> until soc-detect we will keep relying in CONFIG_ARCH_SUNnI
<mnemoc> so we can't wipe them out
<wingrime> unite kernel will be very cool
<wingrime> what do you think about it?
<wingrime> next patch will do some rework dma
<mnemoc> those chunks count as "documentation" until there is a proper implementation :(
<wingrime> I make some dma rework
<wingrime> I removed unused "irq pooling"
<wingrime> and "half done" dma event callback
<mnemoc> if you turn the half done into done it's better than removing the half we have :p
<wingrime> menemoc: simply say even without half done , do callback in IRQ context is realy crap
<mnemoc> true
<wingrime> half done not used
<mnemoc> but it's reference code for "fully done"
<wingrime> there is full done callback
<wingrime> that normaly used
<mnemoc> so you don't want to finish the dma support? :(
<wingrime> I wait normal driver form mripard
<wingrime> and can help with integration
<wingrime> current driver have problems like 1) IRQ callbacks that allow call some dma_add functions that make IRQ handler check two times that changed
<mnemoc> fix it :)
<wingrime> DMA driver must be like
<wingrime> mnemoc: emac add new request in dma callback
<wingrime> mnemoc: Finite state machine mean that one function change dma_engine state ONCE
<wingrime> 1) in dma_add request 2) in irq
<mnemoc> can't follow you atm, but if it's broken, fix it
<wingrime> mnemoc: not so easy it connected with 1) emac 2) nand 3) sound
<wingrime> and more
<mnemoc> and if I still have pending patchsets from you, please tell me date and subject to merge them today
<mnemoc> :(
_BJfreeman has joined #linux-sunxi
<wingrime> don't remember anything
<mnemoc> good
_BJfreeman is now known as BJfreeman
<wingrime> also I may be need make some patch "shutup wifi" dmesg spam every 3 min
<wingrime> and more important I don't know why, but Xorg make hung on resume
<mnemoc> hno: btw, the "please poke me when back" is about ssh access, not soc-detect experiments
<wingrime> but only on debian
<wingrime> mnemoc: how about make normal mailman?
<mnemoc> it's on the TODO
<wingrime> hopefully wait
<mnemoc> it's annoying they want a dedicate domain and can't deal with multiple domains decently
<wingrime> now I thinking about merge clock from sun4i and sun5i
<mnemoc> and /me back at paying bills :p
<Turl> hipboi|cubie: nice cubieboard cluster :)
<mnemoc> very colorful :p
<Turl> I wanted to see if they were a10 or a20 cubieboards but the green led blinds the camera on all the pics :P
n01 has quit [Quit: leaving]
rellla has quit [Remote host closed the connection]
<wingrime> crap, my wifi still not in def_config
rz2k has joined #linux-sunxi
<wingrime> │ This is the driver for Realtek RTL8192CU/RTL8188CU 802.11n USB
<wingrime> USB can't be CU
<wingrime> "C" means CPIO
<wingrime> EU is usb
sanka has joined #linux-sunxi
<rm> wingrime, Bus 004 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
<rm> in lsusb on MK802
<rm> is it not USB?
<mnemoc> *g*
<wingrime> strange
<wingrime> I have eu8188
<mnemoc> hopefully they work with the same river
<mnemoc> driver
<wingrime> we have both ))
<wingrime> both driver
<wingrime> strane
<wingrime> I just test stabe 8.0
<wingrime> 3.9
<wingrime> sorry
<wingrime> 3.0
<wingrime> than checkout stage-3.0 and enable PM and both drivers
<wingrime> and can't boot
mdp has quit [Quit: ZNC -]
mdp has joined #linux-sunxi
<rm> The Realtek RTL8192CU-GR is a highly integrated single-chip MIMO (Multiple In, Multiple Out) Wireless LAN (WLAN) USB 2.0 network interface controller
<wingrime> i find reason
<rm> but sure, realtek model naming is somewhat confusing
<wingrime> Tumb2 kernel option are broken
<mnemoc> we use thumb2 on defconfig?
<mnemoc> is that a "upstream" problem or something in the sunxi code?
<rm> there is "Compile kernel to Thumb2 (EXPERIMENTAL)", I don't think anyone does
<rm> but there's also "Enable Thumb2EE Support", which is I suppose good and I enable it
<mnemoc> and not experimental :p
<Turl> we were discussing that the other day here :P
vinifm has joined #linux-sunxi
sanka has quit [Quit: Leaving]
Undertasker has joined #linux-sunxi
dragonn has joined #linux-sunxi
<dragonn> ssvb, hi! I have a question. I have have wrong brighnets on xbmc when using libhybris libs for video. Could this be connect with that I use a DVI monitor (on Android I had on it problems with colors too)
<ssvb> dragonn: is the brightness correct without libhybris?
<dragonn> ssvb, yes, with the native linux lib it is ok
<ssvb> also there is a known problem with wrong colors (blue tint) in xbmc, exiting from xbmc and restarting it makes the colors correct again
<ssvb> can you try this "workaround"?
<ssvb> exiting via standarx xbmc ui (not killing the xbmc process)
<dragonn> ssvb, no the colors in xbmc are ok, only the video brightness are wrong
<ssvb> yes, if restarting xbmc does not help, then it really could be some different problem
<dragonn> ssvb, oh yes, this helps, but the problem isn't existing when using the native linux
<dragonn> well this a litte bit werid.... and killing it doesn't help? I need a workaround for this problem
<ssvb> it's some sort of poorly reproducible bug (happens with the native library and libhybris), probably related to buggy cedarx hardware initialization in xbmc
<ssvb> afaik nobody has seen it with vlc yet
<dragonn> For my it only happens with the libhybris one
<dragonn> Well maybe rellla can help, I will ask him
<mnemoc> evil unhelpful ssvb
<mnemoc> shame on you
<ssvb> :)
_BJfreeman has joined #linux-sunxi
BJfreeman has quit [Read error: Connection reset by peer]
_BJfreeman is now known as BJfreeman
nove has joined #linux-sunxi
BJfreeman has quit [Excess Flood]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
wingrime has quit [Ping timeout: 260 seconds]
<Turl> ssvb: I'm running membench on the idlest cubie running mainline*
<oliv3r> 162367c7 80778052 50554848 0201ddc3
<oliv3r> copy paste fial :(
<ssvb> Turl: thanks, looks interesting, there is some strange pattern in the latency benchmark
booss has quit [Ping timeout: 252 seconds]
<drachensun> does any one know a good doc for this platform stuff in the kernel?
<drachensun> my sun6i merge is getting a little bogged down with it
<mnemoc> drachensun: baby steps, don't try to make one fat/full integration
<drachensun> I just copied the mach-sun6i directory over
<drachensun> and I'm trying to get it to compile
<mnemoc> ok
<oliv3r> added a new A10, if more people can do that from u-boot, we can start building a database-ish
<drachensun> so I've had to basically disable all the drivers, which I guess is expected since they all seemed to be swapped over to platform
<mnemoc> btw, can you give me a dump of the SC (SRAM) registry from the stock system?
<drachensun> oh yeah, I forgot you had asked for that, ok let me do that quick while I'm stuck
<mnemoc> btw^2, you might want to look at `git diff reference-3.3..import/lichee-3.3/a31-dev -- arch/arm`
<mnemoc> on my github
<mnemoc> they don't only touch the mach-sun6i dir
<drachensun> I just figured it was a good starting point
<mnemoc> reference-3.3..import/lichee-3.3/a31-dev is a better starting point
<mnemoc> you'll see only sun6i stuff, but all of it
<drachensun> yeah, that would be good
<mnemoc> that's why I made that reference branch and rebased the -dev ;-)
<drachensun> I'm trying to merge it into the 3.4 stable
<mnemoc> sure, that's the goal
<mnemoc> but DON'T merge the SDK vomit
<mnemoc> look at `git log reference-3.3..import/lichee-3.3/a31-dev` first
<drachensun> when I was trying to do the lichee kernel, all the drivers not used in Android were just useless, which I think is the state they were in when the sun4i code was first out right?
<mnemoc> give me my registry dump, and then look at that git log :)
<drachensun> ok, I'm u-boot
<drachensun> what addresses do you want again?
<mnemoc> mb.l
<mnemoc> 1m
<mnemoc> 0xf1c00024
<mnemoc> err... from u-boot change the f to a 0
<drachensun> ok so md.l 0x01c00024 1000000
<mnemoc> 1000000???
<drachensun> 1m?
<mnemoc> nah, just 1 long
<drachensun> 1m was just doing one word at a time.
<drachensun> oh
<drachensun> heh
<mnemoc> 1m = 1 minute, let me search
<drachensun> ahh ok
<drachensun> 01c00024: 00000700 ....
<mnemoc> can you write from u-boot too?
<mnemoc> please write ffffffff to it and read again
<drachensun> ok
<oliv3r> thumb2 and thumbEE both don't work
<drachensun> 01c00024: 16338700 ..3.
<mnemoc> 1633... interesting :)
<mnemoc> thanks!
<oliv3r> drachensun: can you also do a sid dump from u-boot? md.l 0x01c23800 4
<drachensun> no problem
<drachensun> oliv3r sure
<drachensun> all 0
<oliv3r> ok
<mnemoc> oliv3r: sure they have the same base?
<oliv3r> if you have time for other devices (sun[4-7]) then dump those too :)
<oliv3r> mnemoc: i belive so, but i'll double check
<mnemoc> i thought I was been greedy thinking the SC reg would be in the same place
<oliv3r> mnemoc: let me check those registers in the sun6i platform.h
<mnemoc> having chip-id in the same place is amazing, after that we can do all the needed magic to support multi-sunxi
<mnemoc> if A31 has it there, A20 will too
<drachensun> cool
<oliv3r> A20 will have it more likly there
<oliv3r> SID is at the same location on A31
<mnemoc> but all zeros?
<mnemoc> .oO
<oliv3r> so it's either all 0, like on hno's mele
<oliv3r> or ... they don't set it anymore
<oliv3r> or, they didn't correct the address in platform.h
<oliv3r> or, it's not there anymore :)
<mnemoc> oliv3r: try to make tom get this info
<oliv3r> drachensun should have made a full 0 - 0x1d00000 dump or sumat :)
<mnemoc> at least to confirm the address
<oliv3r> change aw163x to sun6i
<drachensun> ok
<oliv3r> confirms the aw16333
<oliv3r> drachensun: thank you for trying :)
<drachensun> what address block is of interest
<drachensun> I can dump whatever pretty easily right now
<mnemoc> oliv3r: yes :)
<oliv3r> md.l 0x01c00000 0x20
<drachensun> 01c00000: 7fffffff 00001300 00000000 00000000 ................
<drachensun> 01c00010: 00000000 00000200 00000000 00000000 ................
<drachensun> 01c00030: 00000000 00000000 00000000 00000000 ................
<drachensun> 01c00040: 22222222 22223a22 00000000 00000000 """"":""........
<drachensun> 01c00020: 00000000 16338700 00000000 00000000 ......3.........
<drachensun> 01c00050: 00000000 00000001 00000001 00000000 ................
<drachensun> 01c00060: 00000000 00000000 00000000 00000000 ................
<drachensun> 01c00070: 00000200 00000000 00000000 00000000 ................
<oliv3r> md 0x01c20e00 3
<oliv3r> oh, that's different
<oliv3r> interesting that your chip ID is on
<mnemoc> oliv3r: I just made him turn it on
<oliv3r> oh do'h
<oliv3r> gonna see what my 01c00040 says there
<mnemoc> 00000700 | ffffffff -> 16338700
<oliv3r> you made him write 0xffffffff ... true
<oliv3r> i'll write 0b8 to it and see, then fff
<oliv3r> 0b15*
<oliv3r> 01c00024: 16238100 ..#.
<oliv3r> doesn't make a difference, if you write 0xffffff or 0x8000
<oliv3r> good to know
<mnemoc> the 100 vs 700 can be related to the different boot pins the A31 has
<oliv3r> 16238 is the chip id
<oliv3r> yeah i think so too
<mnemoc> 1623 only
<oliv3r> drachensun: you have the EV board don't you
<oliv3r> are the boot_sel pins mapped in any way?
<oliv3r> I would assume so, I would expect it to be done using jumper caps?
<oliv3r> drachensun: can you play with those jumpers and then md 0x01c00024 1 again?
<oliv3r> that '7' should change
rz2k has quit [*.net *.split]
drachensun has quit [*.net *.split]
awafaa has quit [*.net *.split]
MadSpark has quit [*.net *.split]
<oliv3r> net split, really? now :(
<mnemoc> hehehe
<mnemoc> anyone with a A13 or A10S around to give a run to wip/sunxi-3.4/soc-detect ?
<mnemoc> (which now support A31!)
<ZaEarl> I have an A31. how do I build/run it?
<mnemoc> ZaEarl: it's only the chip-id detection, it won't boot an A31 :)
<ZaEarl> can I run it in android?
<mnemoc> eh?
<ZaEarl> is it an app or a full kernel?
<oliv3r> full kernel :)
<oliv3r> but it doesn't run on A31 yet :(
drachensun has joined #linux-sunxi
<ZaEarl> ah, ok
<oliv3r> wb drachensun
<oliv3r> to reitterate
<oliv3r> thanks for that output
<oliv3r> could you a) md 0x01c20e00 3
<oliv3r> i'll wikify that
<oliv3r> and you have the EV board, correct?
<oliv3r> does it have jumper caps, dipswitches or the like for 'boot_select'?
<oliv3r> and everybody went quiet
<oliv3r> mnemoc: for your backreading pleasure:;
<Turl> :)
<oliv3r> hey turl
<drachensun> 01c20e00: 00000000 00000000 00000000 ............
<Turl> sup oliv3r :)
<drachensun> they didn't give me anything describing the dip switches
<oliv3r> drachensun: ty
<oliv3r> but there are some?
<drachensun> so it has some, but I dont know exactly what they do
<oliv3r> what'st he silk mask say?
<drachensun> Iheh
<drachensun> sw1
<drachensun> sw2
<drachensun> sw3
<drachensun> sw4
<drachensun> :)
<Turl> oliv3r: I discovered why the mmc clock implementation was claiming it was being sourced from osc24M - I forgot to set up all the parents on the mux :P
<drachensun> I had thought of that
<oliv3r> then they are probably gpio's or the like
<oliv3r> Turl: *facepalm*
<oliv3r> drachensun:
<drachensun> I'm still supposed to get one of set of files from wits
<Turl> oliv3r: it's actually being sourced from pll6, which I didn't implement yet :p
<oliv3r> See the A31 boot diagram?
<oliv3r> Turl: what clocks do we have atm? i'll wikify it
<Turl> on mainline?
<oliv3r> yeah
<oliv3r> Turl: just so that we know what drivers can be worked on (as some depend on clk)
<drachensun> oliv3r: yes, I have seen the diagram
rellla has joined #linux-sunxi
<oliv3r> drachensun: well those boot_sel pins, are 'somewhere'
<drachensun> sure, they still aren't of any interest
<oliv3r> OSC24MHZ, OSC32KHZ, PLL1
<drachensun> they wont let it boot from sd0, the fel boot button does that and I know where it is
<oliv3r> drachensun: well those boot_sel pins, somehow relate too md.l 0x01c00000 1
<oliv3r> drachensun: well those boot_sel pins, somehow relate too md.l 0x01c00024 1
<drachensun> ok
<oliv3r> that reads '7' or chipid'7'
<oliv3r> which most likly is related to them
<oliv3r> it's 2 bits, so probably 2 jumpers or something
<mnemoc> 7 = 0b0111
<oliv3r> yeah
<oliv3r> 1 bit for u-boot (fel pin)
<mnemoc> on A1x we get just a 1, so he has another 2 pin "buttons" pressed
rellla has quit [Client Quit]
<mnemoc> or actually, not-pressed
<oliv3r> oh! i want to test that
<oliv3r> yep, confirmed
<oliv3r> pressing makes the bit go to 0
<mnemoc> :)
<mnemoc> the logic of the other two should be the same
<oliv3r> yeah
<oliv3r> i'l bet you 10 bux it's just that
<oliv3r> though hipboi's bootchart is invert
<mnemoc> drachensun: see? it's important for us you press those pins :)
<oliv3r> but he doesn't know those pins :(
<oliv3r> mnemoc: did you backread? :p
<mnemoc> oliv3r: what exactlyI should read from there?
<drachensun> basically, I don't know the pins
<mnemoc> find them ;-)
<drachensun> they aren't labelled in the docs
<drachensun> heh
<drachensun> well I'm not going to start making electrical connections at random on my new $1600 board
<mnemoc> they are probably small buttons like the fel or power of the cubie
<mnemoc> drachensun: they must be buttons as (at least UBOOT) is required to flash the device or boot form uSD
<drachensun> I know where uboot is
<drachensun> I can press that and read
<mnemoc> go
<drachensun> sure enough
<mnemoc> no schematics of your $1600 toy?
<drachensun> 01c00024: 16338300 00000000 00000000 ..3.........
<drachensun> when pressed
<mnemoc> order is inverted...
<mnemoc> that was unexpected
<oliv3r> what makes you think that?
<drachensun> well I know why I didn't find the buttons on the board refence sheet
<mnemoc> 7 -> 3
<oliv3r> 0x300 is 0b011
<drachensun> they were in the schematic, good though you had, they are setup as soldered in resistors
<oliv3r> (on those 3 intersting bits)
<drachensun> you can unsolder to change
<oliv3r> ah
<mnemoc> as UBOOT is 0b001 on A1x, I expected 0b110
<oliv3r> one more thing
<oliv3r> ohh, wait, so its 0b011 while pressed, 0b111 when depressed
<oliv3r> so the shuffled some bits around
<mnemoc> that's what I meant
<oliv3r> 0b011 are the boot_sel bits for sure
<mnemoc> yes
<oliv3r> mnemoc: read UP btw
<mnemoc> oliv3r: how many lines?
<mnemoc> why the heck my Makefile says 3.4.29, git status says nothing is modified and git log says I'm on 3.4.43???!
<Turl> mnemoc: and git branch says?
<mnemoc> stage/sunxi-3.4
<Turl> git log Makefile? :P
<mnemoc> b375a75787daf96b7c6bfae272edb2720a9fedfc Linux 3.4.43
stekern has quit [Ping timeout: 264 seconds]
<mnemoc> jumping out and back again
stekern has joined #linux-sunxi
<mnemoc> $ grep SUBLEVEL Makefile
<mnemoc> SUBLEVEL = 29
<mnemoc> $ git grep SUBLEVEL Makefile
<mnemoc> Makefile:SUBLEVEL = 43
<mnemoc> wtf
<oliv3r> 5-10 i guess
<oliv3r> you broke it
<mnemoc> rm -rf *
<Turl> 'git status' ?
<mnemoc> now everything deleted, but before everything was unmodified
<mnemoc> wtf^2
shineworld has joined #linux-sunxi
<Turl> your filesystem playing tricks on you? :p
<mnemoc> the .git files
<oliv3r> lol, raid out of sync
tinti has quit [Read error: Connection reset by peer]
<mnemoc> pointing to a different tree
<Turl> :)
<mnemoc> changing to relative paths now
paulk-desktop has quit [Quit: Ex-Chat]
<mnemoc> f* ... still drunk
<oliv3r> stop drinking!
<mnemoc> it's a bad idea to rename git dirs with submodules
<mnemoc> VERY VERY fragile thing
<oliv3r> some commands do weird shit due to submodules
* mnemoc deleting his sunxi-bsp trees
<oliv3r> yep
<oliv3r> theres absolutr paths in the subconfigs
<oliv3r> ouch
<mnemoc> I corrected them all
<mnemoc> also */.git files
<mnemoc> but totally f*ed up
<oliv3r> manually?
<mnemoc> sed
<oliv3r> yes :p
<oliv3r> git clone old name new name
<mnemoc> i didn't want to lose the not versioned files
<mnemoc> but... well.... re-cloning
<oliv3r> where are you atm anyway
<oliv3r> being drunk n all
<mnemoc> nah, I'm not drunk
<mnemoc> git is
<oliv3r> o lol
<mnemoc> I'm probably the most boring person on earth
<oliv3r> anyway, im thinking, maybe it is not a nad idea 5oo doo a devroomm for sunxi @fosdem
<oliv3r> lol, what makes you say that?
<mnemoc> when I'm tired of coding I sleep :p
<oliv3r> lol
<oliv3r> how isncoding bad
<mnemoc> don't drink, don't smoke, don't go out, don't enjoy eating, ...
<mnemoc> boring
<oliv3r> (on tablet in beda)
<oliv3r> love eating, othrwe=ise,muep
<oliv3r> otherwise, yep
<oliv3r> same
<techn_> why this wont start loading initramfs if root is null? :(
<mnemoc> weird
<techn_> or has anyone tried linux-sunxi/rootfs/sun4i_rootfs.cpio.gz ?
<techn_> are those broken?
<mnemoc> not me
<oliv3r> we had those?
<mnemoc> "legacy" files
<mnemoc> like
<oliv3r> i test with
<oliv3r> or something like that
<mnemoc> techn_: can you give a try to my soc-detect branch in your A13?
mdfe has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
hglm has quit [Quit: leaving]
awafaa_ has joined #linux-sunxi
mdfe has quit [Disconnected by services]
mdfe_ has joined #linux-sunxi
nove has quit [Quit: nove]
vinifm has quit [Quit: Saindo]
hramrach_ has quit [Remote host closed the connection]
LoCoZeNoz_ZUE has quit [Ping timeout: 252 seconds]
hramrach_ has joined #linux-sunxi
dragonn has quit [Ping timeout: 248 seconds]
mdfe_ has quit [Remote host closed the connection]
LoCoZeNoz_ZUE has joined #linux-sunxi
tinti has joined #linux-sunxi
LoCoZeNoz_ZUE has quit [Read error: Connection reset by peer]
Undertasker has left #linux-sunxi [#linux-sunxi]