Re: [uClinux-dev] [PATCH m68knommu] Improve short help of m68knommu/Kconfig/RAMSIZE for '0' case
On Fri, May 21, 2010 at 07:49, Greg Ungerer wrote:
> Philippe De Muyter wrote:
>>
>> While it is explained in the long help text, meaning of '0' for RAMSIZE
>> is easily overlooked because is not mentionned in the short help text.
>> Add that.
>
> I am reluctant to change that string to something so long.
> When running menuconfig for example on a normal 80 column
> window the end is chopped of. I much prefer brief strings
> in the prompt line.
... "or auto-detect"?
Besides, "bootloader-based autodetection" is not the same as
"try to probe the RAM size at runtime".
>> Signed-off-by: Philippe De Muyter
>> ---
>> arch/m68knommu/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig
>> index 064f591..af57ec1 100644
>> --- a/arch/m68knommu/Kconfig
>> +++ b/arch/m68knommu/Kconfig
>> @@ -566,7 +566,7 @@ config RAMBASE
>> processor address space.
>> config RAMSIZE
>> - hex "Size of RAM (in bytes)"
>> + hex "Size of RAM (in bytes), or 0 for bootloader-based autodetection"
>> default "0x40"
>> help
>> Define the size of the system RAM. If you select 0 then the
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename < TASK_SIZE test in do_getname() when no MMU
On Fri, May 21, 2010 at 00:29, Mike Frysinger wrote:
> dont know if David subscribes to this list ...
> On Thursday 20 May 2010 04:14:45 Philippe De Muyter wrote:
>> Hi Greg,
>>
>> --
>> Avoid filename < TASK_SIZE test in do_getname() when no MMU.
>>
>> Without MMU, filenames can be anywhere in memory. It is thus wrong to
>> check that filename is before TASK_SIZE in do_getname().
>>
>> Signed-off-by: Philippe De Muyter
>> ---
>> fs/namei.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/namei.c b/fs/namei.c
>> index b86b96f..658bc1d 100644
>> --- a/fs/namei.c
>> +++ b/fs/namei.c
>> @@ -119,12 +119,14 @@ static int do_getname(const char __user *filename,
>> char *page) int retval;
>> unsigned long len = PATH_MAX;
>>
>> +#ifdef CONFIG_MMU
>> if (!segment_eq(get_fs(), KERNEL_DS)) {
>> if ((unsigned long) filename >= TASK_SIZE)
>> return -EFAULT;
>> if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
>> len = TASK_SIZE - (unsigned long) filename;
>> }
>> +#endif
>>
>> retval = strncpy_from_user(page, filename, len);
>> if (retval > 0) {
Are these also problematic?
m/nommu.c:static int validate_mmap_request(struct file *file,
unsigned long addr,
unsigned long len,
unsigned long prot,
unsigned long flags,
unsigned long pgoff,
unsigned long *_capabilities)
{
...
/* Careful about overflows.. */
rlen = PAGE_ALIGN(len);
if (!rlen || rlen > TASK_SIZE)
return -ENOMEM;
...
}
fs/namespace.c:int copy_mount_options(const void __user * data,
unsigned long *where)
{
...
/* copy_from_user cannot cross TASK_SIZE ! */
size = TASK_SIZE - (unsigned long)data;
if (size > PAGE_SIZE)
size = PAGE_SIZE;
...
}
Do we need a generic is_in_task_area() helper that always return true on nommu?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH m68knommu] Improve short help of m68knommu/Kconfig/RAMSIZE for '0' case
Hi Philippe, Philippe De Muyter wrote: While it is explained in the long help text, meaning of '0' for RAMSIZE is easily overlooked because is not mentionned in the short help text. Add that. I am reluctant to change that string to something so long. When running menuconfig for example on a normal 80 column window the end is chopped of. I much prefer brief strings in the prompt line. Regards Greg Signed-off-by: Philippe De Muyter --- arch/m68knommu/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig index 064f591..af57ec1 100644 --- a/arch/m68knommu/Kconfig +++ b/arch/m68knommu/Kconfig @@ -566,7 +566,7 @@ config RAMBASE processor address space. config RAMSIZE - hex "Size of RAM (in bytes)" + hex "Size of RAM (in bytes), or 0 for bootloader-based autodetection" default "0x40" help Define the size of the system RAM. If you select 0 then the -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] coldfire issue, _fault routine called setting VBR
Hi Angelo, angelo wrote: i have some additional info from the fault, setting VBR, An exception for invalid instruction seems to be thrown, but in any case, the same instruction shouldn't cause any exception at all. As you said, this could seems an SDRAM issue, but actually i solved the issues with it, memory test at startup pass always. What sort of memory tests do you run? How well do they check the RAM? Do you run the memory tests with cache on as well as of? I checked, 1) the opcode, it is legal, correct, as per 5307 manual movec %a7, %VBR correspond exactly to "4e7bf801" opcode in the manual. This should exclude any toolchain or any -mCPU issue. How far does execution get if you comment out that movec line? 2) before jumping to 0x400 i am checking the SDRAM, reading the code just copied in memory. Here is what i am doing: I don't really know Colilo well, but the processor is still in supervisor mode when it passes control to the newly loaded kernel isn't it? Regards Greg Sysam AMCORE boot... colilo>l 400 0 load: Sysam AMCORE download to 400 Downloaded 1129472 bytes colilo>m 0 : ffc00400 ffc0045e ffc0045e 0010: ffc0045e ffc0045e ffc0045e ffc0045e 0020: ffc0045e ffc0045e ffc0045e ffc0045e 0030: ffc0045e ffc0045e ffc0045e ffc0045e 0040: ffc0045e ffc0045e ffc0045e ffc0045e 0050: ffc0045e ffc0045e ffc0045e ffc0045e 0060: ffc0045e ffc0045e ffc0045e ffc0045e 0070: ffc0045e ffc0045e ffc0045e ffc0045e 0080: ffc0045e ffc0045e ffc0045e ffc0045e 0090: ffc0045e ffc0045e ffc0045e ffc0045e 00a0: ffc0045e ffc0045e ffc0045e ffc0045e 00b0: ffc0045e ffc0045e ffc0045e ffc0045e 00c0: ffc0045e ffc0045e ffc0045e ffc0045e 00d0: ffc0045e ffc0045e ffc0045e ffc0045e 00e0: ffc0045e ffc0045e ffc0045e ffc0045e 00f0: ffc0045e ffc0045e ffc0045e ffc0045e ... colilo>m 400 0400: 4e7146fc 27002e7c 4e7bf801 0410: 23cf000f ce3c2e7c 23cf000f 0420: ce38203c 0100 d08f23c0 000fce44 0430: 203c0100 4e7b 00024e71 203c 0440: c0204e7b 00047000 4e7b0005 203ca000 0450: 02004e7b 00024e71 43f90012 012023c9 0460: 000fce40 41f90011 400043f9 00120120 0470: 428020c0 b3c86600 fffa41f9 0010a000 0480: 4fe81000 4eb90010 b4744efa fffe 0490: 4e56ffa0 48d70c3c 266e0008 200f0280 04a0: f000 20402a28 00104ab9 0011400c 04b0: 66fa 4e932800 4ab90011 400c667a 04c0: 42001d40 ffc04a84 671072ed b284670a 04d0: 4ab90011 400c6600 0136240f 0282 04e0: f0002442 baaa0010 671c4878 00404879 04f0: 000eeb6c 486effc0 4eb90008 de482545 colilo>g 400 Vector table still contain offsets for the colilo "_fault" handler routine. Anyway, even if everything is correct in memory, jumping to 0x400 i get the exception setting VBR (@ offset 0x40C). I am now suspecting of a kind of bad fetching instructions from the SDRAM, like if 16bit (2bytes)opcodes are read correctly, but not the longer opcodes. I am really without any other ideas here. Thanks, Angelo On 18/05/2010 23:52, angelo wrote: brianW, thanks for the reply, i am not using %a7, it is the uClinux kernel that use the stack pointer as a temporary register. It is quite impossible that head.S of the kernel have issues open. #CONFIG_VECTORBASE is 0x Anyway, i replaced %a7 with %d0, just for test. Issue happen exactly there, at the same line, setting VBR. I have read that movec can trig an "illegal instruction" exception, and i guess this is exactly what's happening here. I had already the kernel running some months ago, one of the things i changed is the toolchain, but also the version of the uClinux distribution. I am starting to have some doubts on the toolchain. Regards, Angelo On 18/05/2010 23:38, wi...@ecs.csus.edu wrote: [...] At reset, the "colilo" bootloader test the SDRAM memory, than start up correctly giving the prompt. Kernel 2.6 has been prepared with sdram start at 0x, vector start at 0x, kernel code start at 0x400. I load now through colilo "load" command the kernel (linux.bin) at 0x400 (SDRAM, flash is remapped at 0xffc0 from colilo at reset). Once i run the code from 0x400, after some instructions the $pc jump to the "colilo" "_fault" routine. I inserted a loop in linux-2.6.x/arch/m68knommu/platform/coldfire/head.S, to find the exact point where the jump happen, as below: _start: nop /* filler */ movew #0x2700, %sr /* no interrupts */ /* * Do any platform or board specific setup now. Most boards * don't need anything. Those exceptions are define this in * their board specific includes. */ PLATFORM_SETUP /* * Create basic memory configuration. Set VBR accordingly, * and size memory. */ movel #CONFIG_VECTORBASE,%a7 _loop: jmp _loop movec %a7,%VBR/* set vectors addr */ *<<-- this line cause the jump to _fault* movel %a7,_ramvec
Re: [uClinux-dev] Error compiling uClinux on Ubuntu 9.10
Hi Jonathan, HALLEE, JONATHAN wrote: I have some problems compiling uClinux version. I have downloaded uClinux-dist-20070130 and installed the toolchain |/m68k-uclinux-tools-20061214./|| I also added /usr/local/bin to $PATH. Since I’m using Ubuntu 9.10, I also linked the /bin/sh to bash.| It would be great if someone could help me. r...@ubuntu:~/uClinux-dist$ make make -C tools/ucfront make[1]: Entering directory `/home/rohs/uClinux-dist/tools/ucfront' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/rohs/uClinux-dist/tools/ucfront' ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront tools/ucfront-gcc ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront tools/ucfront-g++ ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront-ld tools/ucfront-ld make ARCH=m68knommu CROSS_COMPILE=m68k-elf- -j4 -C linux-2.6.x || exit 1 make[1]: m68k-elf-gcc: Command not found make[1]: Entering directory `/home/rohs/uClinux-dist/linux-2.6.x' CHK include/linux/version.h CHK include/linux/utsrelease.h CC scripts/mod/empty.o /bin/sh: /usr/local/bin/m68k-elf-gcc: No such file or directory Its not finding your toolchain. Check your toolchain install, did the m68k-elf-* binaries end up in /usr/local/bin? Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename < TASK_SIZE test in do_getname() when no MMU
dont know if David subscribes to this list ...
On Thursday 20 May 2010 04:14:45 Philippe De Muyter wrote:
> Hi Greg,
>
> --
> Avoid filename < TASK_SIZE test in do_getname() when no MMU.
>
> Without MMU, filenames can be anywhere in memory. It is thus wrong to
> check that filename is before TASK_SIZE in do_getname().
>
> Signed-off-by: Philippe De Muyter
> ---
> fs/namei.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index b86b96f..658bc1d 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -119,12 +119,14 @@ static int do_getname(const char __user *filename,
> char *page) int retval;
> unsigned long len = PATH_MAX;
>
> +#ifdef CONFIG_MMU
> if (!segment_eq(get_fs(), KERNEL_DS)) {
> if ((unsigned long) filename >= TASK_SIZE)
> return -EFAULT;
> if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
> len = TASK_SIZE - (unsigned long) filename;
> }
> +#endif
>
> retval = strncpy_from_user(page, filename, len);
> if (retval > 0) {
signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Error compiling uClinux on Ubuntu 9.10
Hi all, I have some problems compiling uClinux version. I have downloaded uClinux-dist-20070130 and installed the toolchain m68k-uclinux-tools-20061214. I also added /usr/local/bin to $PATH. Since I'm using Ubuntu 9.10, I also linked the /bin/sh to bash. It would be great if someone could help me. r...@ubuntu:~/uClinux-dist$ make make -C tools/ucfront make[1]: Entering directory `/home/rohs/uClinux-dist/tools/ucfront' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/rohs/uClinux-dist/tools/ucfront' ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront tools/ucfront-gcc ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront tools/ucfront-g++ ln -sf /home/rohs/uClinux-dist/tools/ucfront/ucfront-ld tools/ucfront-ld make ARCH=m68knommu CROSS_COMPILE=m68k-elf- -j4 -C linux-2.6.x || exit 1 make[1]: m68k-elf-gcc: Command not found make[1]: Entering directory `/home/rohs/uClinux-dist/linux-2.6.x' CHK include/linux/version.h CHK include/linux/utsrelease.h CC scripts/mod/empty.o /bin/sh: /usr/local/bin/m68k-elf-gcc: No such file or directory make[3]: *** [scripts/mod/empty.o] Error 1 make[2]: *** [scripts/mod] Error 2 make[1]: *** [scripts] Error 2 make[1]: INTERNAL: Exiting with 5 jobserver tokens available; should be 4! make[1]: Leaving directory `/home/rohs/uClinux-dist/linux-2.6.x' make: *** [linux] Error 1 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] coldfire issue, _fault routine called setting VBR
Dear all, i have some additional info from the fault, setting VBR, An exception for invalid instruction seems to be thrown, but in any case, the same instruction shouldn't cause any exception at all. As you said, this could seems an SDRAM issue, but actually i solved the issues with it, memory test at startup pass always. I checked, 1) the opcode, it is legal, correct, as per 5307 manual movec %a7, %VBR correspond exactly to "4e7bf801" opcode in the manual. This should exclude any toolchain or any -mCPU issue. 2) before jumping to 0x400 i am checking the SDRAM, reading the code just copied in memory. Here is what i am doing: Sysam AMCORE boot... colilo>l 400 0 load: Sysam AMCORE download to 400 Downloaded 1129472 bytes colilo>m 0 : ffc00400 ffc0045e ffc0045e 0010: ffc0045e ffc0045e ffc0045e ffc0045e 0020: ffc0045e ffc0045e ffc0045e ffc0045e 0030: ffc0045e ffc0045e ffc0045e ffc0045e 0040: ffc0045e ffc0045e ffc0045e ffc0045e 0050: ffc0045e ffc0045e ffc0045e ffc0045e 0060: ffc0045e ffc0045e ffc0045e ffc0045e 0070: ffc0045e ffc0045e ffc0045e ffc0045e 0080: ffc0045e ffc0045e ffc0045e ffc0045e 0090: ffc0045e ffc0045e ffc0045e ffc0045e 00a0: ffc0045e ffc0045e ffc0045e ffc0045e 00b0: ffc0045e ffc0045e ffc0045e ffc0045e 00c0: ffc0045e ffc0045e ffc0045e ffc0045e 00d0: ffc0045e ffc0045e ffc0045e ffc0045e 00e0: ffc0045e ffc0045e ffc0045e ffc0045e 00f0: ffc0045e ffc0045e ffc0045e ffc0045e ... colilo>m 400 0400: 4e7146fc 27002e7c 4e7bf801 0410: 23cf000f ce3c2e7c 23cf000f 0420: ce38203c 0100 d08f23c0 000fce44 0430: 203c0100 4e7b 00024e71 203c 0440: c0204e7b 00047000 4e7b0005 203ca000 0450: 02004e7b 00024e71 43f90012 012023c9 0460: 000fce40 41f90011 400043f9 00120120 0470: 428020c0 b3c86600 fffa41f9 0010a000 0480: 4fe81000 4eb90010 b4744efa fffe 0490: 4e56ffa0 48d70c3c 266e0008 200f0280 04a0: f000 20402a28 00104ab9 0011400c 04b0: 66fa 4e932800 4ab90011 400c667a 04c0: 42001d40 ffc04a84 671072ed b284670a 04d0: 4ab90011 400c6600 0136240f 0282 04e0: f0002442 baaa0010 671c4878 00404879 04f0: 000eeb6c 486effc0 4eb90008 de482545 colilo>g 400 Vector table still contain offsets for the colilo "_fault" handler routine. Anyway, even if everything is correct in memory, jumping to 0x400 i get the exception setting VBR (@ offset 0x40C). I am now suspecting of a kind of bad fetching instructions from the SDRAM, like if 16bit (2bytes)opcodes are read correctly, but not the longer opcodes. I am really without any other ideas here. Thanks, Angelo On 18/05/2010 23:52, angelo wrote: brianW, thanks for the reply, i am not using %a7, it is the uClinux kernel that use the stack pointer as a temporary register. It is quite impossible that head.S of the kernel have issues open. #CONFIG_VECTORBASE is 0x Anyway, i replaced %a7 with %d0, just for test. Issue happen exactly there, at the same line, setting VBR. I have read that movec can trig an "illegal instruction" exception, and i guess this is exactly what's happening here. I had already the kernel running some months ago, one of the things i changed is the toolchain, but also the version of the uClinux distribution. I am starting to have some doubts on the toolchain. Regards, Angelo On 18/05/2010 23:38, wi...@ecs.csus.edu wrote: [...] At reset, the "colilo" bootloader test the SDRAM memory, than start up correctly giving the prompt. Kernel 2.6 has been prepared with sdram start at 0x, vector start at 0x, kernel code start at 0x400. I load now through colilo "load" command the kernel (linux.bin) at 0x400 (SDRAM, flash is remapped at 0xffc0 from colilo at reset). Once i run the code from 0x400, after some instructions the $pc jump to the "colilo" "_fault" routine. I inserted a loop in linux-2.6.x/arch/m68knommu/platform/coldfire/head.S, to find the exact point where the jump happen, as below: _start: nop /* filler */ movew #0x2700, %sr /* no interrupts */ /* * Do any platform or board specific setup now. Most boards * don't need anything. Those exceptions are define this in * their board specific includes. */ PLATFORM_SETUP /* * Create basic memory configuration. Set VBR accordingly, * and size memory. */ movel #CONFIG_VECTORBASE,%a7 _loop: jmp _loop movec %a7,%VBR/* set vectors addr */ *<<-- this line cause the jump to _fault* movel %a7,_ramvec Angelo -- Here is my guess. I did MC68010 programming _many_ years ago. Why are you using A7 as your address reg? It is the stack pointer! If you have interrupts enabled ( which you don't ), that is a very good place to crash. What could happen instead, anytime you BSR ( call a subr ), pushing the return address will corrupt your memory. If CONFIG_VECTORBASE is a Flash
[uClinux-dev] [PATCH] : Avoid filename < TASK_SIZE test in do_getname() when no MMU
Hi Greg,
--
Avoid filename < TASK_SIZE test in do_getname() when no MMU.
Without MMU, filenames can be anywhere in memory. It is thus wrong to
check that filename is before TASK_SIZE in do_getname().
Signed-off-by: Philippe De Muyter
---
fs/namei.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index b86b96f..658bc1d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -119,12 +119,14 @@ static int do_getname(const char __user *filename, char
*page)
int retval;
unsigned long len = PATH_MAX;
+#ifdef CONFIG_MMU
if (!segment_eq(get_fs(), KERNEL_DS)) {
if ((unsigned long) filename >= TASK_SIZE)
return -EFAULT;
if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
len = TASK_SIZE - (unsigned long) filename;
}
+#endif
retval = strncpy_from_user(page, filename, len);
if (retval > 0) {
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
