DSM-G600, DNS-3xx and NSA-220 Hack Forum

Unfortunately no one can be told what fun_plug is - you have to see it for yourself.

You are not logged in.

Announcement

#1 2007-08-10 02:41:48

cwilson
Member
Registered: 2007-07-16
Posts: 19

building kernel for loader.o use

I noticed something funny when loader.o-ing a custom kernel that I built: half of my RAM went missing.

During the initial U-Boot:

Code:

U-Boot 0.2.0 (May 11 2005 - 18:56:16)
CPU:   MPC8245 V1.2 at 170.503 MHz:
Board: Sandpoint 8245
DRAM:  32 MB
...
Total memory 33554432 MB.
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Total memory is 33554432.
CPU = 82xx
...
/* note: now in fwimage-04-sala-20070128 console */
# free
              total         used         free       shared      buffers
  Mem:        30204        22592         7612            0         1848
 Swap:       530104            0       530104
Total:       560308        22592       537716

However, after logging on and doing the loader.o dance, I saw:

Code:

Using /mnt/HD_a2/loader.o loader module loaded
kernel=/mnt/HD_a2/vmlinux-sda3-csw1
cmdline=root=/dev/hda1
Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb
Total memory is 16777216.
CPU = 82xx
...
/* note: now in gentoo /dev/sda3 */
# free
             total       used       free     shared    buffers     cached
Mem:         14040      12776       1264          0       1268       5988
-/+ buffers/cache:       5520       8520
Swap:       530104        624     529480

It turns out the problem is in arch/ppc/platforms/sandpoint_setup.c (sandpoint_find_end_of_memory):

Code:

static unsigned long __init
sandpoint_find_end_of_memory(void)
{
        //unsigned long total_memory;
        bd_t *bp = (bd_t *)__res;

        if (bp->bi_memsize)
        {
        //REX:  
                printk("Total memory %d MB.\n", bp->bi_memsize);
                return bp->bi_memsize;
        }

        /* This might be fixed in DINK32 12.4, or we'll have another
         * way to determine the correct memory size anyhow. */
        /* return mpc10x_get_mem_size(MPC10X_MEM_MAP_B); */
        return 16*1024*1024;
}

During a "normal" boot, the clause labeled "//REX:" is executed, and 32MB is detected.  However, during loader.o boot, it looks like __res is not yet initialized, so the catchall "return 16MB" at the bottom is executed.  Two ways to fix this: just change the 16MB to 32MB, or uncomment the call to mpc10x_get_mem_size() -- which actually works during loader.o.  Patch is attached.  Should this be added to the kernel-build page somewhere?

Offline

 

#2 2007-08-10 09:53:28

sala
Member / Site Admin
From: Estonia
Registered: 2006-07-28
Posts: 731
Website

Re: building kernel for loader.o use

Nice work. For somehow I have missed this problem but most times I do boot my custom kernel from flash.
I did update loader.o wiki page.


DSM-G600 - NetBSD hdd-boot - 80GB Samsung SP0802N
NSA-220 - Gentoo armv5tel 20110121 hdd-boot - 2x 2TB WD WD20EADS

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2010 PunBB