[uClinux-dev] Re: [PATCH] FLAT: fix unmap len in load error path
Mike Frysinger vap...@gentoo.org wrote: The data chunk is mmaped with 'len' which remains unchanged, so use that when unmapping in the error path rather than trying to recalculate (and incorrectly so) the value used originally. Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: David Howells dhowe...@redhat.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
[uClinux-dev] Activate nano in uclinux lpc2478stk
Hi, I bought lpc2478stk from olimex some weeks ago. I've tested the framebuffer and managed to draw something on the screen. But right now i'm thinking to write texts to the screen and someone told me that nano can do that. So my question is, how can i activate nano in uclinux distribution given by olimex? since when i compile the kernel, it didnt askedme anything. Thanks for your time, Regards, -- Wan Mohd Fairuz WAN ISMAIL Masters in Electronics Engineering, Majoring in Embedded System Engineering, Polytech Nice Sophia Antipolis, FRANCE. +33(0)643461339 +60172071591 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my ___ 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] dm9000 with mcf5307
hi all, i also found this link that say that drivers 1.2 are not suitable for dm9000e that is in my board. http://www.cutedigi.com/article_info.php?articles_id=29 Could it be that i have to look for a v 1.2 driver ? thanks angelo On 01/06/2010 21:16, angelo wrote: Hi Lennart, i connected stright D0:D31 of coldfire with D0:31 of the chip. I still didn't looked too much inside the driver, but actually, probably i am one step before, the dm9000_probe is not called at all (i put some printk inside). regards, angelo On 01/06/2010 21:01, Lennart Sorensen wrote: On Tue, Jun 01, 2010 at 08:46:19PM +0200, angelo wrote: i am trying to make work properly the dm9000 driver in a custom board with coldfire mcf5307. Until now, this is what i did: - driver was already there, inside linux-2.6.X folder, i just enabled in the config a selectable option for MCF5307. - i added some writesb,w,l/readsb,w,l functions in nomm_io.h arch/m68k/include/asm/io_no.h /** angelo, DM9000 support for MCF5307, start */ #define readsb(b,addr,count) readb(addr) #define readsw(b,addr,count) readw(addr) #define readsl(b,addr,count) readl(addr) #define writesb(b,addr,count) (io_insb((unsigned int)b,addr,count)) #define writesw(b,addr,count) (io_insw((unsigned int)b,addr,count)) #define writesl(b,addr,count) (io_insl((unsigned int)b,addr,count)) /* angelo, DM9000 support for MCF5307, end */ kernel compile fine, but i just see the following line at boot: dm9000 Ethernet Driver, V1.31 and nothing else dm9000 related, so no dm9000_probe is executed, and so the chip is not initialized. Is the endianess right? I have seen the DM9000 used with little endian arm systems. I have not seen it on coldfire (big endian) systems. ___ 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] dm9000 with mcf5307
On Tue, Jun 01, 2010 at 09:16:08PM +0200, angelo wrote:
i connected stright D0:D31 of coldfire with D0:31 of the chip. I still
didn't looked too much inside the driver, but actually, probably i am
one step before, the dm9000_probe is not called at all (i put some
printk inside).
Perhaps you need a call in the platform setup code. It isn't PCI after
all and almost certainly doesn't have any kind of autodetection facility.
Looks like you need something like this in your board specific startup
(for example stamp.c on blackfin)
#if defined(CONFIG_DM9000) || defined(CONFIG_DM9000_MODULE)
static struct resource dm9000_resources[] = {
[0] = {
.start = 0x203FB800,
.end= 0x203FB800 + 1,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0x203FB804,
.end= 0x203FB804 + 1,
.flags = IORESOURCE_MEM,
},
[2] = {
.start = IRQ_PF9,
.end= IRQ_PF9,
.flags = (IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE),
},
};
static struct platform_device dm9000_device = {
.name = dm9000,
.id = -1,
.num_resources = ARRAY_SIZE(dm9000_resources),
.resource = dm9000_resources,
};
#endif
and then in platform_device something like:
dm9000_device,
Many of the arm boards using it look very similar.
--
Len Sorensen
___
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] dm9000 with mcf5307
On Tue, Jun 01, 2010 at 09:55:24PM +0200, angelo wrote: hi all, i also found this link that say that drivers 1.2 are not suitable for dm9000e that is in my board. http://www.cutedigi.com/article_info.php?articles_id=29 Could it be that i have to look for a v 1.2 driver ? The driver in Linus's current tree explicitly states that it is for DM9000E, DM9000A and DM9000B. It should work, if you get the resources defined in your board setup code, assuming you get the resources right and that the chip is hooked up correctly. -- Len Sorensen ___ 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] Re: [microblaze-uclinux] Re: [Uclinux-dist-devel] [PATCH 1/2 v2] FLAT: split the stack data alignments
Jivin Mike Frysinger lays it down ... On Thu, May 27, 2010 at 04:24, Michal Simek wrote: Mike Frysinger wrote: The stack and data have different alignment requirements, so don't force them to wear the same shoe. ??Increase the data alignment to match that which the elf2flt linker script has always been using: 0x20 bytes. ??Not only does this bring the kernel loader in line with the toolchain, but it also fixes a swath of gcc tests which try to force larger alignment values but randomly fail when the FLAT loader fails to deliver. Signed-off-by: Mike Frysinger vap...@gentoo.org Solve the problem on Microblaze: Tested-by: Michal Simek mon...@monstr.eu Who will add it to mainline? if we can get the misc nommu peeps to agree on this (looking mostly at David [McCullough] and Greg), then akpm will most likely expedite the merge. i like to think they're the best FLAT experts out there ;). Did the latest patch include the changes Paul requested. It looks like it to me, I've just been a bit distracted. If so I'll send in an Ack. Cheers, Davidm -- David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org ___ 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] Re: [PATCH 1/2 v2] FLAT: split the stack data alignments
Jivin Mike Frysinger lays it down ... The stack and data have different alignment requirements, so don't force them to wear the same shoe. Increase the data alignment to match that which the elf2flt linker script has always been using: 0x20 bytes. Not only does this bring the kernel loader in line with the toolchain, but it also fixes a swath of gcc tests which try to force larger alignment values but randomly fail when the FLAT loader fails to deliver. Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: David McCullough david_mccullo...@mcafee.com Cheers, Davidm --- v2 - split changes document better fs/binfmt_flat.c | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 49566c1..b865622 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -56,15 +56,22 @@ #endif /* - * User data (stack, data section and bss) needs to be aligned - * for the same reasons as SLAB memory is, and to the same amount. - * Avoid duplicating architecture specific code by using the same - * macro as with SLAB allocation: + * User data (data section and bss) needs to be aligned. + * We pick 0x20 here because it is the max value elf2flt has always + * used in producing FLAT files, and because it seems to be large + * enough to make all the gcc alignment related tests happy. + */ +#define FLAT_DATA_ALIGN (0x20) + +/* + * User data (stack) also needs to be aligned. + * Here we can be a bit looser than the data sections since this + * needs to only meet arch ABI requirements. */ #ifdef ARCH_SLAB_MINALIGN -#define FLAT_DATA_ALIGN (ARCH_SLAB_MINALIGN) +#define FLAT_STACK_ALIGN (ARCH_SLAB_MINALIGN) #else -#define FLAT_DATA_ALIGN (sizeof(void *)) +#define FLAT_STACK_ALIGN (sizeof(void *)) #endif #define RELOC_FAILED 0xff00ff01 /* Relocation incorrect somewhere */ @@ -129,7 +136,7 @@ static unsigned long create_flat_tables( sp = (unsigned long *)p; sp -= (envc + argc + 2) + 1 + (flat_argvp_envp_on_stack() ? 2 : 0); - sp = (unsigned long *) ((unsigned long)sp -FLAT_DATA_ALIGN); + sp = (unsigned long *) ((unsigned long)sp -FLAT_STACK_ALIGN); argv = sp + 1 + (flat_argvp_envp_on_stack() ? 2 : 0); envp = argv + (argc + 1); @@ -876,7 +883,7 @@ static int load_flat_binary(struct linux_binprm * bprm, struct pt_regs * regs) stack_len = TOP_OF_ARGS - bprm-p; /* the strings */ stack_len += (bprm-argc + 1) * sizeof(char *); /* the argv array */ stack_len += (bprm-envc + 1) * sizeof(char *); /* the envp array */ - stack_len += FLAT_DATA_ALIGN - 1; /* reserve for upcoming alignment */ + stack_len += FLAT_STACK_ALIGN - 1; /* reserve for upcoming alignment */ res = load_flat_file(bprm, libinfo, 0, stack_len); if (IS_ERR_VALUE(res)) -- 1.7.1 -- David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org ___ 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] Re: [PATCH 2/2 v2] FLAT: tweak default stack alignment
Jivin Mike Frysinger lays it down ... The recent commit 1f0ce8b3dd667dca7 which moved the ARCH_SLAB_MINALIGN default into the global header inadvertently broke FLAT for a bunch of systems. Blackfin systems now fail on any FLAT exec with: Unable to read code+data+bss, errno 14 When your /init is a FLAT binary, obviously this can be annoying ;). This stems from the alignment usage in the FLAT loader. The behavior before was that FLAT would default to ARCH_SLAB_MINALIGN only if it was defined, and this was only defined by arches when they wanted a larger alignment value. Otherwise it'd default to pointer alignment. Arguably, this is kind of hokey that the FLAT is semi-abusing defines it shouldn't. But let's ignore that and simply ignore min alignment values of 0. Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: David McCullough david_mccullo...@mcafee.com Cheers, Davidm --- v2 - split changes document better fs/binfmt_flat.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index b865622..4959a0a 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -68,7 +68,7 @@ * Here we can be a bit looser than the data sections since this * needs to only meet arch ABI requirements. */ -#ifdef ARCH_SLAB_MINALIGN +#if defined(ARCH_SLAB_MINALIGN) ARCH_SLAB_MINALIGN != 0 #define FLAT_STACK_ALIGN (ARCH_SLAB_MINALIGN) #else #define FLAT_STACK_ALIGN (sizeof(void *)) -- 1.7.1 -- David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org ___ 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] Re: [PATCH 1/2 v2] FLAT: split the stack data alignments
Mike Frysinger wrote: The stack and data have different alignment requirements, so don't force them to wear the same shoe. Increase the data alignment to match that which the elf2flt linker script has always been using: 0x20 bytes. Not only does this bring the kernel loader in line with the toolchain, but it also fixes a swath of gcc tests which try to force larger alignment values but randomly fail when the FLAT loader fails to deliver. Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: Greg Ungerer g...@uclinux.org --- v2 - split changes document better fs/binfmt_flat.c | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 49566c1..b865622 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -56,15 +56,22 @@ #endif /* - * User data (stack, data section and bss) needs to be aligned - * for the same reasons as SLAB memory is, and to the same amount. - * Avoid duplicating architecture specific code by using the same - * macro as with SLAB allocation: + * User data (data section and bss) needs to be aligned. + * We pick 0x20 here because it is the max value elf2flt has always + * used in producing FLAT files, and because it seems to be large + * enough to make all the gcc alignment related tests happy. + */ +#define FLAT_DATA_ALIGN(0x20) + +/* + * User data (stack) also needs to be aligned. + * Here we can be a bit looser than the data sections since this + * needs to only meet arch ABI requirements. */ #ifdef ARCH_SLAB_MINALIGN -#define FLAT_DATA_ALIGN(ARCH_SLAB_MINALIGN) +#define FLAT_STACK_ALIGN (ARCH_SLAB_MINALIGN) #else -#define FLAT_DATA_ALIGN(sizeof(void *)) +#define FLAT_STACK_ALIGN (sizeof(void *)) #endif #define RELOC_FAILED 0xff00ff01 /* Relocation incorrect somewhere */ @@ -129,7 +136,7 @@ static unsigned long create_flat_tables( sp = (unsigned long *)p; sp -= (envc + argc + 2) + 1 + (flat_argvp_envp_on_stack() ? 2 : 0); - sp = (unsigned long *) ((unsigned long)sp -FLAT_DATA_ALIGN); + sp = (unsigned long *) ((unsigned long)sp -FLAT_STACK_ALIGN); argv = sp + 1 + (flat_argvp_envp_on_stack() ? 2 : 0); envp = argv + (argc + 1); @@ -876,7 +883,7 @@ static int load_flat_binary(struct linux_binprm * bprm, struct pt_regs * regs) stack_len = TOP_OF_ARGS - bprm-p; /* the strings */ stack_len += (bprm-argc + 1) * sizeof(char *); /* the argv array */ stack_len += (bprm-envc + 1) * sizeof(char *); /* the envp array */ - stack_len += FLAT_DATA_ALIGN - 1; /* reserve for upcoming alignment */ + stack_len += FLAT_STACK_ALIGN - 1; /* reserve for upcoming alignment */ res = load_flat_file(bprm, libinfo, 0, stack_len); if (IS_ERR_VALUE(res)) -- 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
[uClinux-dev] Re: [Uclinux-dist-devel] [PATCH 1/2 v2] FLAT: split the stack data alignments
On Thu, May 27, 2010 at 04:24, Michal Simek wrote: Mike Frysinger wrote: The stack and data have different alignment requirements, so don't force them to wear the same shoe. Increase the data alignment to match that which the elf2flt linker script has always been using: 0x20 bytes. Not only does this bring the kernel loader in line with the toolchain, but it also fixes a swath of gcc tests which try to force larger alignment values but randomly fail when the FLAT loader fails to deliver. Signed-off-by: Mike Frysinger vap...@gentoo.org Solve the problem on Microblaze: Tested-by: Michal Simek mon...@monstr.eu Who will add it to mainline? if we can get the misc nommu peeps to agree on this (looking mostly at David [McCullough] and Greg), then akpm will most likely expedite the merge. i like to think they're the best FLAT experts out there ;). -mike ___ 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] Re: [PATCH 1/2 v2] FLAT: split the stack data alignments
On Wed, May 26, 2010 at 04:45, Mike Frysinger wrote: The stack and data have different alignment requirements, so don't force them to wear the same shoe. Increase the data alignment to match that which the elf2flt linker script has always been using: 0x20 bytes. Not only does this bring the kernel loader in line with the toolchain, but it also fixes a swath of gcc tests which try to force larger alignment values but randomly fail when the FLAT loader fails to deliver. btw, a follow up patch might be to move the shared lib identifiers from the start of the data section to the end of it so that the re-aligning isnt necessary (we'd get a 4k page alignment from mmap and such). but i cant seem to figure out how these identifiers are being read/written. otherwise, the fact that we're force aligning to 0x20 bytes means that there is always room for 8 identifiers ... no point in flipping between 1 or 4, at least from this point of view ... -mike ___ 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
