<RSpliet>
interestingly this mechanism, if it works in the way described there, will only work if the page size is 8KiB
<RSpliet>
maybe 4KiB... but with a page size of 1KiB the boot partition would have to be smaller than u-boot-sunxi-with-spl
<bbrezillon>
RSpliet: I guess they are assuming the NAND to have at least 64 pages per blocks
<bbrezillon>
the page size shouldn't be a problem
<bbrezillon>
RSpliet: the other thing I'm wondering is whether we should put the SPL and u-boot binaries in the same block
<RSpliet>
bbrezillon: I don't see why not
<bbrezillon>
because this implies using a pretty poor random seed table
<bbrezillon>
which means you might be more prone to bitflips
<RSpliet>
well sure, but is that a problem for a blob that is generally used read-only
<RSpliet>
?
<RSpliet>
I read your part on how bit reads could trigger bit flips in adjacent cells
<bbrezillon>
actually the problem is not when you read it, but you might flash a u-boot image which might contain too many bitflips from the beginning
<RSpliet>
but... let's put it differently, I don't see how randomisation would change that. ECC might, but the ECC settings required by BROM are pretty strong
kaspter has quit [Remote host closed the connection]
cajg has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<bbrezillon>
for the SPL, you're only writing a limited number of pages, and thus potentially limit the 'repeatable pattern issue', but the u-boot image is a lot bigger, which means it may potentially be less robust to this issue
<bbrezillon>
RSpliet: but let's put this problem aside for now
<mripard>
next issue, where do we store the environment ? :)
<bbrezillon>
mripard: they should definitely be in a different partition
<bbrezillon>
otherwise you won't be able to update the environment without risking to corrupt the u-boot/SPL image
naobsd has joined #linux-sunxi
kaspter has joined #linux-sunxi
<RSpliet>
bbrezillon: I agree btw that using page mode would be a great next step... but I think we implement that better in a follow-up patch
<RSpliet>
it's simple and understood, SPL does it too... but it might require some shoving and shifting of driver logic
<bbrezillon>
RSpliet: BTW, have you tried replacing all the memcpy_toio/fromio ?
<RSpliet>
with memcpy?
<bbrezillon>
yep
awe00 has joined #linux-sunxi
ddc has joined #linux-sunxi
<RSpliet>
I was looking into it
<bbrezillon>
RSpliet: well, for the page mode, we'll still have to check a few things before using it, like is it really working for all the NAND chips (actually for all the page sizes), and if it's not we'll have to fallback to the standard mode
<RSpliet>
bbrezillon: I think the Page mode is actually the ECC block mode
<RSpliet>
and it should work for ECC step sizes of 512B and 1KB
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
hero100 has quit [Ping timeout: 255 seconds]
<libv>
rellla: i am not sure whether this stephan guy knows what a "freelancer" costs
ddc has quit [Quit: Page closed]
<bbrezillon>
RSpliet: yes, but I was more talking about the page size, the thing you configure in the NFC_PAGE_SIZE field
<mripard>
libv: but he'll give you $100 !
<mripard>
:)
<bbrezillon>
apparently the controller supports pages which goes from 1KB to 16KB, so we shouldn't bother about that right now
<bbrezillon>
(I don't know any NAND chip with 32KB pages)
GPenguin has quit [Ping timeout: 256 seconds]
<RSpliet>
not sure if they exist... page size tends to grow proportionally with the NAND size, and at some point you're better off deciding to just stick more chips on there and distribute your data over them
hero100 has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
GPenguin has joined #linux-sunxi
<bbrezillon>
RSpliet: this still leaves the old NAND chips with page < 512 bytes, but I'm not sure it makes sense to support them anyway
<wens>
mripard: where do you think i should put the rsb stuff? drivers/rsb or drivers/soc/sunxi/rsb?
<RSpliet>
bbrezillon: I don't think anybody found a use-case for combining legacy NAND with Allwinner
<RSpliet>
cheap tablet builders can get better value for money, hard real-time systems folks are afraid of Allwinner
<mripard>
wens: I guess it depends on what your code look like
<wens>
i guess it can be generic enough to put under drivers/, but i doubt we'll see it in other vendors
<wens>
i don't know what's the criteria for putting stuff under drivers/soc/ though
<mripard>
yeah, but I mean, if it's a simple regmap, then you don't need anything else
hero100 has quit [Ping timeout: 250 seconds]
<wens>
i guess moving them around is easy enough. i'll start with drivers/ then
flyhorse has joined #linux-sunxi
flyhorse_zvBiL has quit [Read error: Connection reset by peer]
hero100 has joined #linux-sunxi
flyhorse_VgYBe has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
paulk-aldrin has joined #linux-sunxi
<libv>
mripard: :)
alexvf has joined #linux-sunxi
hansg has joined #linux-sunxi
cajg has quit [Quit: WeeChat 1.2]
cajg has joined #linux-sunxi
joost_dtn has joined #linux-sunxi
<RSpliet>
bbrezillon: changing memcpy_fromio to memcpy doesn't make any difference in boot-time
<RSpliet>
so for me the morale of the story is as I assumed.
<RSpliet>
device IO is relatively expensive, and it pays off having a minion to do it for you :-)
gianMOD has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
flyhorse has joined #linux-sunxi
flyhorse_VgYBe has quit [Read error: Connection reset by peer]
<RSpliet>
bbrezillon: right, okay... I'm going to get back on that conclusion
<RSpliet>
yes, PIO is faster if we use memcpy instead of memcpy_fromio
<RSpliet>
and even faster than DMA
<RSpliet>
by another 4-5s
<RSpliet>
(measured in boot-time only... it's hardly a benchmark, but it's what I care about most atm
<RSpliet>
)
<wens>
quick grep only shows some #defines for memcpy_fromio, which is just memcpy with a cast
paulk-aldrin has quit [Remote host closed the connection]
<bbrezillon>
RSpliet: hehe, what did you do wrong in your first attempt ?
<RSpliet>
wrong DTS files, resuling in wrong clock freqs used
<bbrezillon>
ok, these results seems more sensible than the previous ones
<bbrezillon>
do you mind sending a patch replacing all memcpy_toio/fromio by regular memcpys ?
<bbrezillon>
RSpliet: ^
<RSpliet>
I don't mind, but I can't judge whether it's actually correct
<RSpliet>
it just... works
<RSpliet>
and in practice I also know platform-independence doesn't matter, but... I can't verify this :-)
ptitnuage has joined #linux-sunxi
<ptitnuage>
hello everybody
<ptitnuage>
i would like to ask if someone know about sunxi support on A23 tablets: I saw some month ago a post of someone who post a link to a working uboot with DRAM init and SPL in hos git repo, but i don't know if this permit to boot a kernel...
<bbrezillon>
though this should be easily ported to ARM
<bbrezillon>
anyway, modifying this kind of thing might introduce other bugs in other ARM platforms :-/
<RSpliet>
that's why you need a good reviewer for these sorts of patches :-P
<bbrezillon>
RSpliet: moving from memcpy_toio/fromio in the sunxi NAND driver is safe
<bbrezillon>
sorry, should be safe
<bbrezillon>
if if you really want to be sure, you can add a call to rmb() after the memcpy reading data from the SRAM and a call to wmb() after writing data to the SRAM
<ptitnuage>
i would like to ask if someone know about sunxi support on A23 tablets: I saw some month ago a post of someone who post a link to a working uboot with DRAM init and SPL in hos git repo, but i don't know if this permit to boot a kernel...
<NiteHawk>
ptitnuage: "u-boot-sunxi has basic support for A23, which includes UART console (including R_UART) and MMC. Disclaimer: no one has actually booted a kernel with this yet."
flyhorse_XesYt has quit [Read error: Connection reset by peer]
ptitnuage has joined #linux-sunxi
naobsd has joined #linux-sunxi
<libv>
plaes: yup :)
<BroderTuck>
What's holding up a v3 of the H3 patchset?
premoboss has joined #linux-sunxi
flyhorse_kpblY has joined #linux-sunxi
jinzo has joined #linux-sunxi
<WarheadsSE>
libv / plaes : but but, exploit the developers who ....
flyhorse has quit [Read error: Connection reset by peer]
avph has quit [Read error: Connection reset by peer]
marcin_ has quit [Ping timeout: 264 seconds]
<ptitnuage>
niteHawk: thanks, i already read the A23 page, but as someone released a working uboot for A23, i wondered if anything changed...
<ptitnuage>
niteHawk: the A23 page seem outdated, since someone got dram working and the page still saying it's not working...
prz has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<nove>
rellla: i finally looked at what you had asked me two times already, but it appears that the maf hardware block doesn't exist in sun5i, i am only getting zeros from the supposed registers
<RSpliet>
nove: it's clock is not gated in the CCU registers?
<rellla>
have you any sun4i/sun7i re-setup?
<wens>
crap... seems my email forwarder can't get mail from allwinner folks :(
<bbrezillon>
no need to change those memcpy_to/fromio calls
avph has joined #linux-sunxi
<bbrezillon>
RSpliet: not sure this will make it to mainline though (there was another attempt back in 2012)
<RSpliet>
Russel King has a backdoor to mainline, right ?
<bbrezillon>
hm, it's definitely easier for him to get things in, but if it breaks someones code, I'm not sure he can ignore it ;-)
<RSpliet>
heh, well, he, Will and Powel know what they're doing
<RSpliet>
I'm guessing it's lined up for kernel 4.2
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
kaspter has joined #linux-sunxi
<rellla>
nove: DIT_MODE_MAF (0x2) from our 3.4 is called DIT_MODE_RESERVED in allwinner's code on github and DIT_MODE_MAF_BOB get's named DIT_MODE_MAF now. this is all messed up ... :(
kaspter has quit [Remote host closed the connection]
<nove>
rellla: maybe my guess of being independent of decoding is wrong, (it need to get the frame size from somewhere, but why then it needs to be given the address of the just decoded frame)
<bbrezillon>
RSpliet: what do you think of Yassin's suggestion regarding the u-boot NAND driver (use sunxi specific commands until we all the randomizer and per-partition stuff are merged in Linux)
<topi`>
wow, Allwinner has joined Linux Foundation
<bbrezillon>
?
kaspter has joined #linux-sunxi
<RSpliet>
bbrezillon: well, as I explained I don't see a big neccessity for per-partition settings for U-Boot
<RSpliet>
it's a good feature, but it can wait
<RSpliet>
because really most people are only interested in the one partition that contains UBI (or whatever boot part they have)
<topi`>
I wish AW would also participate in Linaro... then we would get decent mainline linux support
<RSpliet>
I understand from your e-mail that regardless of the per-partition stuff, randomisation is not going to happen upstream either?
<bbrezillon>
yes, but still, the randomizer, empty page table (and probably other minor changes) are not mainlined yet, and I doubt they'll be accepted in their current state
<RSpliet>
I'm not too happy about a custom command because it will create a legacy
<bbrezillon>
what about having a u-boot driver that is as close as possible to the mainline one, and add a few functions to tweak the behavior
<libv>
i warned that this might have meant that allwinner ticked the "open source" marketing box.
<libv>
and guess what...
<bbrezillon>
RSpliet: oh, maybe we can hardcode instead of letting the user decide the value for these parameters
<mripard>
RSpliet: everything you're going to do is going to create a legacy
<libv>
topi`: read the comments to my latest blog entry for what good linaro is
<bbrezillon>
my point is: we should avoid modifying the MTD layer until the Linux MTD guys have agreed on the approach
<RSpliet>
bbrezillon: I agree :-)
<bbrezillon>
RSpliet: ok great! could you rework you series taking this into account
<MY123>
Lemon Pi :P
<RSpliet>
I'll see what I can do; I have my "focus meeting" tomorrow, leaving the company in two weeks
<RSpliet>
U-Boot interests might conflict with company interest (of making sure Oliv3r can pick up where I leave) ;-)
<bbrezillon>
RSpliet: yes I know, that's why I'm asking that now ;-)
<RSpliet>
so I'll let you know tomorrow whether I can free up some time or not
<bbrezillon>
RSpliet: ok, that's what I was gonna ask
<bbrezillon>
I'll take over if you can't finish it
physis has joined #linux-sunxi
<topi`>
libv: I think the point of contention is not really Linaro or anything else, but just ARM and their weird jealousy of the Mali architecture
<topi`>
however, look at NVIDIA if you want to understand what "jealousy" means
<topi`>
I think it's pretty standard on the 3D-chip-vendor-world to wrap their architectures in a veil of secrecy and lawsuits (and binary drivers)
physis has quit [Ping timeout: 256 seconds]
<libv>
topi`: heh
<libv>
what i meant to show was that linaro is not something holy or an unconditional force of good
<libv>
do not expect them to take any stance.
<MY123>
libv, Linaro is destroying linux-sunxi
<MY123>
(much less interesting for AllwinnerT)
<topi`>
libv: did you work on the Nokia N9? (the goddamn old SGX GPU)
<libv>
yes.
<topi`>
libv: this is funny, then we must know a lot of the same ppl
<libv>
i am using it right now to get network.
<topi`>
libv: I was the maintainer of Xorg on the N900
<topi`>
after Daniel Stone quit
<topi`>
the main pain point, unmistakenly, being the SGX
<libv>
topi`: when he left for collabora, you mean
<topi`>
yeah
<libv>
he properly "quit" in Q3 2010
<topi`>
wrong wording :)
<libv>
when he didn't show up for anything anymore, and he couldn't get properly fired from the team as no-one could reach him
<topi`>
that's quite typical of him :)
<libv>
the hacking of the radeonhd repo was a response to him thinking i politiced him out.
<libv>
politicked even
<topi`>
I never realized how politicized the OSS world had become, especially in the corporate<->OSS interface
<libv>
even though he claimed he had absolutely no role in that, apart from getting drunk with adam jackson and supossedly handing adam his fd.o root access
<libv>
it happened about a month after he got tossed from the team
<libv>
if he had been honest, he would've been dumped from collabora
<libv>
tbh, most people who are not as politically affiliated would've gotten dumped on the first count already
<topi`>
it's easier to live as a consultant nowadays
<topi`>
I was never a Xorg (or any other graphics-related) contributor anyways
<topi`>
the only reason my boss put me there was because I had hacked some XF 4.0 support in a S3 864 chip of yore
<topi`>
but i'm just a hacker
avph has quit [Ping timeout: 244 seconds]
avph has joined #linux-sunxi
<libv>
topi`: then you must've worked with harald koenig
<libv>
on s3
reinforce has joined #linux-sunxi
<libv>
topi`: if you remember that, and you happen to be on an open source conference in europe, and see a neptunus like character: talk to him, he gladly reminisces about his s3 hacking days
<libv>
topi`: did you learn that oliver mcfadden died, he ported q3a for n900 and later on joined nokia
<plaes>
o_O
<plaes>
So that's why he disappeared :(
philippe_fouquet has quit [Remote host closed the connection]
robogoat has quit [Ping timeout: 276 seconds]
robogoat has joined #linux-sunxi
awe00 has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
hansg has quit [Remote host closed the connection]
iamfrankenstein has quit [Quit: iamfrankenstein]
kaspter has quit [Ping timeout: 276 seconds]
jinzo has quit [Quit: Leaving]
Andy-D has quit [Ping timeout: 264 seconds]
khuey|away is now known as khuey
avph has quit [Ping timeout: 246 seconds]
awe00 has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
jinzo has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
indy has quit [Ping timeout: 246 seconds]
indy has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
physis has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 265 seconds]
physis has quit [Ping timeout: 272 seconds]
avph has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
gianMOD has quit [Ping timeout: 276 seconds]
flyhorse has joined #linux-sunxi
flyhorse_kpblY has quit [Read error: Connection reset by peer]