[ Sorry for the late response, but this [censored] Outlook has no
threading
support :-( ]
This board is not supported yet by the official uclinux
distribution,
but I tried to keep board specific changes separate.
Nice price :-)
Yes. Unfortunately, I still can't get it stable. :-(
And
Hi all,
i am trying to work on ARM platform using S3c4510b processor
boardusing Skyeye emulator for now.
Before starting the hard coding part i just want a working kernel. So
i tried to compile uClinux with linux-2.6.14 kernel along with patches
from uclinux and hsc.
after tweaking
Hi,
I am using uClinux-dist-20060803 and I can do NFS
mount on the M5208EVB.
Now I would like to do a NFS root file system mount.
My question is: how to enable NFS root file system
support?
I am using dBug as bootloader and I am not sure if it
can pass boot arguments to uClinux.
Thanks,
Thanks all for the feedback. I don't feel that this gives any other
severe side effects either, besides incorrect values at boot and in
/proc/meminfo (and free command). But we will of course change to the
correct setting.
A couple of other details I have been thinking about (M5208EVB):
Hi all :)
I'm doing a driver-thing on an uCdimm5282+uCevolution combo. It's
supposed to access a 16-bit memory-mapped device via CS2, which is setup
like this:
...
if(check_mem_region(0x2001,0x0001))
{
printk(KERN_ERR - Dev_mem occupied, aborting!\n);
return
Good day Martin,
Just as a test, why don't you map the space to all areas (Supervisor/User,
etc) and see if you have the same issue?...i.e. CMSR2 = $0001
Cheers,
Sam
- Original Message -
From: Martin Filtenborg [EMAIL PROTECTED]
To: uclinux-dev@uclinux.org
Sent: Wednesday,
Quoth Martin Voss :
I agree that useable SDRAM starts at 0x4002 since dBUG uses the
first 0x2. The physical end address of the SDRAM is 0x4200
(32MB).
[...]
Since the first 0x2 is used by dBUG, why is MEM_BASE 0x4000
and not 0x4002 ? Any shouldn't MEM_SIZE be
Hi,
I have the same kinda hardware using 2 SDRAM's connected to MCF5208
(D0-D15 to one sdram and D16-D31 to another). When i pull the DDRAMSEL
to high(SDRAM), then i couldn't view the flash memory content through
the coldfire-debugger. If i put the DRAMSEL to low(which is DDR and is
wrong) i
Hi martin,
Martin Voss wrote:
Thanks all for the feedback. I don’t feel that this gives any other
severe side effects either, besides incorrect values at boot and in
/proc/meminfo (and free command). But we will of course change to the
correct setting.
A couple of other details I have been
Hi Josef,
Wolf, Josef wrote:
I have a problem with HW/SW floating-point mismatches when I try to
compile uClinux-dist-20051014 with arm-linux-tools-20061213. The
problem
appears when compilation of the user directory (starting with boa)
starts
[ ... ]
ucfront-gcc arm-linux-gcc -Os
While I'm not familiar with the 5208, isn't dBUG in Flash, not SDRAM?
Once it stops running (by passing control to Linux) then any RAM it was
using should be fair game, provided that all its hooks (interrupt
vectors etc) are removed (which they should be).
My first reaction was Duh! Why
Quoth Bob Furber [EMAIL PROTECTED]:
I believe that amongst other things, the dBUG stack is near
the bottom of SDRAM. So, it becomes a bit of a philosophical
question: What do we want to happen when uClinux is shut
down? Return to the dBUG prompt?
Perhaps if uClinux could trigger a soft
Hi Bob,
Bob Furber wrote:
While I'm not familiar with the 5208, isn't dBUG in Flash, not SDRAM?
Once it stops running (by passing control to Linux) then any RAM it was
using should be fair game, provided that all its hooks (interrupt
vectors etc) are removed (which they should be).
My first
Hi Darwin,
Darwin Chen wrote:
I have some questions about uClinux and bootloader, the answer must be in
the kernel source code, but I can't find it, and google master can't yet.
So, the questions are:
1.The bootloader remaps the SDRAM/Flash address, the different bootloader
has different
Hi Vivek,
vivek tyagi wrote:
I am working on providing shared flat support for ARM.The approach is
similar to the way it has been implemented for m68k.I am aware of the
changes required and tested it by putting a manual hack in the flat
file.Before attempting to make the necessary changes in
Quoth Greg Ungerer [EMAIL PROTECTED]:
In modern 2.6 version kernels the RAM mapping is configurable
at make config for at least m68k/coldfire and arm, maybe
others too. In older 2.4 kernels it was often hard coded into
platform specific code for that board support.
Not all of it is
Hi Gavin,
Gavin Lambert wrote:
Quoth Greg Ungerer [EMAIL PROTECTED]:
In modern 2.6 version kernels the RAM mapping is configurable
at make config for at least m68k/coldfire and arm, maybe
others too. In older 2.4 kernels it was often hard coded into
platform specific code for that board
Greg Ungerer wrote:
Gavin Lambert wrote:
although I think most of that *is*
overridable by the config.
It is not completely configurable at config time.
^^^
Ofcourse I meant to say It _is_ completely configurable :-)
Regards
Greg
18 matches
Mail list logo
