Frequent segfaults etc. while compiling
#8
Temperature of 54C is ok. 45C even more.

I just realize that you see virtual addresses which change for the same physical address from one run of memtester to the next.

So, block the first 1GB of physical memory, boot and run memtest. Repeat for the second 1GB, third 1GB and fourth 1GB. Once you found the offending 1GB block, refine this search. Note: things are not as easy as they sound: the kernel can't block its own memory, e.g. where it was loaded by uboot.

What is probably much better is kernel option CONFIG_MEMTEST. Here is a experience report https://raid6.com.au/~onlyjob/posts/MEMTEST_explained/


About under-clocking. The good news: it should be possible. The bad news: nobody did it before. Here is a related thread about over-clocking https://forum.pine64.org/showthread.php?tid=10398

I have not really looked into it. Here are some starting points for you:

#1 uboot drivers/clk/rockchip/clk_rk3399.c

Code:
static ulong rk3399_ddr_set_clk(struct rk3399_cru *cru,
                ulong set_rate)
{
    struct pll_div dpll_cfg;

    /*  IC ECO bug, need to set this register */
    writel(0xc000c000, PMUSGRF_DDR_RGN_CON16);

    /*  clk_ddrc == DPLL = 24MHz / refdiv * fbdiv / postdiv1 / postdiv2 */
    switch (set_rate) {
    case 50 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 1, .fbdiv = 12, .postdiv1 = 3, .postdiv2 = 2};
        break;
    case 200 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 1, .fbdiv = 50, .postdiv1 = 6, .postdiv2 = 1};
        break;
    case 300 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 2, .fbdiv = 100, .postdiv1 = 4, .postdiv2 = 1};
        break;
    case 400 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 1, .fbdiv = 50, .postdiv1 = 3, .postdiv2 = 1};
        break;
    case 666 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 2, .fbdiv = 111, .postdiv1 = 2, .postdiv2 = 1};
        break;
    case 800 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 1, .fbdiv = 100, .postdiv1 = 3, .postdiv2 = 1};
        break;
    case 933 * MHz:
        dpll_cfg = (struct pll_div)
        {.refdiv = 1, .fbdiv = 116, .postdiv1 = 3, .postdiv2 = 1};
        break;
    default:
        pr_err("Unsupported SDRAM frequency!,%ld\n", set_rate);
    }
    rkclk_set_pll(&cru->dpll_con[0], &dpll_cfg);

    return set_rate;
}


#2 the kernel device tree has an attribute for the memory speed

Code:
cru: clock-controller@ff760000 {
...
                        <&cru PLL_CPLL>,
...
                        <800000000>,


Maybe, I just say maybe, the kernel is reinitializing the memory speed back to 800000000Hz and you need to make modifications in the device tree?


I hope I confused you Tongue. Keep us up to date with your experiments.


Messages In This Thread
RE: Frequent segfaults etc. while compiling - by Der Geist der Maschine - 06-27-2020, 11:18 AM

Possibly Related Threads…
Thread Author Replies Views Last Post
Smile Easy cross-compiling elijahr 4 5,794 09-25-2020, 12:27 PM
Last Post: Paulie420
  compiling (large) programs on pbp pine76 8 7,426 09-25-2020, 10:24 AM
Last Post: e-minguez
  Compiling WireGuard (and other things requiring linux-headers) on Debian+Mate Dendrocalamus64 1 3,608 04-02-2020, 07:07 PM
Last Post: Dendrocalamus64

Forum Jump:


Users browsing this thread: 1 Guest(s)