<RSpliet>
for some of the docs us nouveau ppl gathered
<RSpliet>
might help understand the XCL (Cas Latency) and XWR (Write Recovery) values in +0x18 ;-)
<ssvb>
yes, everything is pretty much explained in the DDR3 spec
<ssvb>
which is unfortunately not available in the public access, but some snippets of it are replicated in freely available PDFs from the DRAM manufacturers
<ssvb>
RSpliet: we only have troubles with the bits which are specific to this particular DRAM controller, such as host ports arbitration and priority
<RSpliet>
ah yes, the "impossible to reverse engineer" bits
<ssvb>
the support for the A10/A13/A20 DRAM controller is already in a reasonably good shape and we know almost everything
<RSpliet>
thar's remarkably good :-) most RAM controller vendors tend to be a lot more secretive about their design
gianMOD has quit [Remote host closed the connection]
MY123 has joined #linux-sunxi
<ssvb>
all thanks to the Allwinner boot0 sources, the Rockchips sources (they use mostly the same DRAM controller) and TI Keystone2 documentation
<ssvb>
thankfully, every SoC designer seems to be licensing mostly the same DRAM controller IP from just a few vendors, so it is possible to find a lot of information by looking around
<ssvb>
the rest is trial and error testing to confirm that the retrieved information actually makes sense :-)
<RSpliet>
I wouldn't have expected otherwise, there's some complex logic under the bonnet
<ssvb>
the clarity of the documentation in the linux-sunxi wiki can be still improved, the MR registers description can be replicated from the DDR3 manuals (so that people don't need to refer the external documentation), etc.
<ssvb>
but it's a wiki, so everyone can contribute :-)
<ssvb>
or at least ping me if something is poorly explained
<ssvb>
MY123: what's the Raspberry Pi BRCM story? are the bootloader sources still not available?
<MY123>
ssvb, did they release something?
<ssvb>
how would I know?
<MY123>
ssvb, so there is only the RPi1 RAM init code
<MY123>
old code which works on a 256 and 512MB RPi
pmattern has joined #linux-sunxi
<ssvb>
MY123: has anybody compared the DRAM controller hardware register dumps for the normal vs. overclocked config?
<ssvb>
this could reveal some useful information
<MY123>
ssvb, the RAM frequency is scaled dynamically
<MY123>
so it is not that useful
<MY123>
ssvb, and the tracer inits the HDMI but stops at starting SMP
<MY123>
(just before starting the ARM core)
<ssvb>
well, even with the dynamic scaling, you could probably see whether anything is getting changed in these hardware registers at runtime
<MY123>
ssvb, I don't have an UART for now
<ssvb>
UART? I would guess that you can read these registers from /dev/mem via something like devmem2 or some other custom tool
<MY123>
ssvb, hidden from the ARM
<ssvb>
so not all of the address space is available to ARM?
<MY123>
ssvb, and I managed to lock the system with a VC4 dumper (I used a VC4/ARM busyloop)
<MY123>
see github.com/freeblob/samples
<MY123>
ssvb, that is crash-prone
<ssvb>
anyway, if you can watch these hardware registers, then you could probably try to find if there are any other similar DRAM controllers (either in the other more open source friendly Broadcom SoCs or maybe even in the SoCs of the other vendors)
y0g1 has joined #linux-sunxi
<MY123>
ssvb, the BCM21153 has no blob needed to boot, but needs one at runtime for 3G
<MY123>
(if you don't use mobile, then it's fine)
dev1990 has joined #linux-sunxi
<ssvb>
but it's nice to know that the Raspberry Pi bootloader is being reverse engineered, that's where they are currently lagging behind sunxi
<ssvb>
sunxi could do a bit better with the graphics support in the mainline kernel though
<MY123>
ssvb, the state is already pretty good. USB OK, RAM OK, 250MHz VC4 clock managed
<MY123>
(you see that the ARM is missing :P)
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 244 seconds]
<MY123>
ssvb, I think that bringing GCC and Linux to the VC4 is easier than powering on the ARM
<ssvb>
:)
bsdfox has quit [Ping timeout: 256 seconds]
y0g1 has quit [Quit: brb]
gianMOD has joined #linux-sunxi
<MY123>
ssvb, the problem is that there is a MMU in the VC4 for DRM use, but there is not even blobs for it
<MY123>
(so no RE possible)
bsdfox has joined #linux-sunxi
<MY123>
ssvb, I see signs of it in obsufucated Roku2 code
gianMOD has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
libcg has joined #linux-sunxi
konradoo87 has quit [Ping timeout: 244 seconds]
dev1990_ has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
dev1990 has quit [Ping timeout: 272 seconds]
Renard has joined #linux-sunxi
rz2k has joined #linux-sunxi
rz2k has quit [Remote host closed the connection]
ricardocrudo_ has quit [Ping timeout: 272 seconds]
konradoo87 has joined #linux-sunxi
indy has quit [Ping timeout: 256 seconds]
ricardocrudo_ has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 265 seconds]
ricardocrudo_ has quit [Remote host closed the connection]
indy has joined #linux-sunxi
libcg has quit [Ping timeout: 272 seconds]
ssvb has quit [Ping timeout: 264 seconds]
gianMOD has quit [Remote host closed the connection]
<ssvb>
I mean what kind of u-boot, dram settings and the kernel
<atsampson>
ssvb: you're thinking that with higher MBUS speeds, it can issue consecutive commands faster?
* atsampson
adds to the list of things to try when he's got a chance
<pirea>
dram settings u-boot git default just clock is set to 552
<pirea>
kernel sunxi-3.4
<ssvb>
atsampson: yes, low MBUS clock frequency reduces the memory bandwidth, so I would assume that the commands submission is a bit "sparse"
<ssvb>
atsampson: and potentially something bad might be happening on tight back-to-back reads/writes, but low MBUS speed may be making it harder to reproduce
<ssvb>
atsampson: regarding the suspected rowhammer problem, samsung chips seem to be using most bleeding edge manufacturing processes
<ssvb>
atsampson: the rowhammer papers don't name the exact chip manufacturers, but they mention that the problem is more likely to be present in the modern high density chips
konradoo77 has quit [Ping timeout: 265 seconds]
<ssvb>
atsampson: right now it looks like there may be two potential culprits - 1) some bad write related timings or transitions between reads and writes 2) rowhammer
paulk-aldrin has quit [Remote host closed the connection]
<ssvb>
atsampson: regarding the A20 SoC itself, my Cubietruck can run MBUS at 600MHz
<ssvb>
atsampson: that's why the problems on pcduino3 nano with 400MHz MBUS seem to be rather suspicious
<ssvb>
atsampson: moreover, Cubieboard2/Cubietruck are using 400MHz MBUS with the legacy u-boot-sunxi bootloader (the FAST_MBUS option)
<ssvb>
pirea: I don't think that "dram settings u-boot git default just clock is set to 552" is a reliable configuration
<ssvb>
pirea: first try the default dram clock speed with the sunxi-3.4 kernel, and also it is better to use the up to date sunxi-3.4 git with extra patches - http://stuff.offog.org/pcDuino3Nano/linux34-patches/
cubeast has quit [Quit: Leaving]
bengal has quit [Quit: Leaving]
ricardocrudo has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
<pirea>
ssvb default doesn't work
<ssvb>
pirea: it should
<ssvb>
how does it fail?
ricardocrudo__ has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 255 seconds]
<ssvb>
like, are there any logs?
konradoo77 has joined #linux-sunxi
ricardocrudo_ has quit [Ping timeout: 252 seconds]
ricardocrudo_ has joined #linux-sunxi
ricardocrudo__ has quit [Ping timeout: 252 seconds]
ricardocrudo_ has quit [Ping timeout: 252 seconds]
jinzo has joined #linux-sunxi
gianMOD has joined #linux-sunxi
diego71 has quit [Ping timeout: 256 seconds]
diego71 has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
ricardocrudo has quit [Ping timeout: 272 seconds]
juser123 has quit [Ping timeout: 246 seconds]
konradoo87 has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 265 seconds]
ganbold_ has quit [Ping timeout: 255 seconds]
ganbold_ has joined #linux-sunxi
jinzo has quit [Read error: Connection reset by peer]
jinzo has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
ricardocrudo__ has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 272 seconds]
ricardocrudo_ has quit [Ping timeout: 256 seconds]
domidumont has quit [Ping timeout: 246 seconds]
gianMOD has joined #linux-sunxi
konradoo87 has quit [Ping timeout: 256 seconds]
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 244 seconds]
konradoo77 has joined #linux-sunxi
Wizzup has quit [Ping timeout: 246 seconds]
Wizzup has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
FDCX_ has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
von_fritz has quit [Quit: Don't Panic]
RSpliet has quit [Read error: Connection reset by peer]
RSpliet has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
konradoo77 has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
bsdfox has quit [Ping timeout: 246 seconds]
dev1990_ has quit [Remote host closed the connection]
bsdfox has joined #linux-sunxi
dev1990 has joined #linux-sunxi
libcg has quit [Ping timeout: 272 seconds]
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi
ricardocrudo__ has quit [Ping timeout: 250 seconds]
jinzo has quit [Quit: Leaving]
pmattern has quit [Quit: Genug für heute.]
ricardocrudo__ has joined #linux-sunxi
FreezingAlt has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 255 seconds]
konradoo87 has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
konradoo77 has quit [Ping timeout: 250 seconds]
gianMOD has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
gianMOD has quit [Ping timeout: 240 seconds]
ricardocrudo__ has quit [Ping timeout: 244 seconds]