Jump to content

gymnodemi

Members
  • Posts

    2
  • Joined

  • Last visited

  1. Hi everyone, Interestingly enough I had one board have this problem while a fresh new install on another identical board that has been around much longer did not have the issue. At first deleted the armbian repo lz4 files first and ran apt update. That didn't seem to solve the issue. I was able to find that the culprit was this file: /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4 The freshly installed board board did not have the compressed version. I deleted that file and ran apt update and it was recreated as a lz4 file (and took a good while running cnf-update-db). I ended up simply unlz4'ing the file and now my full text searches are back to normal speed. I re-ran apt update and it didn't pull down a compressed version. Since these are the debian based packages I thought it had to do with the compress index but the two boards had identical /etc/apt/apt.conf.d/ entries. The only difference was updates that happened in between when I ran the build script - so I'm wondering if once you have a lz4 version apt continues getting that version instead of the uncompressed one. If the symptoms come back I will update this thread.
  2. 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
×
×
  • Create New...