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

Stuart Hughes stuarth at freescale.com
Wed Oct 5 03:45:45 EDT 2005


Hi Greg,

Thanks for the reply, that helps me understand what's going on better.

Since that post I've managed to get the ucdimm to boot up to the point 
where it's trying to mount the rootfs.  I then ran into the problem that 
the cs89x0 didn't keep it's patches for the ucdimm in 2.6.x.  At that 
point I got sent the real board I'm working on and haven't done much 
more on the ucdimm (although I intend to go back and clean up when time 
permits).  Before stopping I managed to get this far:

* I forward ported to 2.6.13-uc0

* builds against gcc-3.4.3

* I ended up with boot code in  68328/head-ram.S that was the same as 
5307/head.S except for a couple of minor #ifdefs

If I ever get back to it, who would be the right person to send the 
patches to ?

Has anyone else got patches for linux-2.6.x to get the cs89x0 ethernet 
device running on the ucdimm (68VZ328) ?

Regards, Stuart

Greg Ungerer wrote:
> 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
>>
> 




More information about the uClinux-dev mailing list