gmane.linux.uclinux.devel

Re: [RFC/PATCH] m68knommu: add supportforColdfire?m5441x

Philippe De Muyter — 2012-05-23T08:55:04

Ok, the 54xx fec drivers would not help then.

Best regards

Philippe
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [RFC/PATCH] m68knommu: add support forColdfirem5441x

Philippe De Muyter — 2012-05-23T07:38:46

Are they identical to the fec's of the 548x ? I have drivers for them
(actually they came from the freescale port for 2.6.25, but I have cleaned
them up, made them use phylib, and made them current for 2.6.37).  I don't
know if they still would be compatible with 3.5.

Philippe

_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[RFC/PATCH] m68knommu: add support for Coldfire m5441x

Steven King — 2012-05-23T02:03:59

The 5441x (54410/54415/54416/54417/54418) is similar to the 532x in the same 
way the 532x is similar to the 5208; it doesn't have either IPSBAR nor MBAR, 
instead everything resides at a fixed address.  Many of the registers common 
between the 5441x and the 532x live at the same address as the 532x, but of 
course the 5441x has a v4e core, cache and mmu, along with 10 uarts! 6 i2c 
controllers, 4 dma capable spi controllers, usb and much more.  This patch is 
just a quick and dirty hack to get it booting on the twr-mcf5441x board.  Its 
currently nommu only (well, I havent even tried it with the mmu),  It doesnt 
include support for the 2 fec controllers, the ones on the 5441x are just 
slightly different in some non obvious way so they dont quite work yet.

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/Kconfig.cpu                   |    7 +
 arch/m68k/Kconfig.machine               |    1 -
 arch/m68k/Makefile                      |    1 +
 arch/m68k/include/asm/gpio.h            |   11 +-

[RFC/PATCH] m68knommu: refactor Coldfire GPIO not torequire GPIOLIB, eliminate mcf_gpio_chips.

Steven King — 2012-05-21T20:10:19

If we're not connecting external GPIO extenders via i2c or spi or whatever, we 
probably don't need GPIOLIB.  If we provide an alternate implementation of 
the GPIOLIB functions to use when only on-chip GPIO is needed, we can change 
ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes 
optional.

The downside is that in the GPIOLIB=n case, we lose all error checking done by 
gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the 
only checking that can be done is if we reference a gpio on an external part. 
Targets that need the extra error checking can still select GPIOLIB=y.

For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a 
single chip, eliminating the tables of chips in the 5xxx.c files.  The 
original motivation for the definition of multiple chips was to match the way 
many of the Coldfire variants defined their gpio as a spare array in memory.  
However, all this really gains us is some error checking when we request a 
gpio, gpi

Re: [PATCH v2 3/3] m68k: merge the MMU and non-MMU versions of the entry.S code

Geert Uytterhoeven — 2012-05-20T09:22:01

Acked-by: Geert Uytterhoeven <geert< at >linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >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< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH v2 2/3] m68k: use jbsr to call functionsinstead of bsrl

Geert Uytterhoeven — 2012-05-20T09:15:44

Acked-by: Geert Uytterhoeven <geert< at >linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >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< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH 2/2] m68k: merge the MMU and non-MMU versions of the arch dma code

Geert Uytterhoeven — 2012-05-20T09:01:27

Acked-by: Geert Uytterhoeven <geert< at >linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >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< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: Latest GCC toolchain for m68k

Greg Ungerer — 2012-05-18T05:17:34

Hi Luis,

On 18/05/12 00:21, Luis Alves wrote:

Yeah, interesting discussion :-)



Well, I consider it a bug still (I will probably make some gcc people
unhappy :-(  The ABI change itself doesn't really have anything to do
with it. If you use "gcc -m68000" to generate code that cannot work
then it is a bug. I couldn't in good conscience call that a configuration
error (though we know you can fix it by changing the that STRICT_ALIGNMENT
setting).

But that is just my take on it.

Regards
Greg

Re: Latest GCC toolchain for m68k

Lennart Sorensen — 2012-05-17T14:54:18

gcc 4.3 at least change the size of floating point from 80 to 64bit on
coldfire (and possibly on m68k in general, not sure), and also made some
changes in other things.

gcc 4.2 would fail to compile some programs for me, running out of space
in the offset table as far as I can tell, while gcc 4.3 has never had
any problems with that.  My understanding is that gcc 4.3 switched to a
different way of handling the GOT which works much better, but is almost
certainly incompatible with the old method.  gcc 4.3 also optimizes a
lot more in m68k than 4.2 (I had to insert memory barriers in uboot to
convince gcc 4.3 not to rearrange seemingly unrelated memory read and
writes in the memory controller setup, where as gcc 4.2 did so little
optimization that it never had any issue).  gcc 4.3 didn't do anything
wrong, the code simply wasn't specific enough about what it wanted.

So I like the gcc 4.3 improvements over 4.2.

Re: Latest GCC toolchain for m68k

Luis Alves — 2012-05-17T14:21:12

Hi Greg,

Yes, that file exists in the sources gcc-<version>/gcc/config/m68k/uclinux.h
I've changed those flags and it works (at least in a small test with
the first pass gcc).

But take a look at the comments in my bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386

Someone says that it is related to the ABI change in gcc >= 4.3.x and
that I should use as target 'm68k-uclinuxoldabi' and
--with-cpu=m68000.

For now I've just changed the flags in the header file... maybe I'll
try building it with that weird target (m68k-uclinuxoldabi).


Regards,
Luis Alves



On Thu, May 17, 2012 at 2:59 PM, Greg Ungerer <gerg< at >snapgear.com> wrote:
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: Latest GCC toolchain for m68k

Greg Ungerer — 2012-05-17T06:45:07

Hi Luis,

On 05/17/2012 12:58 PM, Luis Alves wrote:

That is bad...



Ouch, doesn't sound like much fun.



The gcc compile options looked good to me. If you have -m68000 set
the you should be getting code that is good for 68000. I guess the
code generation is at least only using the correct set of 68000
instructions.

Choosing a different optimization level may change the instruction/
addressing modes used. But really that would just be a work around.

Otherwise I would suggest sticking with 4.2.4 if that works.

Regards
Greg

Re: Latest GCC toolchain for m68k

Luis Alves — 2012-05-17T02:58:34

Hi Greg,

I've built a new toolchain using the latest tools and gcc-4.6.4
(gcc-4.7.0 is giving me compiler internal errors!).
But unfortunately the results are the same (bad assembly code - It
look it is producing 68020 code, since when I use the -m68020 flag,
the resulting assembly code is equal!)

I've downgraded gcc to 4.2.4 (the version I was using before this
toolchain quest) and it works (produces correct assembly code).
I don't know what is the latest working version for the 68000 targets.
Maybe I'll go one by one until I find the broken one...

I guess this is related to gcc so I've reported it as a bug it in the
gcc bugzilla (Bug 53386).

Do you have any further suggestion?

Thanks and regards,
Luis Alves



On Wed, May 16, 2012 at 9:42 PM, Luis Alves <ljalvs< at >gmail.com> wrote:
_______________________________________________
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
To unsubscribe see:
ht

[PATCH V3] m68knommu: driver for Freescale ColdfireI2C controller.

Steven King — 2012-05-17T02:10:35

D'oh!  I really dropped the ball on this, but I figure better late than never ;-).

Changes since V2:

drivers/i2c/busses/i2c-coldfire.c:
* As Ben suggested, making the interrupt handler do most of the message
  processing and wake the thread when its done vastly improves performance.
* preliminary support for PM_RUNTIME; but as there isn't arch support for for 
  PM_RUNTIME it doesn't do anything yet.
* fixed a bug when the driver would hang on waiting for bus busy if the bus
  never went busy.

drivers/i2c/busses/Kconfig:
* its easier to list the Coldfire MCUs that don't have I2C.

arch/m68k/include/asm/mcfi2c.h:
* moved the defines for the various Coldfire MCUs to the specific header
   file for the various Coldfire MCUs. 


Support for the Freescale Coldfire I2C controller.

Signed-off-by: Steven King <sfking< at >fedc.com>
---
 arch/m68k/include/asm/mcfi2c.h    |   15 ++
 drivers/i2c/busses/Kconfig        |   10 +
 drivers/i2c/busses/Makefile       |    1 +
 drivers/i2c/busses/i2c-coldfire.c |  497 +++++++++

Re: [PATCH] mtd: clean up uclinux.c map driver

Mike Frysinger — 2012-05-16T16:23:44

would be good to add a comment so someone doesn't clean this up again.
 i can post a patch for that though.

i know the current struct behavior is ugly, but it's cleaner than
previous iterations ;)
-mike
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH] mtd: clean up uclinux.c map driver

Greg Ungerer — 2012-05-16T11:49:42

No I don't see any existing place that makes any sense. I guess it
could be something like a new file include/linux/mtd/uclinux.h.

But it looks like Artem is ok with just reverting it to not be static.
I am happy to leave it that way if you are.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg< at >snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: Latest GCC toolchain for m68k

Greg Ungerer — 2012-05-16T11:44:08

Hi Luis,

On 05/16/2012 07:12 PM, Luis Alves wrote:

What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)



Any m68k targeted compiler should be able to generate code for any
family member with the right command line options. With the bundled
toolchains you may not have the libs generated for your specific
CPU member though.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg< at >snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinu

Re: Latest GCC toolchain for m68k

Luis Alves — 2012-05-16T09:12:58

Hi Greg,

I've solved the missing libraries problem but the toolchain you
provided isn't generating proper code for the 68000.

I've disassembled the kernel and checked the 'proc_net_ns_init'
function, where the kernel is hanging more precisely at the 'memcpy'
intruction.

So, the memcpy gets compiled into a movel instruction with an odd
displacement (causing a bus error).


compiled into:

[...]
  2175b8:217c 6e65 7400 movel #1852142592,%a0< at >(77)
  2175be:004d
[...]


The previous toolchain is generating 4 moveb intructions in this case.
I also see some other differences related to move opcodes.

For instance, the previous toolchain loads an address content to the
stack by doing this:

  207104:2f39 001f 54c8 movel 1f54c8 <malloc_sizes+0x1c>,%sp< at >-
  20710a:4eb9 0004 2bbc jsr 42bbc <kmem_cache_alloc>


The new toolchain is doing this:

  21755a:307c 001c      moveaw #28,%a0
  21755e:d1fc 0020 6d2c addal #2125100,%a0
  217564:2f10           movel %a0< at >,%sp< at >-
  217566:4eb9 0004 640e jsr 4640e <kme

Re: [PATCH] mtd: clean up uclinux.c map driver

Mike Frysinger — 2012-05-16T05:02:39

i thought you were going for merging anyways.

where would you suggest adding such a decl ?  there isn't an existing
one i can see that this would fit into.  might have to create a new
one just for this ?
-mike
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH] mtd: clean up uclinux.c map driver

Greg Ungerer — 2012-05-16T02:55:07

I agree, of course. It wasn't done to knowingly break an arch. But
the sparse warning can be fixed with a proper declaration, that
would avoid you having a local extern for it in
arch/blackfin/kernel/setup.c as well. Cleaner all round.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg< at >snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH] mtd: clean up uclinux.c map driver

Mike Frysinger — 2012-05-16T02:42:59

perhaps, but marking it static to fix a warning that people rarely see
whilst simultaneously knowingly breaking an arch doesn't sound like
the correct trade off.
-mike
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [PATCH] mtd: clean up uclinux.c map driver

Greg Ungerer — 2012-05-16T00:45:29

A comment won't fix the sparse warning. You need a proper declaration.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg< at >snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
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
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev