<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.
<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>
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.
<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
<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>
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: http://paste.debian.net/5762/
<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>
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
<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
<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 libvecore.so
<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*
<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
<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