I have a 1 GB Renegade board and downloaded Armbian_19.11.3_Renegade_buster_current_5.3.11 image to install.   Noticed it was only 510MB of RAM.

 

Relevant extracts from serial log:

 

U-Boot 2017.09-armbian (Nov 19 2019 - 00:09:05 +0100)

Model: Firefly ROC-RK3328-CC
DRAM:  510 MiB

 ____                                 _      
|  _ \ ___ _ __   ___  __ _  __ _  __| | ___ 
| |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \
|  _ <  __/ | | |  __/ (_| | (_| | (_| |  __/
|_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___|
                      |___/                  
Welcome to Armbian Buster with Linux 5.3.11-rockchip64

System load:   0.10 0.14 0.06  	Up time:       2 min		
Memory usage:  22 % of 472MB  	IP:            192.168.11.175
CPU temp:      44°C           	
Usage of /:    5% of 29G    	

[ General system configuration (beta): armbian-config ]

Last login: Sat Nov 23 22:48:50 2019

 

Using armbian-config I downgraded to kernel 4.4.198 and I now have 919MB of RAM.

 

U-Boot 2017.09-armbian (Nov 19 2019 - 00:01:47 +0100)

Model: Firefly ROC-RK3328-CC
DRAM:  1022 MiB

 ____                                 _      
|  _ \ ___ _ __   ___  __ _  __ _  __| | ___ 
| |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \
|  _ <  __/ | | |  __/ (_| | (_| | (_| |  __/
|_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___|
                      |___/                  
Welcome to Armbian Buster with Linux 4.4.198-rockchip64

System load:   0.10 0.09 0.03   Up time:       2 min
Memory usage:  8 % of 919MB     IP:            192.168.11.173
CPU temp:      43°C            
Usage of /:    5% of 29G    

[ General system configuration (beta): armbian-config ]

Ray

 

Board is not supported because there is nobody but you who will dig into the u-boot and provide a patch for this.

On 11/24/2019 at 7:12 AM, Raylynn Knight said:

I downgraded to kernel 4.4.198

Try replacing only u-boot with the old version (which shows 1 GB of RAM).

What I find confusing is that both instances of U-Boot report the same version and compile date.   Only a slight difference in compile time!  Is it actually two different versions of the source code, or different configurations?

 

Ray

4 hours ago, Raylynn Knight said:

both instances of U-Boot report the same version and compile date

U-boot is just one thing. You need to look lower than that:
https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc

There were some recent changes (master branch) which might have affect on this. You need to rebuild thing and try ...

On 11/26/2019 at 5:34 AM, Raylynn Knight said:

or different configurations?

Do you have the option to check the aembian (or LE) image for 3328 TV boxes ? I'm interested in two things. 1. General startup (u-boot and kernel operation). 2. And the ability to directly start the system from USB media (when using the new u-boot).

I just want to mention this happens regularly. I thought I'd found a version that doesn't do it but now I have no idea how to escape it. Maybe it's random. All I know is perhaps I should buy an RPi 4 to use as a NAS and have this just to play with. It's not supported at all by the guys that sell it, while all the non-Rockchip boards in the LibreComputer lineup have fine support. It's a shame

1 hour ago, jpegxguy said:

perhaps I should buy an RPi 4 to use as a NAS

 

If you want to jump on the bandwaggon of dumb hardware decisions (sharing USB and ethernet, etc.) and firmware level RTOS / bootloader / GPU blobs that really run the show (instead of your installed OS) then go right ahead.

 

Look I get the frustration. But there are lots of (much!) better boards than RPi to function as a NAS. If you really do want to join the masses and go buy an RPi then you can stop reading now. Otherwise, your options are:

• Do more research before purchasing, and make sure you get something that is stable and all the bugs are worked out. OR
• Buy whatever unknown hardware and then perhaps consider contributing in one way or another, in order to bring it up to full speed / support.

Personally, I am only low to mid level (at best) wizard, so I chose to do the former. I started with Cubietruck a few years ago, and it has run absolutely flawless as a NAS and running numerous services.

 

The situation with these SBC is a crap shoot. There are lots of holes you can step in (as you found out). But there are also hidden gems. Thus is the nature of the thing.

 

I for one am very happy that we have Armbian, otherwise we would have no (good) options whatsoever on all of this other hardware that are not RPi. So much in fact that I started supporting (financially (only a little)) and even helping out around here (Moderation most recently). But I am lucky to have the resources (time, money) to be able to do so (in other words I am not judging anyone who cannot, in today's difficult economy).

 

Just my $0.02. Anyway, rant over. I'm sorry but something about your comment I found dismissive to the efforts of all these people and Devs who have already put so much time, effort (and their own money) since years, just so regular people like us can Have Nice Things.

I gotta be honest with you, I do like the finicking! Plus I'm tight on money. So I'll play around with uboot and its commands any day. I just found out that USB Mass Storage emulation works fine for playing around with the emmc from a PC!

 

I never mentioned Armbian in my post. Armbian is very important and I'm thankful it exists. As far as I'm aware armbian is the only ready out-of-the-box experience for this board (the ones from Firefly are old and they crash a lot)

I'm using an Armbian U-Boot with Archlinux on this board for months now.

 

I was talking about Rockchip specifically. Armbian is a community distro

2 hours ago, jpegxguy said:

I never mentioned Armbian in my post. Armbian is very important and I'm thankful it exists. As far as I'm aware armbian is the only ready out-of-the-box experience for this board (the ones from Firefly are old and they crash a lot)

I'm using an Armbian U-Boot with Archlinux on this board for months now.

 

I was talking about Rockchip specifically. Armbian is a community distro

 

I may or may have not realized that at the time. In either case, my thoughts on Armbian were the logical continuation of my thought process...

 

Also, some people do not even realize that the alternatives to Armbian are usually much worse... But now I see that is clearly not the case here.

 

Cheers!

Edited February 11, 20206 yr by TRS-80
spacing

Hi all,

Sorry to revive an old forum post but this is directly related to the issue described here. I have a librecomputer rk3328-roc-cc board with 1GB of Ram which was only should about half the RAM. I spent way too much time in u-boot and arm trusted firmware land but I was able to go back to the old Firefly git repo for u-boot and do some source analysis to come up with a patch which will correct the RAM issue in u-boot.

 

I'm a new Armbian user, as I was struggling getting the new 5.4 main line Kernel working on my board when I upgraded from Debian Stretch. Armbian has an amazing build script and process and so far I've really enjoyed using it. The LED lights actually doing things on this board completely sold me. However this half ram issue was the only thing keeping me from upgrading u-boot and going more main line Armbian.

 

I wouldn't call myself a C programmer at all but from my limited understanding it looks like this adds an additional variable for doing math to size the SDRAM for u-boot to initialize.

 

Does anyone here have a contact with ayufan from the git repo (https://github.com/ayufan-rock64/linux-u-boot) so we can get this merged upstream?

 

Also, what else needs to be done to get this board in the supported column? I'm happy to help out and contribute in anyway possible. I run two of these boards at my day job so I can even spend a limited amount of paid time if it allows us to keep them updated and running.

 

==START userpatches/u-boot/u-boot-rockchip64-dev/sdram_common.patch==

 

---

index 76dbdc8..5233e7f 100644
--- a/arch/arm/mach-rockchip/sdram_common.c
+++ b/arch/arm/mach-rockchip/sdram_common.c
@@ -14,7 +14,7 @@
 DECLARE_GLOBAL_DATA_PTR;
 size_t rockchip_sdram_size(phys_addr_t reg)
 {
-    u32 rank, col, bk, cs0_row, cs1_row, bw, row_3_4;
+    u32 rank, col, bk, cs0_row, cs1_row, bw, row_3_4, dbw, bg;
     size_t chipsize_mb = 0;
     size_t size_mb = 0;
     u32 ch;
@@ -37,16 +37,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
             SYS_REG_BW_MASK));
         row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
             SYS_REG_ROW_3_4_MASK;
+         dbw = sys_reg >> SYS_REG_DBW_SHIFT(ch) & SYS_REG_DBW_MASK;
+         /* only used by DDR4 */
+         bg = (dbw == 1) ? 1 : 2;
 
-        chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
+        chipsize_mb = (1 << (cs0_row + col + bg + bk + bw - 20));
 
         if (rank > 1)
             chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
         if (row_3_4)
             chipsize_mb = chipsize_mb * 3 / 4;
         size_mb += chipsize_mb;
-        debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
-              rank, col, bk, cs0_row, bw, row_3_4);
+        debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d dbw %d\n",
+              rank, col, bk, cs0_row, bw, row_3_4, dbw);
     }
 
     return (size_t)size_mb << 20;

 

==END userpatches/u-boot/u-boot-rockchip64-dev/sdram_common.patch===

 

Thanks

 

Gymnodemi

 

6 hours ago, gymnodemi said:

Armbian has an amazing build script and process and so far I've really enjoyed using it. The LED lights actually doing things on this board completely sold me. However this half ram issue was the only thing keeping me from upgrading u-boot and going more main line Armbian.

 

Thank you! If your solution works, add it here https://github.com/armbian/build/tree/master/patch/u-boot with https://docs.armbian.com/Process_Contribute/ Patches might need some time before they are accepted upstream, some never are, which is why we have this patch section.

 

6 hours ago, gymnodemi said:

Does anyone here have a contact with ayufan from the git repo (https://github.com/ayufan-rock64/linux-u-boot) so we can get this merged upstream?

You can try to call him this way:

@ayufan ... but best is to prepare a merge request directly for mainstream u-boot https://www.denx.de/wiki/U-Boot/Patches