Suddenly only 1/4 the RAM [1GB model shipped as 4GB]

ejolson · (This post was last modified: 01-12-2021, 01:08 AM by ejolson.)

Edit: It turns out a 1GB model was shipped in the box labeled as 4GB, so that's why only 1/4 the memory was being detected, see the posts later in this thread. I think it's too late for a replacement, but if anyone knows how to arrange this, I'd very much appreciate it.

I set up two identically configured Rock64 boards last month. The first experienced segmentation faults while compiling with gcc as described in the thread

https://forum.pine64.org/showthread.php?tid=11209

This was solved by slowing the memory clock from 786 MHz to 400 MHz. The second worked well for a little under a month but is now booting with only 1GB out of the expected 4GB detected.

I swapped cards between the two machines. The problem did not move with the cards but remained with the second Rock64 hardware. I also reformatted two other SD cards and tried both the current and legacy builds of Armbian Debian server. Note that I was running Armbian Focal Fossa before. The newly formatted cards booted right up, but the memory remains at 1GB rather than 4GB.

Is it possible there was a defective solder join on the system? Could the RAM itself have developed a fault? Since the circuit boards have been safely mounted on standoffs away from any dangers for the entire time, I am surprised with my bad luck: One didn't run reliably at the default clock speeds and the other just started to report only 1/4 of the expected RAM.

As already mentioned, lowering the clock speed on the first machine has stabilized it and I'm happy. Does anyone know what to do to get my 4GB RAM back on the other? Having only 1GB is unfit for purpose.

ejolson · (This post was last modified: 09-15-2020, 07:36 PM by ejolson.)

Since the system had a Sandisk SSD plugged into the USB3 socket I decided to remove that to see if that helped. Unfortunately, the system still boots up with only 1GB out of 4GB RAM detected. The early dmesg boot lines of the second system which is missing 3GB of RAM look like

Code:
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

[    0.000000] Linux version 5.8.6-rockchip64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 20:23:22 CEST 2020

[    0.000000] Machine model: Pine64 Rock64

[    0.000000] efi: UEFI not found.

[    0.000000] cma: Reserved 128 MiB at 0x0000000034c00000

[    0.000000] NUMA: No NUMA configuration found

[    0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x000000003fffffff]

[    0.000000] NUMA: NODE_DATA [mem 0x3fdc3100-0x3fdc4fff]

[    0.000000] Zone ranges:

[    0.000000]   DMA      [mem 0x0000000000200000-0x000000003fffffff]

[    0.000000]   DMA32    empty

[    0.000000]   Normal   empty

[    0.000000] Movable zone start for each node

[    0.000000] Early memory node ranges

[    0.000000]   node   0: [mem 0x0000000000200000-0x000000003fffffff]

[    0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x000000003fffffff]

[    0.000000] On node 0 totalpages: 261632

[    0.000000]   DMA zone: 4088 pages used for memmap

[    0.000000]   DMA zone: 0 pages reserved

[    0.000000]   DMA zone: 261632 pages, LIFO batch:63

[    0.000000] psci: probing for conduit method from DT.

[    0.000000] psci: PSCIv1.0 detected in firmware.

[    0.000000] psci: Using standard PSCI v0.2 function IDs

[    0.000000] psci: MIGRATE_INFO_TYPE not supported.

[    0.000000] psci: SMC Calling Convention v1.0

[    0.000000] percpu: Embedded 32 pages/cpu s93528 r8192 d29352 u131072

[    0.000000] pcpu-alloc: s93528 r8192 d29352 u131072 alloc=32*4096

[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 

[    0.000000] Detected VIPT I-cache on CPU0

[    0.000000] CPU features: detected: ARM erratum 845719

[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 257544

[    0.000000] Policy zone: DMA

while the dmesg output of the first system that detects all 4GB RAM reports

Code:
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

[    0.000000] Linux version 5.7.15-rockchip64 (root@desktop) (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)), GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08 SMP PREEMPT Mon Aug 17 00:26:28 CEST 2020

[    0.000000] Machine model: Pine64 Rock64

[    0.000000] efi: UEFI not found.

[    0.000000] cma: Reserved 128 MiB at 0x00000000f3c00000

[    0.000000] NUMA: No NUMA configuration found

[    0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x00000000feffffff]

[    0.000000] NUMA: NODE_DATA [mem 0xfe7c8100-0xfe7c9fff]

[    0.000000] Zone ranges:

[    0.000000]   DMA      [mem 0x0000000000200000-0x000000003fffffff]

[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000feffffff]

[    0.000000]   Normal   empty

[    0.000000] Movable zone start for each node

[    0.000000] Early memory node ranges

[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000feffffff]

[    0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x00000000feffffff]

[    0.000000] On node 0 totalpages: 1043968

[    0.000000]   DMA zone: 4088 pages used for memmap

[    0.000000]   DMA zone: 0 pages reserved

[    0.000000]   DMA zone: 261632 pages, LIFO batch:63

[    0.000000]   DMA32 zone: 12224 pages used for memmap

[    0.000000]   DMA32 zone: 782336 pages, LIFO batch:63

[    0.000000] psci: probing for conduit method from DT.

[    0.000000] psci: PSCIv1.0 detected in firmware.

[    0.000000] psci: Using standard PSCI v0.2 function IDs

[    0.000000] psci: MIGRATE_INFO_TYPE not supported.

[    0.000000] psci: SMC Calling Convention v1.0

[    0.000000] percpu: Embedded 32 pages/cpu s92568 r8192 d30312 u131072

[    0.000000] pcpu-alloc: s92568 r8192 d30312 u131072 alloc=32*4096

[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 

[    0.000000] Detected VIPT I-cache on CPU0

[    0.000000] CPU features: detected: ARM erratum 845719

[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1027656

[    0.000000] Policy zone: DMA32

The first difference between the two machines is the cma memory address. What's that? Also, is the lack of DMA32 zones the result of less memory being detected or the cause? Is there a way to test memory using the uboot environment to see what's wrong?

Is there any firmware on the board that needs to be reset?

ejolson · (This post was last modified: 09-17-2020, 09:51 PM by ejolson.)

(09-15-2020, 07:27 PM)ejolson Wrote: Is there any firmware on the board that needs to be reset?

As nobody responded, my assumption is that nobody knows of any firmware on the Rock64 that might cause 4GB of RAM to not be detected properly. Although the Rock64 is noticeably slower than the Raspberry Pi, having hardware AES could be a significant advantage when securing things with TLS, IPSec and dmcrypt. Since the Rock64 is listed as having long-term supply until 2022, now is mid-life in the product cycle. At the same time, the boards I recently received appear not to meet the quality standards necessary for long-term use.

I'm wondering whether I was just exceedingly unlucky. Has anyone else had a Rock64 that experienced memory problems or suddenly started booting with less memory than physically present? How likely will the same thing happen again if I buy a replacement?

lot378 · (This post was last modified: 09-17-2020, 10:15 PM by lot378.)

Do you have a serial console interface available, in order to see what is said about memory?

Should see something like the top of this thread: https://forum.pine64.org/showthread.php?tid=5877

I also wonder if it was something to do with the content in the SPI but is there a u-boot installed in there? By default I don't think there is anything.

ejolson · (This post was last modified: 09-25-2020, 07:55 PM by ejolson.)

(09-17-2020, 10:14 PM)lot378 Wrote: Do you have a serial console interface available, in order to see what is said about memory?

Should see something like the top of this thread: https://forum.pine64.org/showthread.php?tid=5877

I also wonder if it was something to do with the content in the SPI but is there a u-boot installed in there? By default I don't think there is anything.

Thanks for the reply. Sorry for the late response. I haven't intentionally placed anything in the onboard memory. Is it possible that Armbian might do that as part of the default install?

I've don't have a serial console connected up. Is it possible for one Rock64 to serve as a serial console for the other? If so, do you know if there an explanation how to do this somewhere around here?

lot378 · (This post was last modified: 09-25-2020, 11:06 PM by lot378.)

(09-25-2020, 07:54 PM)ejolson Wrote: I've don't have a serial console connected up. Is it possible for one Rock64 to serve as a serial console for the other? If so, do you know if there an explanation how to do this somewhere around here?

Yes, you could use one Rock64 to read the serial console on the other.

There's a guide here: https://forum.pine64.org/showthread.php?tid=5029

Woodpecker UART (set to 3.3v): https://pine64.com/product/serial-consol...r-edition/

It's also possible to pickup a UART device anywhere.

Reading the serial console during boot to see how much memory the system has is the first part of restoring sanity. Does the system really only have 1GB? or 4GB? We know it's 4GB but the sanity test is exactly that - to stop us going insane. When it reports 4GB then we look at what could be changing it to 1GB. Other ways to check are comparing the numbers on the RAM chips.

ejolson · 01-11-2021, 08:29 PM

(09-25-2020, 10:56 PM)lot378 Wrote: Reading the serial console during boot to see how much memory the system has is the first part of restoring sanity. Does the system really only have 1GB? or 4GB? We know it's 4GB but the sanity test is exactly that - to stop us going insane. When it reports 4GB then we look at what could be changing it to 1GB. Other ways to check are comparing the numbers on the RAM chips.

I finally got around to checking the numbers on the RAM chips. It seems to have PB047-125PT on it just like described in the post

https://forum.pine64.org/showthread.php?tid=9377

for the 1GB model, so I guess the same thing happened to me. I was shipped a 1GB model marked as a 4GB model on the box. Needless to say, I'm not very happy about this as I wasted quite a bit of effort checking the software before checking the chip. As the other board is definitely 4GB, I must have become confused about whether this board ever showed 1GB available.

My suspicion is that right now is also long past the return by date. These boards were ordered directly from the manufacturer and arrived by China post at the beginning of the epidemic. Does anyone know is it possible to obtain a replacement? As this same problem has happened to at least one other person, if I want to buy a replacement, how do I guarantee the same thing won't happen again?

Login




Remember me Lost Password?

About Us