libv has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
VargaD has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Akagi201_ has quit [Ping timeout: 255 seconds]
ricardocrudo has joined #linux-sunxi
pwhalen has quit [Ping timeout: 255 seconds]
pwhalen has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
Akagi201 has joined #linux-sunxi
popolon has quit [Quit: Quitte]
egbert has joined #linux-sunxi
egbert_ has quit [Ping timeout: 245 seconds]
ganbold_ has joined #linux-sunxi
nabblet has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
ricardocrudo has quit [Ping timeout: 240 seconds]
nabblet has quit [Quit: leaving]
Andy-D has joined #linux-sunxi
<wens>
libv: i haven't, as we don't have exact a23 dram code to match
<wens>
i just assume it's similar to sun6i
wingrime has joined #linux-sunxi
<libv>
is this due to the lacking u-boot code?
<wens>
lacking boot0
<wens>
allwinner's u-boot doesn't handle dram
<libv>
sounds like something our engaged partner should provide us
<libv>
eva wu just posted on linkedin: "I have noticed quite a lots of complaints about the A80 OptimusBoard provided by partner Merrii. I have talked to Merrii and convinced them to give their best discount. Now you can own an A80 OptimusBoard for 169USD. See more details in the attached poster. http://lnkd.in/bmibaKFhttp://lnkd.in/bjSSNWS "
Andy-D has quit [Ping timeout: 245 seconds]
<wens>
Huh?
Andy-D has joined #linux-sunxi
nabblet has joined #linux-sunxi
hipboi has quit [Ping timeout: 250 seconds]
<wens>
yeah, price on taobao dropped from 1999 rmb to 999 rmb (roughly 165 usd with shipping)
<wens>
so that's about the price of an a80 tablet
<libv>
so halved.
<libv>
discount my arse :p
<wens>
price drop is more accurate
hipboi has joined #linux-sunxi
<wens>
wonder if it helps
Andy-D has quit [Ping timeout: 245 seconds]
Andy-D has joined #linux-sunxi
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
<libv>
wens: did we get boot0 code for a31 or is the dram info in the datasheet?
pwhalen has quit [Ping timeout: 240 seconds]
<wens>
libv: yes we have boot0/boot1 code for a31, but no, dram info isn't in the datasheet
mmarker has quit [Remote host closed the connection]
pwhalen has joined #linux-sunxi
nabblet has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
montjoie[home] has quit [Ping timeout: 244 seconds]
montjoie[home] has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
dlan has quit [Ping timeout: 255 seconds]
kuldeepdhaka has joined #linux-sunxi
dlan has joined #linux-sunxi
dlan has quit [Changing host]
dlan has joined #linux-sunxi
PulkoMandy has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
Faisal has quit [Read error: Connection reset by peer]
Faisal has joined #linux-sunxi
<akaizen_>
how can I upload to dl.linux-sunxi.org? I have most of A31 files downloaded
akaizen_ is now known as akaizen
<akaizen>
oh looks like they are already up there
HeHoPMaJIeH has joined #linux-sunxi
dudepdx has joined #linux-sunxi
Faisal has quit [Quit: No Ping reply in 180 seconds.]
Faisal has joined #linux-sunxi
Quarx has joined #linux-sunxi
_massi has joined #linux-sunxi
<oliv3r>
wow
<oliv3r>
i just received an exciting e-mail from eva. we have got a technical contact officially now from allwinner, and she asked for a list of the main contributors to keep informed of Allwinner news and to also get in touch with the technical contact.
<oliv3r>
So if anybody objects to receiving email from AW, let me know and i'll try to get you removed from their list.
<Gerwin_J>
only i still don't get A80 SDK... only a A80 introduction brief with some GPIO pin out
<T0mW>
I just ordered one the SunLinx dev kits from taobao a few days ago, still waiting for the seller to ship it.
Black_Horseman has quit [Remote host closed the connection]
dudepdx has joined #linux-sunxi
<wens>
that pro a80 board looks large
dudepdx has quit [Read error: Connection reset by peer]
<libv>
oliv3r: your book is on that weixin link Gerwin_J just posted
<wens>
oliv3r: oh look
<oliv3r>
but i have a phone conference tomorrow about the title :p
nedko has quit [Quit: kernel panic]
kuldeepdhaka has joined #linux-sunxi
<bbrezillon>
quitte_: can you paste the errors you're seing when ubiattach fails .
<bbrezillon>
?
kuldeepdhaka has quit [Max SendQ exceeded]
<bbrezillon>
longsleep: 424 BB => that's a lot for a fresh NAND. Can you try to apply this patch http://code.bulix.org/p6gzsi-86808 and then launch a flash_erase on you mtd partition ?
lkcl has quit [Ping timeout: 250 seconds]
<bbrezillon>
longsleep: you'll have to remove the on BBT support (remove the DT property asking for on-flash-bbt), otherwise it will keep still consider these blocks as bad
<oliv3r>
they should have stolen the image from packt
kuldeepdhaka has joined #linux-sunxi
<bbrezillon>
longsleep: after erasing the NAND you should revert the patch and re-enable the on flash BBT
anthony_emtrion has joined #linux-sunxi
kuldeepdhaka has quit [Max SendQ exceeded]
kuldeepdhaka has joined #linux-sunxi
deasy has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
dack has joined #linux-sunxi
lkcl has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
miup has quit [Quit: WeeChat 0.4.3]
lkcl has quit [Ping timeout: 255 seconds]
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 255 seconds]
dudepdx has joined #linux-sunxi
<libv>
crap. my eyerolling at jsmirls DIV_ROUND has caused me to miss a semitime g1 on ebay which i had been oggling for a week
<libv>
by seconds.
<libv>
went for 2.01EUR
<oliv3r>
ohh wow
<oliv3r>
what's a semitime g1?
<libv>
would've given me an A10s quickly (since this aliexpress tosser still hasn't shipped the mele a210 i ordered, which will then take another 2 weeks), and would've finally documented this a10s based mk805
<libv>
oliv3r: you can ask iirc, hansg
<libv>
which means that you cannot ask the wiki.
<oliv3r>
i bought a jesrun hdmi 'stick' which is a10s
<oliv3r>
from dx
<libv>
oliv3r: NDH!
<oliv3r>
i know!
<oliv3r>
i allready took pictures :)
<oliv3r>
mripard_: do you have a video to go with your mainlining out of tree socs slides?
afaerber has joined #linux-sunxi
hansg has joined #linux-sunxi
* libv
is such a tosser.
dudepdx has quit [Ping timeout: 255 seconds]
<longsleep>
bbrezillon: Ok - i try this - with DT you mean the device tree and i need to modify this and then recompile my kernel right?
astr has quit [Ping timeout: 250 seconds]
<bbrezillon>
longsleep: yes I mean device tree, and yes you'll need to recompile your kernel and your dtb (which is automatically done if you run make without any specific target)
<longsleep>
bbrezillon: ok just wanted to make sure - i am still new to the names of the stuff involved
<bbrezillon>
longsleep: np
<longsleep>
bbrezillon: so i am using arch/arm/boot/dts/sun7i-a20-cubietruck.dts - which which settings define the on flash bbt? nand-ecc-mode = "hw" ?
ddc has joined #linux-sunxi
<bbrezillon>
longsleep: oh, you didn't enable the on flash BBT, perfect
<bbrezillon>
then you just have to recompile you kernel with my patch applied
<longsleep>
bbrezillon: ok :D
<longsleep>
bbrezillon: I need to learn about bbt settings in dt now though :)
dudepdx has joined #linux-sunxi
<bbrezillon>
longsleep: sorry, I don't remember who did what: everybody is testing the NAND driver at the same time (which is great BTW)
ddc has quit [Remote host closed the connection]
<bbrezillon>
longsleep: on flash BBT (Bad Block Table) table will (as it names implies ;-)) store the list of detected Bad in a NAND erase block
astr has joined #linux-sunxi
<bbrezillon>
longsleep: this is used to avoid scanning the whole flash chip for NAND detection at each boot, and thus speed up boot
<bbrezillon>
longsleep: for NAND Bad Block detection
<anthony_emtrion>
bbrezillon: and for info, when is it triggered/updated this BBT ?
dudepdx has quit [Ping timeout: 255 seconds]
<longsleep>
bbrezillon: I saw some a kernel flag for something like this
<bbrezillon>
longsleep: yep, this DT property just tell the NAND driver to set this flag ;-)
<oliv3r>
hmm, my framebuffer doesn't seem to be working. i did compile sunxi_disp into the kernel rather then making it a module
<bbrezillon>
anthony_emtrion: hey, you're on the sunxi chan too
<bbrezillon>
anthony_emtrion: every time a BB is detected
<anthony_emtrion>
bbrezillon: I follow Free Electron stuff since a long time (learnt a lot with the slides...)
<anthony_emtrion>
bbrezillon: and sunxi is something Free Electron work on and give info
<anthony_emtrion>
bbrezillon: albeit I'm not that keen on Chinese SoC
<anthony_emtrion>
bbrezillon: I might test one day with a Olimex board. the futur A31 for example.
<anthony_emtrion>
bbrezillon: thanks for the reply. a BB is detested when the driver does not succeed on write a Block ?
<bbrezillon>
anthony_emtrion: it's always written as bad when it does not succed at erasing a block
<bbrezillon>
anthony_emtrion: I'm not sure about writing a single page in a block
<Turl>
oliv3r: wow, cool news. Count me in :)
Quarx has joined #linux-sunxi
<bbrezillon>
anthony_emtrion: and when there's too many bitflips (i.e. above the bitflips_threshold) some wear leveling layers (like UBI) "torture" the block to test its reliability
<anthony_emtrion>
bbrezillon: ok so when it can't erase a block, it writes as bad in the BBT.
<bbrezillon>
anthony_emtrion: though I'm not sure what triggers the torture test (you should ask that on the #mtd chan ;-))
<anthony_emtrion>
bbrezillon: it seems there is a chan for every question :D
<anthony_emtrion>
bbrezillon: funny because I'm implementing something for High Reliability block driver called DataLight Reliance Nitro
<oliv3r>
Turl: any pointers to how to get the framebuffer to work
<oliv3r>
my custom compiled kernel doesn't work, fedora kernel does :)
<Turl>
oliv3r: eh, 3.4?
ddc has joined #linux-sunxi
<Turl>
make sure disp/lcd/hdmi are all =y
<oliv3r>
well this would be the boot console
<oliv3r>
oh er yeah
<oliv3r>
i did, any way to check that from a running kernel, to be sure?
dudepdx has joined #linux-sunxi
<oliv3r>
the kernel seems to like it all; Xorg is running and i can run guvcview
<oliv3r>
the monitor simply remains blank
<ddc>
bbrezilon : mtd channel In which server. There are a few but they. seems to be dead
<oliv3r>
nvm, wrong cable :p
<oliv3r>
well the hdmi->, displayport cable appearanlt ydidn't work
<longsleep>
bbrezillon: compiling the kernel with your erase patch now
<Turl>
sigh :p "and has a Mali-400MP2 GPU, which is capable of rendering high-definition video."
<Turl>
(also yay, mali)
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 240 seconds]
<wens>
anthony_emtrion: mainline won't have display that soon
makepi has joined #linux-sunxi
<anthony_emtrion>
wens: Sure I understand why.
dudepdx has joined #linux-sunxi
thedude has joined #linux-sunxi
<mripard_>
oliv3r: not yet
<mripard_>
anthony_emtrion: we don't have any hardware at the moment, so feel free to contribute :)
dudepdx has quit [Ping timeout: 255 seconds]
<anthony_emtrion>
mripard_: As soon as a cheap board is out why not ! :)
<longsleep>
bbrezillon: With your patch enabled flash_eraseall -N /dev/mtd2 ran without errors.
<longsleep>
bbrezillon: But blocks are still marked as bad.
<anthony_emtrion>
mripard_: I'll be there : Tuesday, October 14 • 15:30 - 16:20
<anthony_emtrion>
mripard_: ;) I'll need it !
<bbrezillon>
longsleep: you have to reboot
<mripard_>
you'll need it for what?
<longsleep>
bbrezillon: oh of course sorry - let me try
<bbrezillon>
longsleep: unless you already did :-)
<anthony_emtrion>
to bring up the A33 !
<longsleep>
bbrezillon: well it did not complain about a ton of bad blocks on boot now - looks promising
thedude has quit [Ping timeout: 240 seconds]
<longsleep>
bbrezillon: yeah now i can erase without -N and no error
<bbrezillon>
longsleep: now revert my patch
<bbrezillon>
recompile and reboot
<longsleep>
bbrezillon: ok doing so now
<bbrezillon>
longsleep: it should work fine now
<bbrezillon>
longsleep: and you can add on flash BBT support if you want to speed up your boot ;-)
<longsleep>
bbrezillon: so how do we avoid this issue without two different kernels?
<bbrezillon>
longsleep: you mean one with libnand and one with my driver ?
<longsleep>
bbrezillon: No i mean only with your driver. But a pre ininialized NAND coming from factory.
<bbrezillon>
longsleep: that should work fine with an fresh NAND
<oliv3r>
mripard_: nice slides though :)
<bbrezillon>
longsleep: I guess your device was already pre installed with an android version on it
<bbrezillon>
longsleep: right ?
<longsleep>
bbrezillon: yes exactly - and i flashed a lubuntu to it for testing too
<bbrezillon>
longsleep: that's the reason
<longsleep>
bbrezillon: but isnt that the case with all boxes one can normally buy as consumer?
<bbrezillon>
longsleep: both the kernel used for ubuntu and android are using libnand
<oliv3r>
mripard_: nand wasn't really REd, libnand was given to us in the past. just not updated versions :( (slide 22/32) the only RE work being done is VPU and some memory stuff I suppose sort of.
<bbrezillon>
longsleep: and libnand doesn't care about BB markers stored in the OOB area
<longsleep>
longsleep: Yeah - but what i meant is that one might always have this problem when updating to mainline with your drivers from pre installed libnand installation right?
<bbrezillon>
longsleep: yep
<mripard_>
oliv3r: ack. i'll change it for next time :)
<bbrezillon>
longsleep: I don't know it would work (and don't know much about libnand), but here might be a possible solution:
<longsleep>
bbrezillon: So that is essentially bad yes. I would consider this as a workaround but there should be an automatic solution or something easier in user space.
ddc has joined #linux-sunxi
<bbrezillon>
longsleep: boot on an MMC card with a libnand kernel, then ask for a full erasure of the NAND device
<oliv3r>
mripard_: you even put my name on the list :D
<oliv3r>
mripard_: i'll put all those names onto the list for eva, not sure about stefan, he kinda seems to have dissapeared
<oliv3r>
and i'll look at our ML for a few common contributors
<mripard_>
you can add ijc I guess
<bbrezillon>
(hopefully it will erase the NAND without writing new stuff on it, and with keep track of Bad Block)
<oliv3r>
mripard_: absolutly
<longsleep>
bbrezillon: Right that might work - but i would prefer something which can be done from a mainline booted kernel though :)
<bbrezillon>
longsleep: s/and with/and will/
<bbrezillon>
longsleep: that's almost impossible, unless there some BBT stored somewhere on the flash
<longsleep>
bbrezillon: With patch removed, still no bad blocks. So i consider this a valid fix for the problem with a ton of bad blocks when moving from libnand to mtd kernel.
<bbrezillon>
longsleep: I would not say a valid solution, just a working one :-)
<bbrezillon>
longsleep: erasing Bad Blocks is always a bad idea
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
<longsleep>
longsleep: True - but shouldnt they get marked bad again quickly if they are really bad?
<ddc>
bbrezillon: I'm wondering if this should work echo 1 > /debug/nanderasebb. without applying erasure patch
<bbrezillon>
longsleep: yes they should, but ddc case prooved it was not so easy ;-)
<bbrezillon>
ddc: wooh, is that a new one ?
<longsleep>
bbrezillon: I learned yesterday that nothing about the NAND is easy :)
<ddc>
setting the nanderasebb attribute of debugfs
<quitte>
bbrezillon: only found the kernel attaching it in the scrollbuffer - but it shouldn't make a difference: http://pastebin.com/hDbnKYfq
lkcl has quit [Ping timeout: 246 seconds]
<bbrezillon>
ddc: where did you find it ?
<bbrezillon>
ddc: I don't think it's a mainline feature :--
<bbrezillon>
:-(
<bbrezillon>
ddc: this feature has been discussed many times, but AFAICT, has never been accepted
xavia has joined #linux-sunxi
<bbrezillon>
quitte: can you show me your dts (sorry if I'm always asking the same things :-)) ?
<longsleep>
ddc: do you hae a link to lkml of that feature - looks useful to me
<bbrezillon>
longsleep: this is one of the threads
<quitte>
to something way lower. okay. I read that but didn't see a connection to my problem
dudepdx has joined #linux-sunxi
<bbrezillon>
quitte: no higer
<quitte>
hmm. ok it was the erase times then
<bbrezillon>
quitte: IIRC, the default threshold is 40
<bbrezillon>
quitte: (which is the ecc strength)
<quitte>
bbrezillon: how can you tell that is the problem?
<longsleep>
bbrezillon: 2005 wtf - thats old
<bbrezillon>
quitte: on MLC NANDs you often reach this limit beacuse of bit levels changing avor the time
<bbrezillon>
quitte: I'm not sure this is the problem, I say, we should try by changing that
<bbrezillon>
quitte: and this is the log that makes me think this might be the cause: [ 27.044142] UBI warning: init_volumes: static volume 0 misses -1 LEBs - corrupted
<quitte>
I read that as meaning the volume was corrupted... if it means tzhe LEB is corrupted I'd have to agree
<bbrezillon>
longsleep: another one => ttp://comments.gmane.org/gmane.linux.drivers.mtd/41624
dudepdx has quit [Ping timeout: 255 seconds]
<bbrezillon>
quitte: AFAIU the messages it says it miss 1 LEB, and this might be caused by wear leveling trying to copy a block with too many bitflips to another block
<longsleep>
bbrezillon: ok i see - so they say that its bad to delete the bad blocks table. Mhm i will need to think about this.
<quitte>
what happened to ddc ehen he erased the bbt? I did, too.
<longsleep>
bbrezillon: I have now added this to our workaround FAQ. If you get lots of bad blocks, compile kernel with patch, erase flash with ignoring bad blocks. Reboot with patch removed, bad blocks are gone.
<longsleep>
bbrezillon: Now i need to figure out regarding the chip support stuff.
<longsleep>
dack: well you do not seem to have the correct data on the nand
ddc has quit [Quit: ddc]
<dack>
longsleep: I mounted it, but never changed anything on there...
<longsleep>
dack: Mhm i suggest you flash nand again with Phoenixsuite - or boot with an sdcard and try to fix it.
zeRez has joined #linux-sunxi
<dack>
I don't have an image for Phoenixsuite and my linux image on sdcard can't access the nand
<libv>
pfff, that microsd adapter board is pretty shitty. why is this not the standard pin size, and why does this require yet another adapter?
<dack>
There's a "recovery" button on the device... I tried booting with that but no joy. I get a weird display on the monitor now, but serial still reports not being able to boot
<longsleep>
dack: so what is on your nand then? Isnt that available as image for Phoenixsuite?
<dack>
longsleep: I'm sure somewhere on the 'nets... but I have no idea where. I've contacted a few people and they haven't been able to give me anything.
<longsleep>
dack: Well i just started with sunxi - so i am not an expert but i would say if you have some device with software from some vendor they are the ones who have to provide the image.
<longsleep>
dack: Not sure if this can be recovered some other way.
<longsleep>
dack: You could try to build an sdcard with cubian (which has nand support) and see what you can do from there.
lkcl has quit [Ping timeout: 240 seconds]
zeRez has quit [Remote host closed the connection]
zeRez has joined #linux-sunxi
<libv>
ah, ok, it does somewhat fit
<libv>
dack: not this again
<libv>
dack: boot it into android
<dack>
libv: dude!!! :) that's what I'm trying to do!
<libv>
get a terminal app or an ssh server from the play store
<dack>
libv: I didn't do anything to what's on the NAND, but suddenly it won't boot into stock Android
<libv>
oh, it fails to boot now?
<dack>
libv: yes
<libv>
great, we ran into the libnand issue again
<dack>
libv: well, it fails to boot Android.. my sdcard with linux works fine. :P
<libv>
if you had followed the howto, you would have retrieved the data already
<libv>
the fact that you used that sdcard killed your android.
<dack>
libv: I didn't do anything to what's on the NAND so I have no idea why this would have happened nor would have following any wiki prevented it
<dack>
libv: how's that?
<libv>
dack: this is a known issue with our libnand code
<libv>
everyone has been sticking their heads in the sand on it
<dack>
libv: so, what's the issue exactly? It's modifying something on the NAND?
<libv>
yup
<libv>
now if i wasn't the only one working the wiki regularly and doing all sorts of random things, i would feel guilty now about not having fixed this already
<dack>
libv: I'm a little confused by terminology... is libnand the sunxi_nand driver for the kernel or the nand support in u-boot?
<libv>
our sunxi nand driver is older
<libv>
allwinner is not providing code for newer versions it ships (which is breaching the GPL)
<libv>
and this code is known to kill installations on at least cubietruck
Akagi201 has quit [Remote host closed the connection]
<dack>
libv: so, this is some other kernel module, not the sunxi_nand one? Where is that in the source tree?
<libv>
dack: if you had, after not finding a way to do fel, reverted to dealing with android, instead of trying to run a linux, you would've been fine
<libv>
dack: what does that matter?
<libv>
dack: your android is dead, and unless someone finally goes and figures out what messes this up, and fixes it, and perhaps provides you with a way of fixing this, it's going to remain dead
<dack>
libv: I want to see if this is something I was actually even using. I had started linux off the sdcard before and then ran Android after with no issue.
<libv>
dack: feel free to try
<libv>
but my a10s stick is no longer booting android anymore either after having successfully loaded libnand
<libv>
from a sunxi kernel
<libv>
luckily, i have a cubietruck that i can throw stuff at
<libv>
but...
<libv>
this delays my uboot code even further
<dack>
libv: okay, but which kernel module is this specifically? I'm using the 3.4 kernel and only tried the sunxi_nand one. Where is this other libnand thing?
<libv>
now if only people would work the wiki and do some menial tasks from time to time
<libv>
dack: i am talking about the 3.4 kernel
<libv>
dack: do know that further tinkering with your hw might further reduce the chance of us reviving the installation there
<libv>
i now have little other option but to go hunt down the issue on cubietruck
<dack>
libv: can I first confirm that I was actually using this libnand thing by checking the kernel config?
lkcl has joined #linux-sunxi
<libv>
dack: did you use defconfig?
<dack>
libv: yes, but minus a bunch of stuff and with my patch to rename the sunxi_nand to sunxi_nand.ko instead of nand.ko
<libv>
oh, that was you too?
<libv>
was that the same hw?
imcsk8 has quit [Quit: Reconnecting]
<ijc>
oliv3r, mripard_: What list am I being added to? ;-)
<dack>
I made that change to try to get NAND working on MK808C, but no luck. I tried it on this TXCZ_A20, but also no luck.
imcsk8 has joined #linux-sunxi
<libv>
does the mk808c still boot android?
<dack>
libv: yes. It's had no issues.
<libv>
oh, because it couldn't read the nand?
<libv>
or couldn't identify the flash module
<dack>
libv: neither device could read the nand. It said the "magic" was wrong and did nothing. I checked and the nand id's are listed in the source code as being supported, though.
<dack>
libv: but wait... I thought libnand != sunxi_nand ?
<libv>
aha, ok, so the partition magic difference was noticed
<libv>
anyway, i will now have to spend a lot of time doing that on the cubietruck.
<libv>
since noone else bothered to do so.
thedude has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 240 seconds]
<dack>
libv: after living with roommates I've learned to not get too hung up on what others should or shouldn't be doing. You only get frustrated and annoyed because you can only control what you can do.
<dack>
libv: I'm running a wiki too that I've had a lot of trouble getting other people involved... I feel the pain too. ;)
<dack>
libv: any way, is libnand sunxi_nand or not? All of my attempts at accessing the nand has been with sunxi_nand
_massi has quit [Remote host closed the connection]
thedude has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
astr has quit [Ping timeout: 272 seconds]
dudepdx has quit [Ping timeout: 255 seconds]
<dack>
oliv3r: wens: longsleep: Is libnand a uboot thing or a kernel module? And if a kernel module, is it the moniker for sunxi-3.4/drivers/block/sunxi_nand ?
<Turl>
dack: it's the same thing
quitte has quit [Read error: Connection reset by peer]
<dack>
Turl: Just to be completely sure, which things are the same?
<Turl>
we say libnand because there's a 'libnand' blob at times and some basic code shim
<Turl>
the problem is that allwinner changed something on it and released a newer version in the newer sdks
astr has joined #linux-sunxi
<Turl>
so it uses a new on-flash format or something
<Turl>
and the old code seems to choke on it and mess up somewhere
<dack>
Turl: ah.. okay, thanks for clearing that up!!! ^_^
thedude has quit [Ping timeout: 240 seconds]
<Turl>
np :)
<dack>
Turl: I still don't see how this could cause issues like I'm seeing, though. The libnand is failing to mount the nand but now I can't boot the stock Android.
<Turl>
dack: it may have tried to be smart and 'fix' it or something
<dack>
Turl: I guess it doesn't matter because it seems I need to reflash regardless. There's a button on my device to boot from the recovery partition, but that doesn't work either.
<Turl>
do you get zero output on uart?
<dack>
Turl: maybe.. but I've tried using it many times on another device and it's never done anything to the Android.
<dack>
Turl: I haven't done anything to the stock Android, though... I looked at some past serial logs with successful boots and they seem to diverge at "NB1 : nand_info_init fail"
<bbrezillon>
longsleep: a missing flag, and everything fall apart
pwhalen has quit [Ping timeout: 246 seconds]
dudepdx has joined #linux-sunxi
diego_r has quit [Quit: Konversation terminated!]
<bbrezillon>
longsleep: and as mripard_ (which is a really supportive co-worker BTW :D) suggested, this was all my fault => I tend to squash my fixes into existing commits, which definitely does not help when other developers want to base their work on my branches :-)
dudepdx has quit [Ping timeout: 272 seconds]
<bbrezillon>
longsleep: you should rebase your branch on mine, and in exchange I'll try to do incremental patches from now on :-)
pwhalen has joined #linux-sunxi
lkcl has joined #linux-sunxi
<libv>
dack: since you now ran into this issue big time, and i really would like to see this board supported as well, i will flash a new android to my cubietruck and then figure out why it is messing up and how we can fix it
<libv>
if it is at all fixable
<dack>
libv: that'd be awesome! I've tried contacting several suppliers too to see if I can get an image to simply reflash the device
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 246 seconds]
afaerber has quit [Quit: Verlassend]
konradoo77 has quit [Ping timeout: 255 seconds]
konradoo77 has joined #linux-sunxi
dudepdx has joined #linux-sunxi
<dack>
If I can get this unit working, I'm now able to get them for about $31 USD for an order as small as 5. (for some reason the guy just stopped selling them individually after I got mine)
<dack>
As for using it as a media center... it seemed pretty terrible. ^_^
dudepdx has quit [Ping timeout: 255 seconds]
afaerber has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
alexvf has quit [Ping timeout: 246 seconds]
Akagi201 has quit [Ping timeout: 260 seconds]
dudepdx has joined #linux-sunxi
guest385 has joined #linux-sunxi
dudepdx has quit [Ping timeout: 255 seconds]
<guest385>
is there some technical limitation to build kitkat for A10? or noone has tried it yet?
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 255 seconds]
bonbons has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
amitk has quit [Quit: leaving]
libv has joined #linux-sunxi
wingrime has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
guest385 has quit [Quit: Page closed]
<libv>
now really.
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
marcin_ has quit [Quit: Konversation terminated!]
lkcl has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
zeRez has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
__builtin_trap has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
physis has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<__builtin_trap>
does anyone know whether the allwinner SoCs execute bootloader code in secure state or in non-secure state? because this AM335x SoC seems to execute all non-boot-ROM code in nonsecure state and i want to have access to the secure state and i'm considering getting a board with an allwinner SoC
<libv>
mnemoc: is there room to unpack the A31 and other SDKs?
Gerwin_J has quit [Ping timeout: 250 seconds]
<Turl>
__builtin_trap: ijc can probably answer that
<mripard_>
__builtin_trap: iirc, the bootloader is started in secure
<Turl>
libv: I can check if you tell me where
<libv>
Turl: i am filling in the urls on the a23 SDK gpl violations
<libv>
i think i/someone else for a change should go do the same for a31, a33 and a80, in as far as SDKs are available
<Turl>
libv: there's around 100G free on that partition
<Turl>
the A23 SDK is 13G
<__builtin_trap>
can someone try __asm__ __volatile__("MRC p15, 0, %0, c1, c1, 0\n" : "=r" (scr) : : ); on an allwinner SoC and tell me what is value of scr?
<Turl>
you can probably unpack a handful, but not every single one. Is there any value in unpacking them?