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

Greg Ungerer gerg at snapgear.com
Wed Oct 5 08:40:38 EDT 2005


Hi Stuart,

Stuart Hughes wrote:
> 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

That is good. I would very much like to have a single head.S
for all m68knommu (or at lost most of them) one day. That may
still be some way off :-)


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

Yep, send them to me.

Regards
Greg



> 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
>>>
>>
> 
> _______________________________________________
> 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