[SOLVED] Pine64+ 2GB shows up as 1GB to the world

[valant]

Hi. I have a 2GB Pine64+ and have armbian on it.

 

Yes, it's not new, but I noticed the problem only now.   It's because my use - in short, I use these boards for hobbyistic low level programming - say an OS loader writing, so it's flash and test, never been looking into linux too deep - only needed utilities. staring at the top is not of that set.

Now, when reached the DT parsing, passed by uboot, on this board, my loader, noticed 1GB of RAM... Basically, 1GB, as I see, is a default value set in the dts for pine64-plus yet. The DT is not updated on the fly by uboot, as it looks should be. and when I went to Linux, I saw the same - it sees it as 1GB! I don't see different downloads for variants of this board, so how does armbian distinguish between them? Is that discrimination being done right? I saw in the output, that uboot does see 2GB of RAM, still passes stale information in the DT. What is this, how do you think, is it my miserable fault, a known problem, got it fixed now? Maybe a lot of people keep using their 2GB models not even suspecting linux sees only 1GB?

[Igor]

On 5/10/2019 at 12:47 AM, valant said:

is it my miserable fault, a known problem, got it fixed now

 

Perhaps an image from the download section doesn't have this problem ... you are using some very old build. I only have two Pinebooks and on both 2Gb memory is properly detected.

 

Fixing this stock garbage (kernel 3.10.y / legacy u-boot) is pointless, while 2G should work OOB with a modern kernel.

 

Try.

[blastiko]

Hi Igor

I have a board with H3 Soc cortex a7 and gpu mali 400mp2 with SK hynix 2gb memory.

I try many armbian download distro but all give me 256mb only (240 effective because 16 is for fb).

If i recompile i can get all 2gb?

If so what is the correct param?

Thank

[Icenowy]

@blastiko I must tell you that 2Gbit = 256MByte.

 

Memory chips are usually identified with Gbit as unit, not GByte.

[blastiko]

Ahhh.... you're right Icenowy!
Badly written documentation misled me because it was written 2GB and no 2Gb
Thank you and sorry for my carelessness.

[valant]

@Igor, you know, I just installed the newest image (stretch) and it's the same! moreover, now even uboot reports 1GB.

[Igor]

4 hours ago, valant said:

@Igor, you know, I just installed the newest image (stretch) and it's the same! moreover, now even uboot reports 1GB.

Sorry, don't have any Pine64 around to check this.

[martinayotte]

I've 5.1.0 Stretch running on my Pine64, and it is actually reporting 2GB ...

[Igor]

13 hours ago, valant said:

now even uboot reports 1GB.

Which image exactly or if you can provide u-boot version?

[valant]

7 hours ago, Igor said:

Which image exactly or if you can provide u-boot version?

downloaded yesterday, armbian stretch 9 (mainline based kernel 4.19.y).

U-Boot 2019.04-armbian (May 03 2019 - 22:00:22 +0200) Allwinner Technology

[martinayotte]

20 hours ago, valant said:

now even uboot reports 1GB.

If you leave it booting, what the kernel is actually reporting using "free" ?

[valant]

25 minutes ago, martinayotte said:

If you leave it booting, what the kernel is actually reporting using "free" ?

val@pine:~$ free
              total        used        free      shared  buff/cache   available
Mem:        1017160       57956      850320        2956      108884      889600
Swap:        508576           0      508576

[martinayotte]

19 minutes ago, valant said:

Mem:        1017160

... maybe there is bad chance that one bank has bad soldering ...

Did you ever booted another kind of image, even Legacy, to see if it is always 1GB ?

[valant]

50 minutes ago, martinayotte said:

... maybe there is bad chance that one bank has bad soldering ...

Did you ever booted another kind of image, even Legacy, to see if it is always 1GB ?

I used an old legacy image until now (the screenshot on top of the page), there uboot reported 2GB but passed 1GB in the dtb. I'll try something else.

[valant]

3 hours ago, martinayotte said:

... maybe there is bad chance that one bank has bad soldering ...

Did you ever booted another kind of image, even Legacy, to see if it is always 1GB ?

well, I added writing into the second gigabyte in my loader and it showed this result:

• first, the code has been writing into every 8-byte word, starting at the 2nd gigabyte. and it failed at the 37th 8-byte word inside of the 129th page or passing ~512KB. I ran it twice and it failed at the same position. The fail is "synchronous abort" exception.
• second, the code has been changed to write first 8-byte word on every 4KB page starting from the 2nd gigabyte up to the last page (bffff000). I run this code twice and it passed it successfully both times. After the loop, the code read back the starting word and it matched.

So, I suppose, it's not that bad as a bad soldered bank. instead, there are some bad pages, maybe even just 1. Too bad uboot doesn't do any testing or at least doesn't report bad pages as for example UEFI does, passing this for an OS. Basically because of some broken bits, maybe not more than occupying just one page,  entire gigabyte is cut off... that sucks. 

Well, thanks @Igor and @martinayotte for your advices.

[Tido]

6 hours ago, valant said:

• first, the code has been writing into every 8-byte word, starting at the 2nd gigabyte. and it failed at the 37th 8-byte word inside of the 129th page or passing ~512KB. I ran it twice and it failed at the same position. The fail is "synchronous abort" exception.
• second, the code has been changed to write first 8-byte word on every 4KB page starting from the 2nd gigabyte up to the last page (bffff000). I run this code twice and it passed it successfully both times. After the loop, the code read back the starting word and it matched.

Almost every Linux Distro comes with this RAM-Checker memtest86+ (maybe just for X86?),  but you wrote your own test.
Would you write this down in an own Thread as a 'tutorial', sounds interesting.

 

[valant]

It's hard for an OS to do SDRAM test, at least because it resides there. The best way would be the firmware, while running in SRAM yet, right after SDRAM initialization, to do that, then recording info about bad pages and passing it to the OS through the memory map.

what I did was a quick hack (see the snippet below) - I inserted a simple loop inside the code, that runs after uboot, and ran it. It wouldn't be of a much usefulness overall, it just let understand loosely what amount of RAM is damaged in this particular case. The fact, it threw exception on the same address gives a hope, it's a very insignificant defect inside memory chip. But again, for proper handling such situations, memory testing functionality should be included inside firmware.

 

PutString("DEBUG: checking 8 bytes of every page beginning at the 2nd GB.\r\n");
p = (PUINT64)0x0080000000;
for(i = 0; i < 0x40000; i++){
    if(!(i % 0x50))PutString("\r\n");
    *(p + (i<<9)) = 0xb16b00b5cafebabe;
    PutString(".");
}
PutString("\r\nDEBUG: reading back: ");
PrintUintn(*p);
PutString("\r\n");