Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

["Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

Hi Arnd,

On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
> On Thursday 26 September 2013, Uwe Kleine-König wrote:
> > I made that work now and can prepare a patch. I had to drop "depends on
> > !ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
> > works with XIP_KERNEL as it only has 4 MiB of RAM.
> 
> Ok, cool. We might run into a few problems with 'make randconfig' and
> 'make allyesconfig' when it becomes possible to enable XIP_KERNEL then.
> IIRC, there is no fundamental reason to disallow XIP_KERNEL with
> ARCH_MULTIPLATFORM, but I added the dependency because it causes
> build errors in combination with other options.
ah, OK. Do you have an idea to fix both?
 
> A few questions from my side, out of curiosity:
> 
> * Do you need any other patches (unrelated to EFM32) to run NOMMU on a
> recent kernel? When I last tried, I could not get any NOMMU build to work
> at all.
no, there isn't much needed on top of current mainline. My current wip is at

	git://git.pengutronix.de/git/ukl/linux.git efm32

I don't even rely on all the HACK-patches that are included there. (The
multi-arch stuff isn't there yet.)
 
> * Do you think 4MB is now a strict lower bound for running a modern
> kernel? It would be a good data point if we could show that any target
> with less than that is by definition broken and could get removed
> from the kernel. What is the size of your kernel and user space?
$ objdump -p vmlinux

vmlinux:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000000 vaddr 0x88020000 paddr 0x88020000 align 2**15
         filesz 0x00000094 memsz 0x0000a9f4 flags rw-
    LOAD off    0x00008000 vaddr 0x8c000000 paddr 0x8c000000 align 2**15
         filesz 0x001679b0 memsz 0x001679b0 flags rwx
    LOAD off    0x00170000 vaddr 0x88008000 paddr 0x8c1679b0 align 2**15
         filesz 0x00018d2c memsz 0x00018d2c flags rw-
private flags = 5000002: [Version5 EABI] [has entry point]

my rootfs (busybox, no init) is 153600 bytes big.

After booting I get:

	/ # free
		     total         used         free       shared      buffers
	Mem:          3892         1428         2464            0            0
	-/+ buffers:               1428         2464

but it doesn't run anything but a busybox shell ATM. Assuming the next
smaller configuration is 2 MiB of RAM I'd say that machine can maybe
boot, but cannot do anything sensible after that.

> * What user space are you running? Anything that's easy to build
> for testing? Should that run with a mach-virt kernel built for
> ARMv7-A NOMMU?
There is a BSP publically available at

	http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary

which also includes a README file. For troubleshooting /join #efm32 on
freenode.
 
> * An ARMv7-M kernel cannot run on either ARMv4/v5 nor ARMv6/v7-A, right?
The entry convention is different (ARMv7-M doesn't support the ARM
instruction set but you need to jump into the kernel in ARM mode for
v4-v7). Other that that I don't know if there is a problem. Maybe
Jonathan can say anything here? Or alternatively if you want an efm32
devboard, just tell me.

> Do you prevent building such a kernel in Kconfig?
I'm sure my Kconfig magic isn't waterproof. It took me a few tries to
expand the multiarch architecture selection to make v7-m selectable at
all.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html