Hi,
On 25-12-14 17:13, Siarhei Siamashka wrote:
On Thu, 25 Dec 2014 11:14:23 +0100
Hans de Goede <hdego...@redhat.com> wrote:
Hi,
On 25-12-14 03:07, Siarhei Siamashka wrote:
On Wed, 24 Dec 2014 19:39:33 +0200
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
On Wed, 24 Dec 2014 18:58:17 +0200
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
After reboot, reset or even short power off, DRAM typically retains
the old stale data for some period of time (for this type of memory,
the bits of data are stored in slowly discharging capacitors).
The current sun6i/sun8i DRAM size detection logic, which is
inherited from the Allwinner code, relies on using a large magic
signature with the hope that it is unique enough and unlikely to
ever accidentally match this leftover garbage data in RAM. But
this approach is inherently unsafe, as can be demonstrated using
the following test program:
/***** A testcase for reproducing the problem ******/
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
void main(int argc, char *argv[])
{
size_t size, i;
uint32_t *buf;
/* Allocate the buffer */
if (argc < 2 || !(size = (size_t)atoi(argv[1]) * 1048576) ||
!(buf = malloc(size))) {
printf("Need buffer size in MiB as a cmdline argument\n");
exit(1);
}
/* Fill it with the Allwinner DRAM "magic" values */
for (i = 0; i < size / 4; i++)
buf[i] = 0xaa55aa55 + ((uintptr_t)&buf[i] / 4) % 64;
/* Try to reboot */
system("reboot");
/* And wait */
for (;;) {}
}
/***************************************************/
If this test program is run on the device (giving it a large
chunk of memory), then the DRAM size detection logic in u-boot
gets confused after reboot and fails to initialize DRAM properly.
A better approach is not to rely on luck and abstain from making
any assumptions about the properties of the leftover garbage
data in RAM. Instead just use a more reliable code for testing
whether two different addresses refer to the same memory location.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
Thanks for the patch, it looks good to me, I'll give it a test on my
own sun6i and sun8i boards when I find some time to do so.
Thanks.
---
Done only very limited testing on MSI Primo81 tablet (Allwinner A31s),
which is currently a rather impractical device for doing any sun6i code
development due to having no access to the serial console, USB or other
convenient ways to interact with the device.
Got a serial console on my tablet via a MicroSD breakout board. So I'm
retracting this statement :-)
Nice. Note that my personal u-boot git repo has lcd support in the sunxi-wip
branch, so that we can have at least u-boot output messages on tablets, but
I guess that FEL + console via microsd breakout works too.
HDMI works too. Too bad that neither LCD nor HDMI can handle input. But
at least the UART console can. I was hoping to just get WLAN working as
the next step in order to use it instead of the UART console for
communicating with the device.
The MSI Primo81 is quite a nice tablet:
* has a HDMI connector (can run a real desktop Linux system on a HDMI
monitor, that is if we get USB OTG working)
* has access to the hardware FEL button (this makes the device truly
unbrickable)
* has a sturdy slim metal frame, but a downside is that it may be
more difficult/dangerous to disassemble
* has an IPS LCD display with good colors and viewing angles but
unfortunately relatively low resolution (1024x768)
* The current price seems to be around or under 100 EUR on amazon.de
and other places.
If you can point me to a fex file for your board I can add a defconfig for
your tablet with hopefully working LCD support.
If you really insist on doing this yourself, then you can find the fex
file in the sunxi-boards git repository:
https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31s/msi_primo81.fex
In any case, this tablet is not going to be really usable until the
mainline kernel gets USB OTG support. Which gives us some weeks/months
to take care of the necessary dts/defconfig files.
Ack, I offered to create the defconfig since the alternative was to
write a short howto on the VIDEO_LCD_MODE Kconfig, but since I've done
that now anyways I'll happily wait for you to provide a defconfig.
And indeed, the DRAM parameters get incorrectly detected after running
the test program (the system fails to boot later on):
Bummer, does this happen with both the old and the new memcmp functions ?
Everything works fine after the "sunxi: Fix buggy sun6i/sun8i DRAM size
detection logic" patch is applied. Sorry for not stating this clearly
enough.
Ah, ok, that is good to know.
Without the patch and after running the test program, I just see that
the system fails to boot. Typically with the HDMI not coming up at all.
The UART console allows to see why it fails and makes debugging
possible.
Ack.
I'll send you a private mail with a statically linked util I've written
called mmio-dump, which can dump any hardware address from within android,
assuming you've an adb shell as root on your tablet, you can then copy
this to /system/bin and use it to dump the dram controller registers,
compare with what u-boot selects and see where we're getting things wrong.
Usage is e.g.:
mmio-dump 0x01c62000 64
We are not getting anything that behaves obviously wrong, so I would
postpone this check for a later date.
I had root on this tablet for a short while (just for extracting fex),
but not anymore. Gaining root in Android is a pain on this tablet. And
one rooting package that works is flagged as a trojan on virustotal.com
(maybe a bogus report, but I don't want to take any risks). Since I'm
actually using this tablet as an Android tablet, trying to root it
again only for running mmio-dump would cause way too much disruption
(backing up and restoring everything).
But I'm glad that you are actually using mmio dumping yourself. You did
not sound like a big fan of it earlier, this had me seriously worried:
http://lists.denx.de/pipermail/u-boot/2014-December/199429.html
Oh, no I do use mmio dumping frequently to check various things, esp.
to compare the dram setup between what boot0 / u-boot does. I just do not
see much use in a meminfo like tool for a31 / a23 for end users, since for
double checking all register matter, and for a simple bringup the info in
the fex is enough.
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
