Discussion:
uClinux 2.4.x - 68328
(too old to reply)
Waligora
2003-05-24 15:04:23 UTC
Permalink
Hello,

Does anybody successfully run kernel 2.4.x (latest copy from CVS) with 68EZ328, or any other 68000 processor?

I have found one more bug in 68328/entry.S file
actual:
do_trace:
....
/* jbsr @(SYMBOL_NAME(sys_call_table),%d1:l:4)@(0) */
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
jbsr %a0@(%d1)
#else

should be:
do_trace:
....
/* jbsr @(SYMBOL_NAME(sys_call_table),%d1:l:4)@(0) */
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
movel %a0@(%d1), %a0
jbsr %a0@
#else

Anyway, my system still have problems when tries to create a first INIT kernel_thread. I use 68000 processor with
timer (10 ms tick, jiffies=76), uart 115200. It is quite similar to 68328 platform.
Short screen log is below:
-------------------------
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x020000-0x0abf00 DATA=0x0abf00-0x0c4064 BSS=0x0c4064-0x0d53ac
KERNEL -> ROMFS=0x0d53ac-0x125c9c MEM=0x126000-0x400000 STACK=0x400000-0x400000
Command line: 'root=/dev/ram0 console=/dev/ttyS0'
bdata->
node_bootmem_map=1204224
node_boostart=0
node_low_pfn=1024
start_mem is 0x126000
virtual_end is 0x400000
On node 0 totalpages: 1024
zone(0): 0 pages.
zone(1): 1024 pages.
zone(2): 0 pages.
Done setup_arch
Kernel command line: root=/dev/ram0 console=/dev/ttyS0
Calibrating delay loop... 1.40 BogoMIPS
Mem_init: start=126000, end=400000
Memory available: 2860k/4096k RAM, 0k/0k ROM (559k kernel code, 165k data)
Dentry cache hash table entries: 512 (order: 0, 4096 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 1024 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
^^^^^^^^^^^^^^^^^^^^^^^^^^
after this print system crashes
-------------------------
Below is some trace-back from my system (I'm not uCLinux expert :), so
apologize for any obvious stuff)

I did some tracing and found that switching from IDLE task to NEW TASK
returns to 0x00000 address. I think that NEW TASK should be INIT process in this case.

The following steps are executed prior crash (after "POSIX conformance testing by UNIFIX" printf).

rest_init()
...
kernel_thread(init,NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNALS)
...
do_fork()
...
wake_up_process()
[fork.c(~890)] wait_for_completion(&vfork)

... this goes to
schedue();
...
[sched.c(~600)] del_from_runqueue(prev)
[sched.c(~686)] prepare_to_switch()
[sched.c(~719)] switch_to(prev,next,prev)
[entry.S(~319)] resume
[entry.S(~100)] ret_from_fork
[sched.c(~530)] schedule_tail
[entry.S(~163)] ret_from_exception goes to 0x00000

Please let me know if data flow above is correct. What could be the most possible reason of such behavior?
Thanks in advance for any hints/suggestions.

Waligora.
Kunlun Zhu
2003-05-25 07:43:07 UTC
Permalink
Hi, all:

When I selected to use rom kernel, I got the error for missing the
crt0_rom.S. Could someone help me where to get the crt0_rom.S file if it
is not included in the uClinux-dist-20030522?

Thanks,

Kevin zhu
Greg Ungerer
2003-05-25 12:50:27 UTC
Permalink
Hi Kevin,
Post by Kunlun Zhu
When I selected to use rom kernel, I got the error for missing the
crt0_rom.S. Could someone help me where to get the crt0_rom.S file if it
is not included in the uClinux-dist-20030522?
There isn't one. No-one has done support for running a 5272
based board direct from ROM/flash. (It is not hard to do
mind you).

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
Bernhard Kuhn
2003-05-25 20:39:48 UTC
Permalink
Post by Greg Ungerer
Post by Kunlun Zhu
Could someone help me where to get the crt0_rom.S file if it
is not included in the uClinux-dist-20030522?
There isn't one. No-one has done support for running a 5272
based board direct from ROM/flash.
This is not fully true :-)

http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20011119/kernel/patches/uClinux-2.4.x-M5272C3-bootfromrom.patch

However, the patch is for an older 2.4.x kernel, so it may not apply
OOTB for the current distro ...

Bernhard
Greg Ungerer
2003-05-25 23:27:15 UTC
Permalink
Hi Bernhard,
Post by Bernhard Kuhn
Post by Greg Ungerer
Post by Kunlun Zhu
Could someone help me where to get the crt0_rom.S file if it
is not included in the uClinux-dist-20030522?
There isn't one. No-one has done support for running a 5272
based board direct from ROM/flash.
This is not fully true :-)
http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20011119/kernel/patches/uClinux-2.4.x-M5272C3-bootfromrom.patch
However, the patch is for an older 2.4.x kernel, so it may not apply
OOTB for the current distro ...
Indeed. I guess I should have said "no-one has sent the
CVS maintainers a patch for inclusion" :-)

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
Sivam
2003-05-26 04:04:12 UTC
Permalink
Hello All,

I am using a external DUART chip TL16C752B on my M5249 board ?. Is there
any driver available in uClinux for this ?. Pls do advice me on this.

Thanks and Regards
sivam
Richard Klingler
2003-05-26 07:46:46 UTC
Permalink
Post by Sivam
Hello All,
I am using a external DUART chip TL16C752B on my M5249 board ?. Is there
any driver available in uClinux for this ?. Pls do advice me on this.
Take the regular serial.c driver and adjust it as also asm/serial.h
Although FIFO support doesn't work with 16c752...but if you need it
for console that's okay (o;


rick
David McCullough
2003-05-25 11:05:38 UTC
Permalink
Jivin Waligora lays it down ...
Post by Waligora
Hello,
Does anybody successfully run kernel 2.4.x (latest copy from CVS) with
68EZ328, or any other 68000 processor?
We alway run it under Xcopilot (68328) which I just built and tested.
I am fairly sure Phil Wilshire has run it on the Arcturus boards recently.
Either way there are a lot of 68k platforms out there :-)
Post by Waligora
I have found one more bug in 68328/entry.S file
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
entry.S hasn't changed for some time, and I know it has been run on
many 68328/68EZ328 and 68VZ328 platforms. Why is the above code giving
you problems ?


Which tools are you using ?
Post by Waligora
Anyway, my system still have problems when tries to create a first INIT kernel_thread. I use 68000 processor with
timer (10 ms tick, jiffies=76), uart 115200. It is quite similar to 68328 platform.
-------------------------
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Again, all this has been working fine on other platforms.
I notice below you have specified root=/dev/ram0, yet you also appear
to have a valid ROMFS at the end of the kernel. Is this intended ?

I have no great ideas for you. I would say, start by looking at what
you may be doing differently to other platforms. Especially in the
memory setup, bootmem, filesystems areas.

All the 68328 variants use the m68k-elf-tools with the -m68000 compile
option to generate the correct code.

Cheers,
Davidm
Post by Waligora
KERNEL -> TEXT=0x020000-0x0abf00 DATA=0x0abf00-0x0c4064 BSS=0x0c4064-0x0d53ac
KERNEL -> ROMFS=0x0d53ac-0x125c9c MEM=0x126000-0x400000 STACK=0x400000-0x400000
Command line: 'root=/dev/ram0 console=/dev/ttyS0'
bdata->
node_bootmem_map=1204224
node_boostart=0
node_low_pfn=1024
start_mem is 0x126000
virtual_end is 0x400000
On node 0 totalpages: 1024
zone(0): 0 pages.
zone(1): 1024 pages.
zone(2): 0 pages.
Done setup_arch
Kernel command line: root=/dev/ram0 console=/dev/ttyS0
Calibrating delay loop... 1.40 BogoMIPS
Mem_init: start=126000, end=400000
Memory available: 2860k/4096k RAM, 0k/0k ROM (559k kernel code, 165k data)
Dentry cache hash table entries: 512 (order: 0, 4096 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 1024 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
^^^^^^^^^^^^^^^^^^^^^^^^^^
after this print system crashes
-------------------------
Below is some trace-back from my system (I'm not uCLinux expert :), so
apologize for any obvious stuff)
I did some tracing and found that switching from IDLE task to NEW TASK
returns to 0x00000 address. I think that NEW TASK should be INIT process in this case.
The following steps are executed prior crash (after "POSIX conformance testing by UNIFIX" printf).
rest_init()
...
kernel_thread(init,NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNALS)
...
do_fork()
...
wake_up_process()
[fork.c(~890)] wait_for_completion(&vfork)
... this goes to
schedue();
...
[sched.c(~600)] del_from_runqueue(prev)
[sched.c(~686)] prepare_to_switch()
[sched.c(~719)] switch_to(prev,next,prev)
[entry.S(~319)] resume
[entry.S(~100)] ret_from_fork
[sched.c(~530)] schedule_tail
[entry.S(~163)] ret_from_exception goes to 0x00000
Please let me know if data flow above is correct. What could be the most possible reason of such behavior?
Thanks in advance for any hints/suggestions.
Waligora.
--
David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com
davidm at snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + Security
David McCullough
2003-05-26 12:25:07 UTC
Permalink
Jivin David McCullough lays it down ...
...
Post by Waligora
I have found one more bug in 68328/entry.S file
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
Ok, applied this fix. I read it too quickly the first time and assumed
it was part of the standard syscall, but it should only be invoked
if you are tracing syscalls.

This is why we haven't seen the problem, not many people trace syscalls
on these platforms.

If this code is getting executed then there is something wrong with your
setup. A few things you might want to check:

* BSS is zeroed in your kernel crt0.S

* that the init_task is aligned correctly (8K alignment) and the
correct size (8K) and that the stack pointer/current task is also
set properly in crt0.S

* that your RAM is working properly ;-) ;-)

You might want to try and trace where this trace bit is getting set,
should point to part of the problem,

Cheers,
Davidm
--
David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com
davidm at snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + Security
richard
2003-05-25 14:04:06 UTC
Permalink
Post by Kunlun Zhu
When I selected to use rom kernel, I got the error for missing the
crt0_rom.S. Could someone help me where to get the crt0_rom.S file if it
is not included in the uClinux-dist-20030522?
You can start from another 5272 architecture and modify
crt0_rom.S and ld file according to your board...


rick
HenrySimmons17
2003-05-25 22:53:35 UTC
Permalink
Hello Waligora,
Is your STACK size correct? STACK=0x400000-0x400000
Something is causing the STACK size to be define incorectly
Henry

From: "Waligora" <waligora33 at poczta.fm>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, May 24, 2003 8:04 AM
Subject: [uClinux-dev] uClinux 2.4.x - 68328
Post by Waligora
Anyway, my system still have problems when tries to create a first INIT
kernel_thread. I use 68000 processor with
Post by Waligora
timer (10 ms tick, jiffies=76), uart 115200. It is quite similar to 68328 platform.
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x020000-0x0abf00 DATA=0x0abf00-0x0c4064
BSS=0x0c4064-0x0d53ac
Post by Waligora
KERNEL -> ROMFS=0x0d53ac-0x125c9c MEM=0x126000-0x400000
STACK=0x400000-0x400000
Waligora
2003-05-26 06:22:24 UTC
Permalink
Post by HenrySimmons17
Hello Waligora,
Is your STACK size correct? STACK=0x400000-0x400000
Something is causing the STACK size to be define incorectly
Henry
It doesn't mater, because stack pointer is at the end of available space. In fact it is always set in init section, to value &init_task_union+0x2000. It is 0xAE000 in my case. The new TASK (init) has 0x17C000 base. Thanks for your hint.
Post by HenrySimmons17
From: "Waligora" <waligora33 at poczta.fm>
To: <uclinux-dev at uclinux.org>
Sent: Saturday, May 24, 2003 8:04 AM
Subject: [uClinux-dev] uClinux 2.4.x - 68328
Post by Waligora
Anyway, my system still have problems when tries to create a first INIT
kernel_thread. I use 68000 processor with
Post by Waligora
timer (10 ms tick, jiffies=76), uart 115200. It is quite similar to
68328
platform.
Post by Waligora
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x020000-0x0abf00 DATA=0x0abf00-0x0c4064
BSS=0x0c4064-0x0d53ac
Post by Waligora
KERNEL -> ROMFS=0x0d53ac-0x125c9c MEM=0x126000-0x400000
STACK=0x400000-0x400000
Waligora
2003-05-26 06:39:29 UTC
Permalink
Post by David McCullough
Jivin Waligora lays it down ...
Post by Waligora
Hello,
Does anybody successfully run kernel 2.4.x (latest copy from CVS) with
68EZ328, or any other 68000 processor?
We alway run it under Xcopilot (68328) which I just built and tested.
I am fairly sure Phil Wilshire has run it on the Arcturus boards
recently.
Either way there are a lot of 68k platforms out there :-)
Post by Waligora
I have found one more bug in 68328/entry.S file
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
....
lsl #2,%d1
#if 1
lea SYMBOL_NAME(sys_call_table), %a0
#else
entry.S hasn't changed for some time, and I know it has been run on
many 68328/68EZ328 and 68VZ328 platforms. Why is the above code giving
you problems ?
This opcode doesn't have a sense jbsr %a0@(%d1). It jumps to sys_call_table +offset and starts execution of code in this table. It should fetch pointer of new instruction pointed out by (a0+d1) and load to PC this value.
This bug was in sys_call procedure somewhere in previous releases of 2.4.x
Post by David McCullough
Which tools are you using ?
(gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/))
Post by David McCullough
Post by Waligora
Anyway, my system still have problems when tries to create a first INIT
kernel_thread. I use 68000 processor with
Post by Waligora
timer (10 ms tick, jiffies=76), uart 115200. It is quite similar to
68328 platform.
Post by Waligora
-------------------------
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Again, all this has been working fine on other platforms.
I notice below you have specified root=/dev/ram0, yet you also appear
to have a valid ROMFS at the end of the kernel. Is this intended ?
My FS is appended by CAT method, then copied above BSS in crt0_ram.S code.
To be honest I'm not sure if kernel root='dev/*' should be rom0 or ram0.
I tried both options and it didn't help. I have not any FLASH, ROM, etc.
devices. My code is always loaded through RS-232 to my on board SDRAM.

One more question: does
kernel_thread(init,NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNALS);
;// next line of C code
returns to next line of C code? Or generally kernel_thread() could return somewhere else?

Thanks,
Waligora.
Post by David McCullough
I have no great ideas for you. I would say, start by looking at what
you may be doing differently to other platforms. Especially in the
memory setup, bootmem, filesystems areas.
I did it, but I have not found any hints. Everything is looking similary
in my code, but I'm sure that somewhere inside is a bug (at least one ;-)).
Post by David McCullough
All the 68328 variants use the m68k-elf-tools with the -m68000 compile
option to generate the correct code.
Cheers,
Davidm
Post by Waligora
KERNEL -> TEXT=0x020000-0x0abf00 DATA=0x0abf00-0x0c4064
BSS=0x0c4064-0x0d53ac
Post by Waligora
KERNEL -> ROMFS=0x0d53ac-0x125c9c MEM=0x126000-0x400000
STACK=0x400000-0x400000
Post by Waligora
Command line: 'root=/dev/ram0 console=/dev/ttyS0'
bdata->
node_bootmem_map=1204224
node_boostart=0
node_low_pfn=1024
start_mem is 0x126000
virtual_end is 0x400000
On node 0 totalpages: 1024
zone(0): 0 pages.
zone(1): 1024 pages.
zone(2): 0 pages.
Done setup_arch
Kernel command line: root=/dev/ram0 console=/dev/ttyS0
Calibrating delay loop... 1.40 BogoMIPS
Mem_init: start=126000, end=400000
Memory available: 2860k/4096k RAM, 0k/0k ROM (559k kernel code, 165k
data)
Post by Waligora
Dentry cache hash table entries: 512 (order: 0, 4096 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 1024 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
^^^^^^^^^^^^^^^^^^^^^^^^^^
after this print system crashes
-------------------------
Below is some trace-back from my system (I'm not uCLinux expert :), so
apologize for any obvious stuff)
I did some tracing and found that switching from IDLE task to NEW TASK
returns to 0x00000 address. I think that NEW TASK should be INIT process
in this case.
Post by Waligora
The following steps are executed prior crash (after "POSIX conformance
testing by UNIFIX" printf).
Post by Waligora
rest_init()
...
kernel_thread(init,NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNALS)
...
do_fork()
...
wake_up_process()
[fork.c(~890)] wait_for_completion(&vfork)
... this goes to
schedue();
...
[sched.c(~600)] del_from_runqueue(prev)
[sched.c(~686)] prepare_to_switch()
[sched.c(~719)] switch_to(prev,next,prev)
[entry.S(~319)] resume
[entry.S(~100)] ret_from_fork
[sched.c(~530)] schedule_tail
[entry.S(~163)] ret_from_exception goes to 0x00000
Please let me know if data flow above is correct. What could be the most
possible reason of such behavior?
Post by Waligora
Thanks in advance for any hints/suggestions.
Waligora.
Thomas Chen
2003-05-26 17:30:15 UTC
Permalink
a basic question.... if the target has, say, four different type of
serial chips.... (i mean completely different registers, fifo...etc)

is it better to have one serial.c that handles all four different type
of devices, or better to have four different xxx_serial.c ???

ps... currently i have them all in one serial.c, but wonder whether this
is the best approach
Greg Ungerer
2003-05-26 23:59:05 UTC
Permalink
Hi Thomas,
Post by Thomas Chen
a basic question.... if the target has, say, four different type of
serial chips.... (i mean completely different registers, fifo...etc)
is it better to have one serial.c that handles all four different type
of devices, or better to have four different xxx_serial.c ???
ps... currently i have them all in one serial.c, but wonder whether this
is the best approach
Are the serial devices separate "chips"?

If the answer is yes, then I would separate them into separate
drivers. Since it is quite reasonable that others may use that
same chip/device on another board.

If they are physically in the same device, with very little
chance they would ever appear separately then I guess all
in one is fine.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
Chris Alfred
2003-05-27 02:52:39 UTC
Permalink
Hello,

I have been unable to access the searchable
development email archive for a few days.
The link I was successfully using:
http://mailman.uclinux.org/htdig

Chris
David McCullough
2003-05-27 04:28:34 UTC
Permalink
Jivin Chris Alfred lays it down ...
Post by Waligora
Hello,
I have been unable to access the searchable
development email archive for a few days.
http://mailman.uclinux.org/htdig
I was talking to the sysadm today. The list machine had some sort of
major hiccup and access to subscribe/archives should be back later this
week if everything goes ok. Its up now, it's just not available to the
world yet. Thats all the details I have,

Cheers,
Davidm
--
David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com
davidm at snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + Security
Sivam
2003-05-27 10:25:30 UTC
Permalink
Hi All,

I have a Xicor X1226 RTC chip in my custom board based on MCF5249 ?. can
anyone pls enlight me where i can start with to make the RTC work ?
Whether userland base clock program needs to be taken as reference ?.

Thanks
Sivam

Bernardo Innocenti
2003-05-26 18:09:50 UTC
Permalink
Post by Thomas Chen
a basic question.... if the target has, say, four different type of
serial chips.... (i mean completely different registers, fifo...etc)
is it better to have one serial.c that handles all four different type
of devices, or better to have four different xxx_serial.c ???
ps... currently i have them all in one serial.c, but wonder whether
this is the best approach
I would prefer the latter, perhaps sharing common serial code with
something like generic_serial.c.

You can also share the same device major across different serial
drivers. serial.c has some (semi-broken) support for doing it.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/

Please don't send Word attachments.
See: http://www.gnu.org/philosophy/no-word-attachments.html
Continue reading on narkive:
Loading...