[uClinux-dev] Re: [PATCH] m68k: merge the mmu and non-mmu kernel/Makefiles

2011-08-13 Thread Geert Uytterhoeven 
On Thu, Aug 11, 2011 at 06:47,   wrote:
> --- a/arch/m68k/kernel/Makefile
> +++ b/arch/m68k/kernel/Makefile
> @@ -1,5 +1,20 @@
> -ifdef CONFIG_MMU
> -include arch/m68k/kernel/Makefile_mm
> -else
> -include arch/m68k/kernel/Makefile_no
> +#
> +# Makefile for the linux kernel.
> +#
> +
> +extra-$(CONFIG_MMU)    := head.o
> +extra-$(CONFIG_SUN3)   := sun3-head.o
> +extra-y                        += vmlinux.lds
> +
> +obj-y  := entry.o m68k_ksyms.o process.o ptrace.o setup.o signal.o \
> +          sys_m68k.o syscalltable.o time.o traps.o
> +
> +obj-y$(CONFIG_MMU_SUN3) += dma.o       # no, it's not a typo
> +obj-$(CONFIG_MMU)      += ints.o module.o devres.o

On MMU, we unconditionally build module.c.

> +devres-$(CONFIG_MMU)   = ../../../kernel/irq/devres.o
> +
> +ifndef CONFIG_MMU
> +obj-y                  += init_task.o irq.o
> +obj-$(CONFIG_MODULES)   += module.o

On nommu, it depends on CONFIG_MODULES.

However, most inside module.c is already protected by #ifdef CONFIG_MODULES.
Except for module_fixup(), which is empty for nommu. After moving the whole
module_fixup() inside #ifdef CONFIG_MMU, you can consolidate the module.o
entry in the Makefile.

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] m68k: reorganize Kconfig options to improve mmu/non-mmu selections

2011-08-13 Thread Geert Uytterhoeven 
On Thu, Aug 11, 2011 at 08:43, Greg Ungerer  wrote:
> On 11/08/11 16:15, Sam Ravnborg wrote:
>> On Thu, Aug 11, 2011 at 03:10:21PM +1000, g...@snapgear.com wrote:
>>> diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
>>> new file mode 100644
>>> index 000..83263ec
>>> --- /dev/null
>>> +++ b/arch/m68k/Kconfig.bus
>>> @@ -0,0 +1,98 @@
>>> +if MMU
>>> +
>>> +comment "Bus Support"
>>> +
>>> +config EISA
>>> +       bool
>>> +       help
>>> +         The Extended Industry Standard Architecture (EISA) bus was
>>> +         developed as an open alternative to the IBM MicroChannel bus.
>>> +
>>> +         The EISA bus provided some of the features of the IBM
>>> MicroChannel
>>> +         bus while maintaining backward compatibility with cards made
>>> for
>>> +         the older ISA bus.  The EISA bus saw limited use between 1988
>>> and
>>> +         1995 when it was made obsolete by the PCI bus.
>>> +
>>> +         Say Y here if you are building a kernel for an EISA-based
>>> machine.
>>> +
>>> +         Otherwise, say N.
>>> +
>>> +config MCA
>>> +       bool
>>> +       help
>>> +         MicroChannel Architecture is found in some IBM PS/2 machines
>>> and
>>> +         laptops.  It is a bus system similar to PCI or ISA. See
>>> +         (and especially the web page given
>>> +         there) before attempting to build an MCA bus kernel.
>>> +
>>> +config PCMCIA
>>> +       tristate
>>> +       help
>>> +         Say Y here if you want to attach PCMCIA- or PC-cards to your
>>> Linux
>>> +         computer.  These are credit-card size devices such as network
>>> cards,
>>> +         modems or hard drives often used with laptops computers.  There
>>> are
>>> +         actually two varieties of these cards: the older 16 bit PCMCIA
>>> cards
>>> +         and the newer 32 bit CardBus cards.  If you want to use CardBus
>>> +         cards, you need to say Y here and also to "CardBus support"
>>> below.
>>> +
>>> +         To use your PC-cards, you will need supporting software from
>>> David
>>> +         Hinds' pcmcia-cs package (see the
>>> file
>>> +         for location).  Please also read the PCMCIA-HOWTO, available
>>> from
>>> +       .
>>> +
>>> +         To compile this driver as modules, choose M here: the
>>> +         modules will be called pcmcia_core and ds.
>>> +
>>> +config NUBUS
>>> +       bool
>>> +       depends on MAC
>>> +       default y
>>
>> Do you really need EISA, MCA and PCMIA? They have no promt thus cannot be
>> selected by the user.
>
> Yes, your right, they don't look like than can be selected at all.
> None of the default configs seem to reference them either.
> Geert: do you know why these options might still be around?

Just legacy. There was a time they needed to be there. Let them go!

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] possible mcf5307 port issue

2011-08-13 Thread Angelo Dureghello 
Hi Greg and all,

good and bad news for me: the issue below has been solved, many thanks for the 
support.
It was related to a "bad/open soldering" on a small pull-up resistor network, 
and spurious interrupts was generated.

Now the board is much more stable (was crashing in 1 hour), so i left the shell 
(serial port) open, but after 1 day of uptime i get this strange lock situation:

~ # ls
binetclibmntroot   usr
devhome   media  proc   tmpvar
~ # ▒▒

- no keys are accepted from the console
- not possible to connect with telnet
- web server was still someway responding, but slower than normal, i could get 
2 times the homepage, but then seem be locked completely.
- ftp server (inetd) don't respond also, as telnet

Debug symbols are already enabled inside the kernel, but there isn't any useful 
information.

Any help is appreciated,

regards,
angelo

On 12/08/2011 10:55, angelo wrote:

> Hi Greg, many thanks for your reply,
> 
> did you use and found reliable mcf5307 boards ? I am asking since the
> errata for this chip only.
> 
> 
> the issue described in the errata was happening in u-boot, i was getting
> the trap below just after "rte" execution inside the interrupt handler.
> Also there the shown PC was different from 0x., but setting the
> "C/I" bit as they say solved the problem.
> 
> 
> *** Unexpected exception ***
> Vector Number: 3  Format: 04  Fault Status: 4
> 
> PC: 00fe910aSR: 2000SP: 00ed8af0
> D0: 2c1bD1: 001bD2: 0040D3: 00ee8b76
> D4: ffc12d08D5: D6: 00ffad57D7: 00ee8b76
> A0: 00ee8b76A1: 00fe9604A2: 00ee8bc6A3: 00ffd400
> A4: 00ff8167A5: 00ffbb00A6: 00ed8b48
> 
> *** Please Reset Board! ***
> 
> Looking better now, the uclinux trap is different, it is a Vector
> 4(illegal instruction) and not 3, but it always happen inside the
> interupt and this is probably not a case.
> 
> 
> 
> About power, i recently changed the power supply circuit inside my
> custom board, using a more reliable, switching, 3.3V regulator, 2A max
> drain (total board consume is near 400ma). I will check for noise and
> see if there are some stability issues.
> 
> About SDRAM, do you know a method to be sure it's working correctly ? Is
> there some specific test inside linux ?
> I am thinking to run a continued loop test from u-boot ram test section,
> to exclude out uclinux.
> 
> This are some informations about the board:
> 
> /proc # cat cpuinfo
> CPU:COLDFIRE(m5307)
> MMU:none
> FPU:none
> Clocking:   88.4MHz
> BogoMips:   58.98
> Calibration:29491200 loops
> /proc #
> 
> ~ # cat /proc/version
> uClinux version 2.6.36.2 (angelo@angel7) (gcc version 4.2.4) #134 Wed
> Aug 10 16:01:21 CEST 2011
> 
> ~ # cat /proc/meminfo
> MemTotal:  13864 kB
> MemFree:7164 kB
> Buffers:  16 kB
> Cached:  124 kB
> SwapCached:0 kB
> Active:   68 kB
> Inactive: 72 kB
> Active(anon):  0 kB
> Inactive(anon):0 kB
> Active(file): 68 kB
> Inactive(file):   72 kB
> Unevictable:   0 kB
> Mlocked:   0 kB
> MmapCopy:552 kB
> SwapTotal: 0 kB
> SwapFree:  0 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 0 kB
> Mapped:0 kB
> Shmem: 0 kB
> Slab:   1208 kB
> SReclaimable: 60 kB
> SUnreclaim: 1148 kB
> KernelStack: 100 kB
> PageTables:0 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit:6932 kB
> Committed_AS:  0 kB
> VmallocTotal:  0 kB
> VmallocUsed:   0 kB
> VmallocChunk:  0 kB
> ~ #
> 
> 
> regards,
> angelo
> 
> 
> On 12/08/2011 05:28, Greg Ungerer wrote:
>> Hi Angelo,
>>
>> On 11/08/11 19:52, angelo wrote:
>>> working on a port of u-boot for mcf5307 i have found a major issue
>>> due to an "errata" of this chip:
>>>
>>> from MCF5307ER pdf:
>>>
>>> 35 Corrupted Return PC in Exception Stack Frame
>>>
>>> 35.1 Description
>>> When processing an autovectored interrupt an error can occur that
>>> causes 0x to be written as
>>> the return PC value in the exception stack frame. The problem is
>>> caused by a conflict between an internal
>>> autovector access and a chip select mapped to the IACK address space
>>> (0x).
>>>
>>> 35.2 Workaround
>>> • Set the C/I bit in the chip select mask register (CSMR) for the
>>> chip select that is mapped to
>>> 0x. This will prevent the chip select from asserting for IACK
>>> accesses.
>>> • Remap the chip select to a different address range.
>>> • Use external logic to provide external vectors for all interrupts
>>> instead of autovectoring.
>>> MASKS: 0H55J, 1H55J, 1J20C, 2J20C01/22/04
>>>
>>>
>>>
>>> from time to time,