[uClinux-dev] booting linux-2.6.11 on a ucdimm (68VZ328)

Greg Ungerer gerg at snapgear.com
Tue Oct 4 23:25:56 EDT 2005


Hi Stuart,

I just found this sitting in my inbox, and I realized I hadn't
responded yet :-)


Stuart Hughes wrote:
> Okay,  I've got a bit further and now I'm booting up to:
> .....
> Kernel command line: console=ttyS0,115200
> call parse_early_param
> call parse_args
> call sort_main_extable
> call trap_init
> call rcu_init
> call init_IRQ
> call pidhash_init
> PID hash table entries: 64 (order: 6, 1024 bytes)
> call init_timers
> call softirq_init
> call time_init
> m68328_timer_init: enter
> call console_init
> Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
> Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
> <7>Mem_init: start=12a000, end=800000
> <6>Memory available: 6884k/8192k RAM, 0k/0k ROM (887k kernel code, 171k 
> data)
> 
> I've mostly changed arch/m68knommu/platform/68328/head-ram.S and made it 
> more like 5307/head.S
> 
> I've got a few questions:
> 
> 1/ I didn't see where to setup the stack pointer (from 307/head.S), in 
> the old 2.4 code, there was:
> 
> moveal  #__ramend-CONFIG_MEMORY_RESERVE*0x100000 - 0x10, %sp
> 
> Should I still have this ???

You may not need this anymore - it depends on the start code
after this.

For the ColdFire I used to set up a temporary stack early in
the kernel start code. Then the real process 0 stack was set
just before calling start_kernel() [the couple of instructions
just before the "jsr start_kernel" in 5307/head.S].
But there was no function calls or other stack usage in between,
so I did away with the early stack pointer setup.


> 2/ The ucdimm seems to want to reduce the 8 MB of memory to 6MB. Should 
> I do this ??

I dunno about this one. I don't have any experience using the ucdimm.


> 3/ I've put a return; early in init_hardware() to bypass the calls to 
> getserialnum() etc, which trap to the bootloader.  These are the ones 
> that call:
> 
> _bsc0(char *, getserialnum)
> _bsc1(unsigned char *, gethwaddr, int, a)
> _bsc1(char *, getbenv, char *, a)
> 
> 
> These macros would not compiler originally, so I "fixed" them, the 
> changes were (first one shown):
> 
> --- linux-2.6.10.modified/include/asm-m68knommu/bootstd.h   2004-12-24 
> 21:35:23.000000000 +0000
> +++ linux-2.6.10/include/asm-m68knommu/bootstd.h    2005-07-20 
> 11:43:51.000000000 +0100
> @@ -50,9 +50,8 @@
>  { \
>     register long __res __asm__ ("%d0") = __BN_##name; \
>     __asm__ __volatile__ ("trap #2" \
> -                         : "=g" (__res) \
> -                         : "0" (__res) \
> -                         : "%d0"); \
> +                         : "=r" (__res) \
> +                         : "0" (__res)); \
>     __bsc_return(type,__res); \
>  }
> 
> 
> Does this look right ???  I think I messed up.

Assuming register variables defined with __asm__ is problematic
with some version of gcc for the m68k. The compiler doesn't
guarantee that d0 (in this example) is neccessarily in place
when the actual asm code is called.

Look at the syscall code in include/asm-m68knommu/unistd.h
for a safer way to do this.

Regards
Greg




> Stuart Hughes wrote:
> 
>> Hi everyone,
>>
>> I've been working on getting the ucdimm port running on linux-2.6.
>>
>> I ran into a number of things that needed fixing in the source and now 
>> I'm at the point where I'm trying to boot, however this fails.  I've 
>> built with CONFIG_RAMKERNEL and after downloading the image to ram and 
>> typing goram I see: 'FRCF' before it hangs.
>>
>> I looked into this a little, and the first problem seems to be with: 
>> arch/m68knommu/platform/68VZ328/config.c:
>>    init_hardware(char *command, int size)
>>
>> The call to printk(KERN_INFO "uCdimm serial string [%s]\n", 
>> getserialnum()); causes a crash.  This does a 'trap 2' and it seems 
>> like my vectors may be messed up.
>>
>> If I comment this out, I get a lot further.  The boot continues up until
>> arch/m68knommu/mm/init.c: paging_init(void)
>>
>> Here are a couple more clues:
>>
>> * one of the fixups I did was in vmlinux.lds.S (changed line 39 to: 
>> #define ROMVEC_START    0x00020000)
>>
>> * I don't get any of the banner output (printk) even though there are 
>> loads of calls to this before the crash.
>>
>> * I have been able to put in debug calls to put a character to trace 
>> where I'm up to (using rs_put_char('X')), so I know the serial port 
>> isn't broken (I'm on RS232A - DCE).  Possibly my printk's are going to 
>> a different port ?? (If so how can I change this)
>>
>> Anyone got any ideas how I can track down the problem a bit further??
>>
>> Regards, Stuart
>>
>>
>>
>>
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>>
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com



More information about the uClinux-dev mailing list