<Turl>
libv: on the bright side, at least it doesn't look like spam now
andoma has quit [Ping timeout: 252 seconds]
<HdkR>
Oh, they haven't shown it off at CES yet?
<libv>
true
<HdkR>
Guess they've got three more days to do so
<Turl>
HdkR: not that I could find on any blog (and I'm not there :p)
<libv>
mailed...
andoma has joined #linux-sunxi
* libv
is now in for a bit of a long wait... dding over nfs over usb
<Turl>
o.O
<Turl>
bs= bigenough I hope
<HdkR>
Guess we've got to wait until the press comes out of the coma that Tegra 5 put them in to :P
<Turl>
I have a feeling your chip will get outdated 10 generations while that finishes otherwise
<libv>
bsdfox: for getting the other bits upstream, please refer to the new device howto
<Turl>
T5?
<Turl>
wasn't K1 all the rage now?
<HdkR>
beh, same thing new name
<Turl>
ah
<libv>
bsdfox: it is bad form to just attach them to the device page, your tablet should be supported by our standard u-boot-sunxi and sunxi-boards, so that all the howtos apply
<Turl>
if they continue doing as on the past, by the time it reaches market it's going to be a mid/low end chip
<libv>
bsdfox: please also spend some time on the infobox and such
<HdkR>
haha
<HdkR>
mid range hardware with OpenGL 4.4? Yes please :D
<Turl>
it's a quad A15
<libv>
crap.
<Turl>
T4 and previous have been meh hardware when compared with same gen snapdragons and the like
<libv>
kernel panic
<Turl>
time will tell
<Turl>
libv: ouch
<HdkR>
Sure, 4+1 Cortex-A15 setup at 2.3Ghz. Also the Denver dual core at 2.5Ghz that'll be out later this year
<libv>
ah, no, just noise
<libv>
it's trying to buffer too much
<HdkR>
I'm more excited about Nvidia's Denver CPUs than the GPU...
hipboi has joined #linux-sunxi
<Turl>
hey hipboi :)
<hipboi>
Turl, hi
<Turl>
hipboi: did you bring CES news with you? :P
<hipboi>
:P
<Turl>
we are waiting for allwinner A80 announcement
<Turl>
hipboi: with libv here we're speculating on the gpu :p
<hipboi>
pvr
<hipboi>
very likely
<HdkR>
My bet is on PVR
<keebler>
I was told that it WASN'T big.LITTLE
<keebler>
:/
<Turl>
hipboi: what about vivante?
<libv>
my guesstimate was 80% pvr, 19% vivante, 1% mali
<keebler>
But I DID hear they weren't going with Mali.
<hipboi>
why vivante?
<keebler>
But ALSO that the weren't going with PowerVR because of the headache of the A31.
<Turl>
hipboi: because they need market share and have gles3
<libv>
hipboi: because it can do gles3 and is not expensive compared to a mali t series
<hipboi>
oh, really
<hipboi>
i doubt
<libv>
hipboi: i would think that vivante would like to muscle in on the tablet market
<libv>
just like imagination is trying to claw back market share
<keebler>
If they go Vivante, then it'll be like the Freescale chips.
<libv>
_desperately_
<keebler>
Which would be interesting.
<HdkR>
hm. If it is Vivante it couldn't be a GC4000? I would think it would have to be atleast a GC6000
<keebler>
It could be the GC4000, but I don't see it. the 4000 is kinda low-end for the tech they're pushing.
<keebler>
I would think they're trying to compete against the Freescale Quad.
<keebler>
and such
<keebler>
(and apple)
<HdkR>
A GC6000 would put it on par with at least year old highest end GPU offerings
<rz2k>
I was ready to buy it since we have sun9i support in the A23 SDK
<Turl>
hipboi: benn post sound like they are, at least partially
<hipboi>
Turl, cubietech will make A80 based board
<hipboi>
of course
<hipboi>
but we, radxa will also make devices based on it
<hipboi>
something with router and storage
<Turl>
hipboi: :D
<Turl>
hipboi: the more the merrier :)
<Turl>
hipboi: sata PM sounds nice for that
<wens>
hopefully get some things right this time? like H-Sync/V-sync on LCD1?
<rz2k>
make atheros mips-something router design + arm SoC combo
<rz2k>
:p
<Turl>
rz2k: I have that at home :p
<hipboi>
rz2k, exactly
<Turl>
rz2k: using ethernet as interconnect ;)
<hipboi>
and arm is pluggable
<hipboi>
more than one
<Turl>
hipboi: totally offtopic but is 126.com email user base more like hotmail or gmail?
<Turl>
hipboi: someone has been emailing me questions and I'm trying to figure out if they know what they are doing or not :p
<hipboi>
126.com?
<hipboi>
126.com is not popular now
<hipboi>
in China
<hipboi>
maybe 5 or 10 years ago, it have the largest email users
<hipboi>
in China
<Turl>
so more like hotmail then
pwhalen has quit [Ping timeout: 252 seconds]
fredy has quit [Ping timeout: 245 seconds]
fredy has joined #linux-sunxi
HdkR has quit [Read error: Connection timed out]
pwhalen has joined #linux-sunxi
pwhalen has quit [Changing host]
pwhalen has joined #linux-sunxi
Akaizen has quit [Remote host closed the connection]
<Turl>
good night guys :)
HdkR has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
perr has joined #linux-sunxi
kriegero1 has joined #linux-sunxi
bfree has quit [Read error: Operation timed out]
kriegerod has quit [Read error: Operation timed out]
newleaves_jason has joined #linux-sunxi
bfree has joined #linux-sunxi
rz2k has quit []
newleaves_jason has quit [Client Quit]
newleaves_jason has joined #linux-sunxi
<newleaves_jason>
hello
<perr>
newleaves_jason: im here
<newleaves_jason>
ns ?
<perr>
yeah
tomboy64 has joined #linux-sunxi
<perr>
i have some problem in crypto of A20 chip. anyone can help me?
<perr>
i dont know how to conf the DMA for this
<perr>
newleaves_jason: it is at midnight.so there maybe no people online
mturquette has quit [Ping timeout: 246 seconds]
perr has left #linux-sunxi ["Leaving"]
newleaves_jason has quit [Quit: Leaving]
mturquette has joined #linux-sunxi
<wens>
mainline?
\\Mr_C\\ has quit [Quit: .]
newleaves_jason has joined #linux-sunxi
newleaves_jason has quit [Client Quit]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
<bsdfox>
I'm working on a different device now. A13 tablet. I've got TX from the serial console (don't think there's any chance of RX.. pitch is too fine to fit it) and I've built u-boot and got the unit booting from the sd card but I lose output after 'Starting kernel ...' -- http://pastebin.com/71TSqREs
<bsdfox>
do I need to change the 'UART to use during low level' to '1' since it's UART1 even though it shows up at ttyS0?
utente has quit [Ping timeout: 246 seconds]
utente has joined #linux-sunxi
<bsdfox>
that did appear to be the case. now to figure out the kernel crash :D http://pastebin.com/UFyVS48F do I need to do anything special to disable the uart that conflicts with the mmc? the only one I have enabled is pn PG03/PG04 and is uart1 which shouldn't conflict
hansg has joined #linux-sunxi
Quarx has joined #linux-sunxi
wolfy has joined #linux-sunxi
Quarx has quit []
bbrezillon has joined #linux-sunxi
<bsdfox>
same problem with another SD card that's working with my A10 tablet so it must be a kernel issue
rellla has joined #linux-sunxi
bamvor has quit [Ping timeout: 264 seconds]
bamvor has joined #linux-sunxi
newleaves_jason has joined #linux-sunxi
wolfy has left #linux-sunxi ["Culmea lenei este sa te scoli la sase dimineata ca sa ai mai mult timp de stat degeaba. (Tristan Bernard)"]
nesleaves_jason has joined #linux-sunxi
FR^2 has joined #linux-sunxi
nesleaves_jason has quit [Quit: Leaving]
panda84kde has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
juanfont has left #linux-sunxi ["Saliendo"]
juanfont has joined #linux-sunxi
juanfont has left #linux-sunxi ["Saliendo"]
juanfont has joined #linux-sunxi
FreezingCold has quit [Read error: Operation timed out]
_massi_ has joined #linux-sunxi
ssvb has quit [Remote host closed the connection]
<eyal>
hi guys
<eyal>
I'm playing with a cubieboard2
<eyal>
compiling the last Android release and it seems a file is missing to "pack" the distro
<eyal>
the file is fed_nand-linux.axf
<eyal>
instead of fed_nand.axf
bluse has quit [Ping timeout: 252 seconds]
<eyal>
does somebody knows if I can use the fed_nand.axf provided on the sources ?
lynxis has quit [Ping timeout: 272 seconds]
hansg has quit [Quit: Leaving]
Phoenix_ has joined #linux-sunxi
<Phoenix_>
does anyone know how to turn off lcd power? /sys/class/lcd/lcd/power/control accepts on or auto but not off?
newleaves_jason has quit [Quit: Leaving]
<mnemoc>
moin
newleaves_jason has joined #linux-sunxi
<ccaione>
moin
<bbrezillon>
Turl: Hi
Nyuutwo has quit [Quit: No Ping reply in 180 seconds.]
<bbrezillon>
you're patch is working (at least for my needs :))
<bbrezillon>
thanks
sgo11 has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
<oliv3r>
the board schematic is enough to claim yourself your opensource phoneix board?
<oliv3r>
phoenix board doesn't do i2c on the vga port :(
kivutar has joined #linux-sunxi
rah_ is now known as rah
FDCX has quit [Ping timeout: 260 seconds]
<oliv3r>
external headers: capacitive touch; right, they integrated the touch controller on their board, sure
FDCX has joined #linux-sunxi
<Nyuutwo>
oliv3r: I heard (here) that schematic must be published in open program (kicad)
<oliv3r>
Nyuutwo: not in open program per say, but schematic + board layout
<oliv3r>
and i think we are missing board layout
<oliv3r>
of course, using a proprietary file is kind of crap, but that's not hugely a problem
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
<Nyuutwo>
for me, I don't care about Open(TM) hardware, give me schematic, component placement and good bsp
parabyte has joined #linux-sunxi
<oliv3r>
personally, the schematic is enough; having the layout is very nice to have though (and a requirment, so good that). what's important to me on the software side, is open tools
<oliv3r>
a good bsp with all closed tools only causes headaches later
<Nyuutwo>
true
<Nyuutwo>
I have not specified good enough bsp
<oliv3r>
but i'm no hardware EE guy, so routing is important
<oliv3r>
rob savoye looks like a true geek
<oliv3r>
@armdevices.net
<Nyuutwo>
routing ofc is important, but you get board and you cannot repair it, so ...
<oliv3r>
yeah but as a non EE, if you try to debug/fix something, you know where traces are etc
<oliv3r>
and with open source hardware, making a small addition, requires the routing more then the schematic even
<oliv3r>
and i think that's the point, learn and extend
<Nyuutwo>
yeah that's the point ow ohw, learn but you need some theory (impedance, length) and nothing so special
<Nyuutwo>
and I said about component placement - you know where the traces ends
<oliv3r>
hehe
<oliv3r>
i think the routing is like the source code, if you wanna modify it, you need it
<Nyuutwo>
yup
<Nyuutwo>
but for software you just compile it
<wens>
you need the raw layout data to compile/make a new board
<Nyuutwo>
for PCB, you have to pay
kivutar has quit [Ping timeout: 272 seconds]
<Nyuutwo>
but you move say CPU 1mm to the left, and you need place high-speed buses from scratch
<Nyuutwo>
so when I have schematic I can make my own board, but ofc correcting some minor problems without board files is problematic
<oliv3r>
well that's kinda the thing though isn't it
<oliv3r>
you have something that is trace-length dependant
<wens>
well there are people who would want to print their own boards, and have the expertise to do it
<oliv3r>
your schematic may tell you this; but if you have to redo the whole routing, it may take you weeks
<oliv3r>
obviously, we dno't care about trolls who just use the routing files to mass produce cheaper versions of the same stuff
<Nyuutwo>
wens: yup, especially there are people that can do PCB for BGA at home
<oliv3r>
that's like sellers of gimp on CD etc
<Nyuutwo>
for me for 2 layer boards, when you don't have board files - you can just desolder everything, scan it and make gerbers
<wens>
i heard you could home solder BGA with a small oven?
<Nyuutwo>
wens: i heard it too
<Nyuutwo>
bga for me is scary, probably doable but no cheap chips to destroy
<Nyuutwo>
I have hotair, but no ball stencils, paste ...
<Nyuutwo>
and no cheap pcb
<oliv3r>
Nyuutwo: lol ok that's a little hardcore; but yes
<oliv3r>
reflow soldering is easy if you have the tools :)
parabyte has quit [Quit: Leaving]
<Nyuutwo>
qfn you can just flip over and solder with small wire to goldpins
<Nyuutwo>
but ofc high speed is hard in this setup
<Nyuutwo>
oliv3r: for reflow you need just oven(with added temperature regulator on uC), and solder paste
<Nyuutwo>
stencils are nice
<wens>
soldering for me ends at discrete though-hole components
<Nyuutwo>
i have soldered QFN16 3x3mm to homemade pcb (without bonding wires)
<ccaione>
uC ??
<Nyuutwo>
ccaione: microcontroler like Atmega
<ccaione>
hahaha I thought that uC == micro C degree sensibility
<Nyuutwo>
pt100 + some opamp to match to adc in atmega, atmega, some optocopuler and triac
<ccaione>
nvm, need coffee
<Nyuutwo>
and some way to set it (like rs232 to pc)
<Nyuutwo>
there are some cheap ovens (to heat up some bread) that you can use
<Nyuutwo>
but stencils for 1 pcb ...
<oliv3r>
i can solder some SMD
* mnemoc
failed to resolder a mini-usb connector :<
<oliv3r>
i solderd a mini usb connector on my tablet keyboard
<oliv3r>
which had a full size connector
<oliv3r>
rob savoye is awesome
<oliv3r>
going over his 1995 style homepage
<oliv3r>
but very very cool guy
<mnemoc>
no animated GIFs?
<wens>
weren't GIFs patented back then?
<mnemoc>
sure, but everyone used them on their sites to make things "more attractive"
<mnemoc>
flashy
sgo11 has quit [Quit: Leaving]
<Nyuutwo>
I soldered wire to 0.5mm? connector (on my tablet to probe LVDS clock)
<Nyuutwo>
some flux, some solder (0,7mm is a bit to big) and doable
ZetaNeta has quit [Ping timeout: 248 seconds]
<Nyuutwo>
and doable with rosin as flux
ZetaNeta has joined #linux-sunxi
newleaves_jason has quit [Quit: Leaving]
cubear has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
Black_Horseman has quit [Remote host closed the connection]
pwhalen has quit [Ping timeout: 260 seconds]
<binaryferret>
newb question but I can't seem to find the CSI driver choices (for a13 camera) when going through menuconfig. Any ideas?
<ccaione>
binaryferret: if you know the CONFIG_ you can search with /
<binaryferret>
Okdokey. Will chekc that out. Thank you ccaione
<ccaione>
yw
* ccaione
have to get used to the new nick
pwhalen has joined #linux-sunxi
pwhalen has quit [Changing host]
pwhalen has joined #linux-sunxi
utente has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
<mnemoc>
looks like cocaine
AreaScout has joined #linux-sunxi
<oliv3r>
wasn't that a tune some time ago? fuck on cocaine?
HeHoPMaJIeH has quit [Remote host closed the connection]
HeHoPMaJIeH has joined #linux-sunxi
<ccaione>
mnemoc: you are the second person today telling me that O_O
<oliv3r>
well lets see, cocaine and ccaione contain exactly the same latters; and it looks like
<ccaione>
I know, need to change my last name :)
<oliv3r>
carloc
<oliv3r>
sounds like clear alloc!
<ccaione>
gh, no way out
<oliv3r>
carloc isn't too bad though :p
<ccaione>
yeah, but definitely too many carloc in italy. Caionec only 3
<ccaione>
bbl
printallthething has joined #linux-sunxi
<oliv3r>
cb2 uses 0.1 Amps (4.95V) during u-boot prompt, but only 0.065 Amps for linux idling! (mainline)
<oliv3r>
running tinymembench is 0.15 amps @ 4.9 V
<oliv3r>
spikes of 0.2 amps
<oliv3r>
i wonder what speed the cpu runs at
<oliv3r>
prob single core
<oliv3r>
old kernel; ...
<oliv3r>
NEON operations don't change the current draw
nove has joined #linux-sunxi
<oliv3r>
latency tests run at 0.1 amp
<oliv3r>
which is what, .5 Watt?
FreezingCold has quit [Ping timeout: 260 seconds]
<libv>
Turl: i guess i will have to go fix up the phoenixboard page as well.
<oliv3r>
ok this is very strange
<oliv3r>
the current draw drops conciderably when i unplug my uart
<oliv3r>
0.06 amps idle, vs 0.16 amps idle; i'm no EE so don't know hy this happens, either the uart driver is leaking power somewhere when it's not connected? or, which is more likly, it is being fed via the UART cable
<libv>
mmc reading seems to work, good thing i went to bed though: 4085252096 bytes (4.1 GB) copied, 4789.83 s, 853 kB/s
ganbold_ has joined #linux-sunxi
<libv>
hrm, no cpufreq?
<oliv3r>
holy shit that's slow lol
<oliv3r>
don't think we have cpufreq in this old kernel; i was just doing a very short quick test of my vA meter
<libv>
ah, i was talking about my A13
<libv>
i have cpufreq on a10
<libv>
i even had it on sunxi-3.0
<oliv3r>
should work on a13 afaik
<wens>
oliv3r: the AXP209 regulators should give a much better reading when we have support?
<libv>
perhaps it died because it ran out of memory
<oliv3r>
wens: probably; but i'm interested in 'drawn from the wall'
<wens>
I see
<oliv3r>
cb3 with a charging battery and sata hdd uses 0.75 Amps
<wens>
I think it's possible the UART is leaking power
<oliv3r>
@ 4.8V
<wens>
btw, how large is your battery?
<oliv3r>
i think so too; well we know that power flows into the board from uart from the led
FreezingCold has joined #linux-sunxi
<oliv3r>
1220 mAh
<oliv3r>
4.51 Whr
Phoenix_ has quit [Ping timeout: 272 seconds]
<oliv3r>
3.7V obviously
<wens>
and we don't have pull-ups on the uarts
<oliv3r>
i have no clue; they are regular pins, so 'should'?
<oliv3r>
0.31 on cb3 without uart while in full 'off' state just to charge the battery and 'idle'
<libv>
where does one install the spl and uboot binaries?
<oliv3r>
i would expect to use the stock boot0/boot1/boot.axf combo?
<libv>
we do not have the ability to change that?
<wens>
read somewhere that uarts in general have pins pulled up
<oliv3r>
libv: we don't have a nand driver in u-boot-spl yet; the MTD work is for that
<oliv3r>
libv: i think someone tried to patch in libnand work into our current u-boot, but nothing came of that; so for nand support, use the stock one on nanda
<libv>
oliv3r: but we do in the lichee-dev branch
<oliv3r>
yeah, which is stock u-boot from nand-a, or should be
<libv>
first off, this is not documented as such
<oliv3r>
that how to goes about compiling that u-boot
<notmart>
libv: in that case uboot goes in /linux of the first partition.. it needs the lichee-dev uboot tough
<ccaione>
mripard: I'm puzzled. why does Arnd refers to SPI-0 in his reply?
<libv>
notmart: what does "goes in" mean?
<notmart>
boot0/boot1 is ok the stock one if the partition layout is not changed from the android setup, or it needs a patched one if there isn't an android fastboot partition anymore
<notmart>
libv: the question was where one puts the uboot binary no?
<libv>
ah, ok
<mripard>
ccaione: ?
<oliv3r>
libv: i think the install u-boot section
<hramrach>
libv: you don't. You use boot0/boot1
<libv>
so for starters, nanda is not to be touched, as noone has figured out or documented a full clean u-boot installation
<hramrach>
wrt nand installing
<ccaione>
mripard: did you see the Arnd's reply?
<mripard>
ccaione: just received it, 2s
<ccaione>
:)
<libv>
boot.cmd is apparently not supported, it has to be backed into the u-boot binary
<mripard>
oh
FreezingCold has quit [Ping timeout: 260 seconds]
<mripard>
ccaione: Shared Processor Interrupt, not Serial Peripheral Interface :)
<ccaione>
hahaha
<ccaione>
ok, now it is clear even though I have no idea if in the soc NMI is in cascade with GIC or not
<ccaione>
I guess so since for every NMI I need to ack also GIC
cubear has quit [Remote host closed the connection]
<binaryferret>
Anyone had any luck getting a GC0329 driver working with linux on an a13 tablet?
<binaryferret>
It's for the front facing camera built into the tablet.
perr has joined #linux-sunxi
<oliv3r>
mripard: Boris? this new? yes it is
<mripard>
oliv3r: parse error :)
<oliv3r>
mripard: do we know Boris Brezillon?
perr has left #linux-sunxi ["Leaving"]
<mripard>
I do :)
<mripard>
and he's on this chan too
<mripard>
bbrezillon:
<oliv3r>
oh! a lurker!
<bbrezillon>
hi
<oliv3r>
then he knows all the ins and outs of the mtd work and what has been done allready
<oliv3r>
bbrezillon: hi! :
<libv>
do we have source for boot.axf?
<oliv3r>
libv: i'm not sure
<oliv3r>
libv: I know we complained about GPL violation of the AW bootloader, and we got boot0/boot1 source (which partially I suppose is also BROM source code we have strong indications on)
<oliv3r>
libv: however if that includes boot.axf, I'm not sure of
<oliv3r>
I never checked
<bbrezillon>
oliv3r: I found the driver proposed by Qiang Yu
<bbrezillon>
and I based my work on it
<oliv3r>
bbrezillon: yeah that's all we have atm, you workin on cleaning it up for mainline submission first?
<bbrezillon>
but that's all I know
<oliv3r>
bbrezillon: you are aware of the research/fixes rz2r did on it?
<bbrezillon>
nope
<oliv3r>
bbrezillon: it's on our ML, but i'm not sure where he pushed it
<oliv3r>
bbrezillon: short summary, he did a lot of work on top of yuq's work
FreezingCold has joined #linux-sunxi
<oliv3r>
bbrezillon: i'll find a link
<bbrezillon>
I'm about to post a version the driver on LAKML (and sunxi)
<bbrezillon>
but I'll take a look
<oliv3r>
yuq's driver isn't fault free
<bbrezillon>
BTW, it would help me if other peope can test it
<libv>
it knows how to talk to the nand and reads boot.axf?
<hramrach>
it reads boot0
<hramrach>
very few blocks in a special format
<bbrezillon>
oliv3r: sending it :)
<hramrach>
or spl from mmc
<libv>
hramrach: where does boot0 live?
balage has joined #linux-sunxi
<hramrach>
libv: start of nand in area not normally visible
<hramrach>
the yuq driver gives access to it
<hramrach>
well, I think it's start but it may as well be anywhere. outside of what you see
<oliv3r>
bbrezillon: so deff. compare the nfc.c from rzk as it should have many fixes
<libv>
ok, so nanda does not expose it then
<libv>
err, our nand driver
<oliv3r>
libv: nope, and i think you can only change it via u-boot/fel mode? I don't remember; but i think hno did say we where able to change it with special tools
balage has left #linux-sunxi [#linux-sunxi]
<oliv3r>
bbrezillon: well there's only 3 patches ontop of yuq's patch; so that's easy to look at :)
<oliv3r>
i thought he did much more then taht
<bbrezillon>
:)
<libv>
so as long as we are on sd-card, we have only brom to worry about
<bbrezillon>
my proposal is a lot more simpler, and does not implement all the NFC features (HW ECC, DMA, HW randomization, ...)
<libv>
bring the nand into play, and there's suddenly a whole chain of binaries before you can get to u-boot
<bbrezillon>
I just used Yuq's work to understand how the NFC works
<oliv3r>
bbrezillon: what can we do with nand based on that patch? and what do we need for u-boot?
<bbrezillon>
you have to enable software ECC, beside that it will work as a regular NAND
<bbrezillon>
DMA not enabled -> CPU is not offloaded when writing from/reading to NAND
<bbrezillon>
writing to/reading from :)
<oliv3r>
what about the OOB issues dimitry and yuq ran into?
<oliv3r>
or does it not apply when using software ecc?
<bbrezillon>
HW ECC a bit more of speed penalty
jemk has joined #linux-sunxi
<bbrezillon>
I'm not aware of this issue, but I'd say if it deals with ECC it might be solved
<bbrezillon>
sorry: HW ECC missing -> a bit more of speed penalty
<libv>
hrm, rhombus-tech wiki does not seem to expose history per page
<bbrezillon>
oliv3r: I'm not using DMA transfers, this should solve the problem
<oliv3r>
bbrezillon: i don't know how they relate :p
<bbrezillon>
And when doing my test I always succeed in reading the OOBs
<oliv3r>
bbrezillon: but from my understanding it was a problem with the actual flash storage, as each chip has different oob values or something, but i'm far not up to speed with all of this
<libv>
oob?
pwhalen has quit [Ping timeout: 252 seconds]
<oliv3r>
libv: http://linux-sunxi.org/SRAM_Controller 0x00010000 - 0x00010ffff is for the USB FIFO's, nand flash has its buffers somewhere where we not sure of yet
<oliv3r>
brb
<libv>
oh, out of blocks
FR^2 has joined #linux-sunxi
<mripard>
I thought it was out of band?
<oliv3r>
bbrezillon: in any case, a slow, well working driver without DMA and ECC for now is far preferable then the nothing we have now :)
<oliv3r>
heh, out of something :p i don't even know what it means with regards toflash
<libv>
oliv3r: hrm, why would that are be exposed through /dev/nand ?
<libv>
area even
<oliv3r>
libv: oh the 0x00001000 - 0x0100000 area on flash, i thought in address space!
<libv>
:)
<libv>
i get 0xFF returned there, where one would expect all sorts of things to be loaded
shineworld has joined #linux-sunxi
shineworld has left #linux-sunxi [#linux-sunxi]
<oliv3r>
our /dev/nand driver won't expose the first few bytes, where boot0 boot1 are stored
<oliv3r>
well not our, the allwinner one
<oliv3r>
afaik you need nand_part to make partitions, fdisk won't work
<bbrezillon>
OOB -> Out Of Band
<oliv3r>
libv: boot-block! is what that first area is called
<bbrezillon>
the NAND driver expose nand device as /dev/mtdX
<oliv3r>
bbrezillon: how does it handle the bootblock? does it also skip it?
<oliv3r>
libv: nand-part
<oliv3r>
nand-part is a tool to repartition the internal NAND on sunxi devices. It should be (cross-)compiled for the device's architecture, and it requires the device to have a special kernel patch (already included in our kernel tree) to expose the full NAND as a block device.
<bbrezillon>
I don't know, I guess you'll have to define a partition
<bbrezillon>
with the bootblock size
<oliv3r>
but i think it skips the bootblock
<bbrezillon>
if it's a real NAND blk it can't
<oliv3r>
bbrezillon: well by default, partitioning tools refuse to use anything before sector32 or sector 63 on x86 anyway, so i'd imagine it will refuse to partition before that space, to leave room for the bootloader?
<libv>
aha, so since it uses a different access pattern (randomizer and ecc) it cannot be accessed anymore by the nfs, unless the nfc is set up differently
<libv>
again
<libv>
cannot be accessed anymore by the nfc, later on, unless ...
<oliv3r>
libv: i think so; but don't quote me on that; i know very little of it all; i never dug in :)
<oliv3r>
interesting point, that means, that bbrezillon nand driver must also skip the bootloader, or force it to use the fixed random_seed, or you can't ever write the bootloader there from the mtd driver
<bbrezillon>
well, I'm not sure, because I erased the flash content when doing my tests
<oliv3r>
bbrezillon: if you hook up serial and can still do something from boot0 (boot0 and boot1 do serial debug output) it's still there
<bbrezillon>
but I guess I can write the binary to the NAND again and see how it looks like
<oliv3r>
i do remember yuq did address that issue
<libv>
bbrezillon: right, so you are using the full thing and are not boot from the nand
<libv>
booting
<bbrezillon>
not yet
<bbrezillon>
but we should be able to boot it
<oliv3r>
bbrezillon: I guess the mtd driver must always use the fixed random_seed for the first 24KiB for the bootloader, as the BROM will always read with that fixed random_seed from nand and check for SPL there (24-32k being the hard limit the BROM tries to load)
<libv>
and perhaps have a separate driver to access it afterwards
<bbrezillon>
I'm pretty new to all this sunxi stuffs, I don't exactly the internals of the boot process
<libv>
which should only work when the other driver is not being used
<oliv3r>
bbrezillon: the BROM (boot loader in ROM) has the following boot order: mmc0, nand, mmc2, SPI. it checks for a valid image there. the BROM has a hardcoded limit of 24k on sun4i, sun7i and 28k for sun5i
<libv>
bbrezillon: good thing i started whinging when you were about then
<oliv3r>
bbrezillon: the BROM will use a hardcoded random seed of 0x4a80 to load the SPL from nand
<oliv3r>
u-boot-spl is then loaded and should be able to use the static random_seed[128] table we know an dhave
<libv>
things are starting to make some sense :)
<oliv3r>
if the first 32k are treated with the fixed random_seed, we should bhe able to write the SPL to the first 32k; u-boot to 32k - sizeof(u-boot) with a randomseed from linux
<oliv3r>
but i think yuq did tacle that (see mailing list) where he said he didn't know how to write the bootloader and relied on the livesuit initially
<libv>
does spl set the random_seed ?
<oliv3r>
if there is enough room in the SPL, it could, it's only a unsigned short [128] size table
<oliv3r>
so if we have enough room in the 24k of the SPL, it can do everything 'normally'
<libv>
so first step, add an option to existing nand drivers to do just boot
<oliv3r>
i think the allwinner driver did it the 'lazy way' used the fixed seed for the first meg or so, and the driver only does the random bit; hence why they skip that bit in their driver
<libv>
oliv3r: would you really want to mix this during operation?
<oliv3r>
the fixed seed for the first 32kb of the flash?
<libv>
oliv3r: would you really want to or can you even have different randomizing going on on the NFC?
n1bs has joined #linux-sunxi
<oliv3r>
libv: re rhombustech history; i think it's all a big git repo; so checking it out you can use gitlog
<libv>
oliv3r: i would expect it to be one setting for the lot
<libv>
oliv3r: so you either access just the boot area, or you access the rest, not both at the same time
<oliv3r>
libv: afaik, it uses a table of 128 entries; how that's applied, i don't know
<oliv3r>
libv: well if you want to update the bootloader
<oliv3r>
i think it'll be much easier to have a mtd driver, that skips the first meg
pwhalen has joined #linux-sunxi
<oliv3r>
and you use some special tool to write the bootloader when needed
<oliv3r>
i'd even bot both the SPL and u-boot into the fixed seed area
<n1bs>
Hi Guys! Trying to port android JB for Hackberry board, and need some help with EGL errors - can't beat the problem with different versions of API for mali.ko & libMali/libUMP - both seems setup correctly, but SurfaceFlinger can't start :(
<oliv3r>
so you can flash u-boot-sunxi-with-spl.bin
<oliv3r>
n1bs: that sounds more like #android and #mali :p
<libv>
the latter doesn't exist :p
<libv>
n1bs: find out what EGL is about
<n1bs>
oliv3r: still not sure, it's still related to kernel sunxi-kernel :)
<libv>
n1bs: no, it is not
<libv>
n1bs: the key is EGL
<n1bs>
kernel provides r3p0 API, copied all needed stuff from r3p0 part of sunxi-mali - with not luck :(
<libv>
n1bs: again, find out what EGL is
<oliv3r>
libv: i think we scared bbrezillon
<n1bs>
libv: sorry, what do you mean ?
<libv>
oliv3r: so is there the ability to set up the randomizer per ""block""?
<oliv3r>
libv: my knowedge lacks this information
<bbrezillon>
nope, I'm just taking a look at NAND randomization
<bbrezillon>
but I think the mainline kernel does not support it
<n1bs>
libv: well, what I can see from logs - it's not about general API - it fails on very first step - can't even initialize. So I keep hope that it's just my mistake somewhere with libs, but need someone to kick me in right direction - don't know how to debug this deeper
<oliv3r>
i don't know why they changed the random_seed for page0 to something different then the rest of the lot; maybe because the BROM was 'old' and they changed the seed later, but couldn't change the BROM anymore obviously
<oliv3r>
n1bs: opengl ES vs opengl maybe?
<libv>
oliv3r: this blocks of an area which is dependant on the nand size
<libv>
off even
<oliv3r>
libv: but i'm just going by patches now and talking a little out of my butt, i really don't know this stuff :)
<libv>
which is a pretty nasty big hammer
<oliv3r>
how big is a page size generally for this stuff? dpeendand on the flash chip itself?
pacopad_ has joined #linux-sunxi
<libv>
yes
<libv>
and there are other factors as well
<libv>
multiple dies and such
<libv>
so you basically give up 1/128th of the chip
<libv>
with slapins patch
<n1bs>
oliv3r: there is only ES - traced surfaceflinger with strace - successfully loaded all libs, but when starting with eglInitialise() - segfaulting. From linux side it was the same until I compiled libUMP and put libMail.so from r3p0 version, but for android - this doesn't help :(
pacopad has quit [Ping timeout: 260 seconds]
<libv>
Turl: please confirm my assertion
<oliv3r>
libv: really? that much?
<libv>
Turl: not every random libMali.so/libEGL_mali.so will work with every random surfaceflinger, right?
<oliv3r>
libv: so on an 8 gig chip; that's 64 mb?
<libv>
or is google taking very special care to keep things compatible?
pacopad has joined #linux-sunxi
<libv>
which is complete bullshit on an area that is that crucial for the performance of android
<libv>
oliv3r: it's 32MB on a 4GB chip
<n1bs>
libv: it's not random - it's exactly matching kernel version, so at least initialization should pass
<libv>
n1bs: do you know how to read?
<oliv3r>
libv: that's a lot, if you concider that the bootloader is what, 512k?
<oliv3r>
libv: still I don't understand how the mod 128 relates to the pages of the chip; i thought that the randomizer repeated the random see or something
<libv>
oliv3r: apparently, this is to avoid that large areas have the same signature for hw reasons
<libv>
so that's why the lower bits are used to mask this off
<libv>
err, to achieve this
<libv>
actually, this is all software...
<n1bs>
libv: sorry for not being so smart as you, but I was sure that app + libs from the same API should work.
<oliv3r>
libv: as long as bbrezillon understands :p
<libv>
and it should be possible to translate on the driver side
<bbrezillon>
based on my driver, see if it helps booting the spl bin
<oliv3r>
bbrezillon: i think it'll be crucial to not burn the flash out in days, I thought that even using a wearlvling FS won't matter here; but as i just told libv; i know too little abou tthis to say anything really; hno and slapin know this stuff best
<oliv3r>
hno ^
pacopad_ has joined #linux-sunxi
<jemk>
nove: is it possible to fake register values with ammt?
pacopad has quit [Ping timeout: 260 seconds]
pacopad_ is now known as pacopad
<nove>
jemk: is possible, but not easy as it is now
<nove>
jemk: i had plans to had this feature, as something a wrap_point, that would allow to wrap a memory access with a function
<libv>
oliv3r: it is on the software side.
<jemk>
nove: ok, i only wanted to fake a13 (0xf0 = 0x1625).
pacopad_ has joined #linux-sunxi
<bbrezillon>
oliv3r: UBI is quite good at wear leveling, and you can put any FS on top of UBI
pacopad has quit [Read error: Operation timed out]
rellla2 has joined #linux-sunxi
<libv>
oliv3r: this randomizing is set per access
pacopad has joined #linux-sunxi
<libv>
at least in slapins code
rellla has quit [Ping timeout: 260 seconds]
<libv>
so we could be smart about it
<libv>
but that would break livesuit
<hramrach>
the ultimate advantage of UBI over AW libnand is that it's known code used by bazillions of people so if something goes wrong with your nand there is good chance it happened to somebody else already and you can just stfw for a solution
pacopad_ has quit [Ping timeout: 265 seconds]
<nove>
jemk: something like WRAP_POINT(virtualaddress, callbackfunction), but still not time to do it
<libv>
hramrach: we still need to be able to read allwinners nands
<libv>
hramrach: otherwise we limit ourselves to olimex development boards and cubie
<jemk>
nove: no problem, its easier then to let someone with real a13 trace it ;)
<hramrach>
libv: no. you just rewrite the nand with new format. the MTD driver is not compatible with AW
<hramrach>
you need to support the boot0 special block but that's it
<nove>
jemk: i have a A13,, if you want me to look for something or upload some traces
<hramrach>
if you need to read aw nand you can use 3.4 kernel and libnand. Until AW tells us what's actually there or somebody RE it the chances of reading it are slim
<libv>
hramrach: you're right, as we usually can get other bits off of the stock firmware
<libv>
hrm, what requirements does brom have
<libv>
if it's just an offset...
<hramrach>
it probably just reads the boot0 block and checks some checksum on it
<libv>
then a sunxi mtd should check for the softwinner partitioning
<libv>
and refuse to load
<hramrach>
it would have to implement all of NFC for that
<hramrach>
because to MTD driver the AW nand is unintelligible
<hramrach>
it's pretty much unintelligible to anyone. that's the problem with AW nand
<libv>
oliv3r: you looked at brom in detail, does it care at all what partitioning scheme is there or does it just care about what is at usual offsets?
wingrime has joined #linux-sunxi
<bbrezillon>
AW is using a specific NAND chip ?
<hramrach>
it's using a specific NAND format
<hramrach>
bad block tables and stuff like that
<libv>
hramrach: the theory is that brom needs the special randomizing bits just for the spl binary
<bbrezillon>
ok
<libv>
hramrach: but it's theory atm
<libv>
i am not sure if anyone _really_ knows what needs to be loaded where.
<libv>
as no-one has gone and replaced boot0 with spl
<hramrach>
well, the yuq driver gives access to the boot0/boot1 area but is not tested
<hramrach>
and there is no replacement for boot0, yes
<hramrach>
so nothing to test with
<libv>
but i thought boot0 could be replaced by our u-boot-spl.bin
<libv>
if it knew about nand
<hramrach>
technically it could but in practice the spl is not useful because it does not know about nand
<hramrach>
you could like replace the boot0 with spl that reads mmc
<hramrach>
should work for testing
<libv>
hramrach: this is the chicken and egg problem atm.
<hramrach>
so long as the spl fits into the boot0 area
<hramrach>
if it needs splitting
<libv>
hramrach: 1) sunxi nand driver must be able to access this area like brom does it
<Turl>
libv: if kernel and libEGL/GLES/Mali/etc match there's a chance it'll work
<libv>
so you can read/write it from usb/sd boot
<hramrach>
libv: actually, the first thing to do is the MTD driver for linux so you can boot from mmc, write new content to nand. then a nand spl is useful to boot from thre
<libv>
hramrach: research first.
<libv>
actually...
<Turl>
libv: if you're using ancient blobs (eg r3p0) with newer androids you're bound to hit issues though
<libv>
spl does not need to know about nand, does it?
<hramrach>
well, oliv3r did/is doin the brom research and yuq did much of the nand side
<hramrach>
no, it can be read from nand and then read kernel from mmc
<libv>
u-boot.bin needs to know
<Turl>
stuff on the EGL layer changed a bit, so you get dequeuing errors
<Turl>
bbrezillon: /q?
<hramrach>
spl read u-boot.bin
pacopad_ has joined #linux-sunxi
<bbrezillon>
Turl: Hi
<libv>
Turl: read up on what n1bs was saying an hour ago
<libv>
Turl: he was having issues and he was blaming the kernel, while i rudely pointed the finger at EGL
pacopad has quit [Ping timeout: 260 seconds]
<libv>
hramrach: right
<libv>
so spl needs to be able to access this too :(
pacopad_ has quit [Read error: Operation timed out]
<hramrach>
libv: with the yuq driver we have now you can write spl to nand and have it read u-boot.bin from a supported location like mmc, in theory
<Turl>
libv: you got logs handy? -ENOCAFE yet
pacopad has joined #linux-sunxi
<libv>
Turl: nm: "kernel provides r3p0 API, copied all needed stuff from r3p0 part of sunxi-mali - with not luck :("
<libv>
so yes, he is on r3p0 and expects jelly bean to run
<libv>
Turl: his first msg was: "16:04 < n1bs> Hi Guys! Trying to port android JB for Hackberry board, and need some help with EGL errors - can't beat the problem with different versions of API for mali.ko & libMali/libUMP - both seems setup correctly, but SurfaceFlinger can't start :("
<Turl>
he's probably going to see a bt of a bootanimation and then death and dequeuing errors and the like
<libv>
and he seems totally unwilling to listen to the lima driver developer, and the guy who creates sunxi-mali, and still tries to blame the kernel
pacopad_ has joined #linux-sunxi
<libv>
but then, it could've been that google has kept surfaceflinger <-> egl interface absolutely and completely stable since 2007
<hramrach>
you mean absurdly bugged?
<libv>
google has this vast computing power
<libv>
and they can look 6 years in the future
pacopad has quit [Ping timeout: 245 seconds]
pacopad_ is now known as pacopad
<libv>
and they knew in 2007 that they would have apps use the GPU extensively for accelerating some calculations
<libv>
and they also knew about hw overlays and such back then
<HdkR>
They also knew in 2007 that they weren't ever going to allow OpenCL on any of their platforms
<HdkR>
Before it was even announced
<libv>
so they managed to design an absolutely futureproof surfaceflinger, so that everyone could use any binary drivers
<libv>
makes one wonder why those open source idiots are busy reverse engineering GPUs
<Turl>
libv: well, the GL interface was rather stable from the first android to around gb (2.3)
<libv>
Turl: GL yes, EGL no
<libv>
EGL interface to GL/Apps, yes
<libv>
EGL interface to windowing system: no
<libv>
that's exactly what the egl bit is for
<Turl>
well, the binaries worked, that's what I meant :)
<libv>
ah, right
<libv>
yeah, first big breakage perhaps
<libv>
but since then they added hwcomposer, and renderscript and such
pacopad_ has joined #linux-sunxi
<hramrach>
well, I cannot boot a damn android on an A10 board unless it's a prebuilt image with ancient bugged kernel
<Turl>
libv: around the ICS ages they started requiring a new GL extension, glExternalImageOES or something like that
<Turl>
I suck remembering names :)
pacopad has quit [Ping timeout: 245 seconds]
<Turl>
that's when suff began to break considerably
pacopad_ is now known as pacopad
<libv>
n1bs: are you now willing to accept this?
pacopad_ has joined #linux-sunxi
<libv>
Turl: thanks :)
<libv>
anyway, time to commit a lot of stuff to our wiki.
<n1bs>
libv: seems you misunderstood me :) I wasn't telling that it's problem of kernel, I just stated that according to sunxi wiki - it's problem of chain: mali.ko -> libmali -> libegl. I'm not a graphics dev, so it's new to me - but now I see, that r3p0 is not compatible with surfaceflinger from JB :)
FreezingCold has joined #linux-sunxi
<n1bs>
but I still don't understand - cubieboard 1 has the same HW as hackberry - how is that possible that manual for building JB for CB exists, but will not start ? :)
<libv>
n1bs: with working binaries?
<n1bs>
I guess it's good to state that JB of a10 will work in headless only mode
FR^2 has quit [Quit: Connection reset by peer]
bfree has quit [Ping timeout: 260 seconds]
<bbrezillon>
can someone dump a few blocks (including oob datas) of a NAND chip programmed with HW ECC and HW RANDOMIZATION
TehCaptain has quit [Read error: Connection reset by peer]
<bbrezillon>
?
bfree has joined #linux-sunxi
TehCaptain has joined #linux-sunxi
bfree is now known as bfree_
panda84kde has quit [Quit: Konversation terminated!]
<hramrach>
bbrezillon: I have a few nand chips written by AW tools (and at least on one the FS is failing already) but how do I dump the data?
<hramrach>
also the HW returns some evaluation of the block bitrot. You want that also?
<bbrezillon>
this is a good question :P
FreezingCold has quit [Ping timeout: 276 seconds]
<hramrach>
presumably the yuq driver could be modified to dump blocks
<hramrach>
but it cannot do randomization and oob at the same time
<bbrezillon>
nanddump tool is able to dump blocks + oob
<bbrezillon>
but you'll need an mtd device
<hramrach>
with what driver?
<bbrezillon>
could you try to boot on an SD card and load a kernel with my driver ?
<bbrezillon>
but you'll need a kernel based on linux-next...
<hramrach>
I can try to boot from network and load a kernel with whatever driver I can patch on top of sunxi-devel
<hramrach>
the archive gives you HTML of the patch which is useless for applying and you can have the patch forwarded to you if you solve a captcha. one for every of the 9 patches
ssvb has joined #linux-sunxi
<hramrach>
not to mention that those patches then end up in your mailbox out of which you have to filter them somehow
<Turl>
hramrach: lkml.org has a get patch button on the left
<Turl>
you can use something like gmane otherwise
<hramrach>
but it gets you the bare diff, not the message
FreezingCold has joined #linux-sunxi
<hramrach>
with completely useless filename, no less. all are named 1
<Turl>
yeah :)
<Turl>
try gmane then
<Turl>
or google, often those patches get caught in patchworks, which are prety handy
<mripard>
yes, there's patchwork instances for a number of kernel ml
<ssvb>
oliv3r: it also makes sense to remove any other cables (miniusb, uart, ...) and lipo battery to make it a clean experiment
Akaizen has quit [Remote host closed the connection]
<ssvb>
oliv3r: but I wonder if it could be that the sunxi-3.4 kernel enables some particularly power hungry peripheral, while your mainline kernel does not :)
FreezingCold has joined #linux-sunxi
ssvb has quit [Ping timeout: 252 seconds]
bbrezillon has joined #linux-sunxi
<oliv3r>
well once i have some more time, i can test a few configurations and kernels
<oliv3r>
i just tested what was on my SD card; and i ran the test witha nd without uart connected (but i need uart to boot)
<oliv3r>
also remember, mainline supports like next to no hardware
<oliv3r>
ssvb and yeah i saw your your performance post
<mripard>
oliv3r: tsss, we have babelfish for that :)
<hramrach>
except there is never anything but that
<oliv3r>
well jffs is a great flash filesystem, but i think it needs OOB, more then we can offer? then there's logfs which I dunno if that was tested and f2fs is more intended for flash like usb and or mmc; not raw flash; i didn't think ext4 ran ontop of ubifs, i thought you need trueffs or extremeffs with ext4 ontop I belive
<hramrach>
one patch did not apply so tried to glue it on the top
<oliv3r>
libv: i'm not to worried about breaking livesuit atm, mtd for 3.10, libnand for 3.4; and once both work reliably, we can see how to keep livesuit compatibility
<Turl>
hramrach: post the full dmesg
<oliv3r>
libv: but i think hno, who did the initial nand work; said there would be no way they'd ever be compatible; you could do some fuse thing inbetween though
<oliv3r>
libv: I haven't checked the nand portion, but it extremly likly it does the same as SPI and MMC; the bootloader is wrapped in a header, with a signature, the BROM loads the first 1k or so, and reads the signature, if it says 'eGON0' it loads the rest and executes it
<hramrach>
oliv3r: the on-flash format for AW and MTD is different. the block management data is stored there but differently
enrico__ has quit [Ping timeout: 260 seconds]
<hramrach>
it cannot be compatible in any way
<oliv3r>
libv: hence, u-boot-spl will have to look the same, but once we load the SPL; we can check in the boot1 header if a special sunxi flag is set, and if not, refuse to load it
<oliv3r>
libv: luckly though the brom uses a fixed always the same randomizer
<Turl>
hramrach: those nodes should be inside the pio one, with all the other pin definitions
<oliv3r>
libv: and as hamrach siad (i'm still backreading btw) yuq's stuff actually replaced teh whole thing. u-boot-spl with mtd support, kernel with mtd support, ereasing the entire flash
<hramrach>
Turl: like 8149216
<oliv3r>
libv: that's why i hope bbrezillon also took rz2k's patches as they both where rather far ahead; just some oob things to solve
<oliv3r>
and bad block tables (now back to backreading)
<hramrach>
?
<hramrach>
guess I was off a few lines :/
<Turl>
hramrach: yeah looks better
<libv>
oliv3r: i'm back from cycling now, and i will continue working the NAND page filling it in with what i learned today
<libv>
oliv3r: i gave it a start in background, and hopefully that will be enough of a motivator to get this work going again
<Turl>
hramrach: will it blend? :)
<hramrach>
the driver starts so it's good enough I guess
<hramrach>
I wonder how the bad block scanning works
ssvb has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
FR^2 has quit [Remote host closed the connection]
FR^2 has joined #linux-sunxi
ssvb has quit [Ping timeout: 260 seconds]
FreezingCold has quit [Ping timeout: 260 seconds]
ZetaNeta has quit [Ping timeout: 246 seconds]
AreaScout has quit []
techn__ has joined #linux-sunxi
techn_ has quit [Ping timeout: 276 seconds]
FR^2 has quit [Remote host closed the connection]
FR^2 has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
ssvb has joined #linux-sunxi
lkcl has quit [Ping timeout: 276 seconds]
<andhe>
investigating bluetooth on cubietruck is driving me crazy.
netlynx has quit [Quit: Leaving]
<oliv3r>
hramrach: why is your nand so bitrotten? shouldnt it only rot slowly when you write, reading you can do indefinatly
<hramrach>
oliv3r: it happens. it's normal with AW nand. I booted Linux off it a few times and installed it there in the first place so it got written somewhat
<oliv3r>
yeah but it shouldn't be THAT horrible?
<oliv3r>
though with a good FTL; you won't notice it for a while
<oliv3r>
and i understood FTL correctly, the flash will just keep shrinking when it starts to break severly
<hramrach>
well, every once in a while somebody comes saying their device no longer boots and it miraculously starts working after reformatting and reflashing the nand
<hramrach>
so it is normal with AW devices to bitrot
rellla has quit [Remote host closed the connection]
<hramrach>
also to shrink the flash you have to reformat it
<oliv3r>
Ohh, now i understand; UBI/UBIFS does not use OOB at all
<oliv3r>
hence, why it's not an issue
kivutar has quit [Remote host closed the connection]
lkcl has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
ZetaNeta has quit [Changing host]
<oliv3r>
lkcl: hey!
<oliv3r>
lkcl: new a23 SDK; libnand.so again
<Nyuutwo>
wat, I thought ubi uses oob
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
<Nyuutwo>
you needed put logical and psyhical sizes of sector, for ubifs just logical
xeros has quit [Quit: xeros]
kivutar has joined #linux-sunxi
<Nyuutwo>
and I have platform with nand that always prints fixable bit flip
<oliv3r>
Nyuutwo: neither ubi nor ubifs use OOB's
<oliv3r>
Nyuutwo: i didn't even know the two where seperate
<oliv3r>
not sure if there's any layer ontop of ubi that works with ubi volumes though other then ubifs
<Turl>
there's ubiblock :p
bbrezillon has quit [Ping timeout: 252 seconds]
<Nyuutwo>
oh, so ECC is in nand driver
<Nyuutwo>
interesting wether ubi uses this info
<bsdfox>
does lichee-dev u-boot work with A13?
enrico__ has quit [Ping timeout: 252 seconds]
<techn__>
bsdfox: yes
enrico__ has joined #linux-sunxi
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
popolon has quit [Changing host]
<bsdfox>
techn__, thanks. I'm interested in copying my linux install to nand and am currently backing up /dev/nand and /dev/nand[a-j] but the howto talks about changing this "The lychee-dev u-boot has useless default boot command. In include/configs/sun4i.h change this line:" and that line is quite different in the current repo. Also not sure if I would need to make changes to the sun5i_a13.h or perhaps the current line is correct?
<HdkR>
PVR6 obviously. but I wonder how high they are going on the power spectrum
adb has quit [Ping timeout: 252 seconds]
Night-Shade has joined #linux-sunxi
nove has quit [Quit: nove]
<HdkR>
I'm going to guess the 6320, same one that the Apple A7 uses
<bsdfox>
hmm I appear to be having issues getting my nanda partition to be 16mb
<bsdfox>
I repartitioned it using nand-part -f a10 /dev/nand 32768 'boot 32768' 'root 7405568'
<bsdfox>
and nand-part shows it being 16mb as does sfdisk but when I mount the parition it shows up as 128MB
<andhe>
sunxi-rfkill driver in 3.4 seems to not even contain the cases for cubietruck bluetooth module.... I wonder how anyone could have this working.
<oliv3r>
Nyuutwo: we have hardware ECC in the nand controller as far as I know
<bsdfox>
partition 1: class = DISK, name = boot, partition start = 32768, partition size = 32768 user_type=0
ganbold_ has quit [Remote host closed the connection]
<oliv3r>
'They own a lot of their own IP' i highly doubt that
<jinzo>
they can probably buy instead of license a lot of IP
<jinzo>
I would say
<jinzo>
so no cost per device, but a up front
<jinzo>
but who would'we known
<jinzo>
they're boasting 15% tablet share - which looks far fetched too
RzR is now known as rZr
<jinzo>
(I think RockChip is quite a margin above them, and then there're the other non-china contesters and... leaves a little of that 100 up for grabs)
<jinzo>
but who would'we known.
<libv>
is patrick wood chinese?
enrico___ has quit [Quit: Bye]
setkeh1 is now known as setkeh
setkeh has quit [Changing host]
setkeh has joined #linux-sunxi
rz2k has joined #linux-sunxi
<libv>
un-be-lievably unusable.
pwhalen has quit [Ping timeout: 246 seconds]
<libv>
doesn't even do limit checking, and doesn't at any point bother to tell us what the size of the nand really is...
<libv>
the best option is to provide something huge, and then look at dmesg to see what the driver states there
Gerwin_J has joined #linux-sunxi
Akaizen has quit [Remote host closed the connection]