All of lore.kernel.org
 help / color / mirror / Atom feed
From: gerg@snapgear.com (Greg Ungerer)
To: linux-arm-kernel@lists.infradead.org
Subject: [uClinux-dev] Running linux with mmu disabled on arm (AT91).
Date: Tue, 8 May 2012 14:50:06 +1000	[thread overview]
Message-ID: <4FA8A5FE.3080709@snapgear.com> (raw)
In-Reply-To: <4FA00040.8000207@fnac.net>

Hi Paul,

On 02/05/12 01:24, Paul Chavent wrote:
> I'd like to try linux on an AT91SAM9G20 (i have a linuxstamp board), with MMU disabled (the Hyok-Sung Choi&  Hee-Chul Yun paper demonstrate that it could be possible).
>
> All the code seems to be present in the kernel...
> So i would like to share my experience.
>
> (1) I had to make two little changes in the kernel code :
>       - I'm not able to change the REMAP_VECTOR_TO_DRAM. I have submitted the problem to the kbuild mailing list (http://www.spinics.net/lists/linux-kbuild/msg06153.html).

Odd. Is it because DRAM_BASE is a numerical value?


>       - The soc_detect code that init the at91_soc_initdata structure is never called. Later this structure is used unitialized.
>       I'm currently using the joined patch as a workaround. Someone can review it please ?

It looks ok to me.


> (2) I used to run the module with a "classic system" based on linux + eglibc, and i needed only one toolchain (arm-xxx-linux-gnueabi) for the kernel and the userspace apps.
>       I found that for the nommu case i wasn't able to build the kernel with the userspace toolchain.
>       So I had to build 2 toolchain, based on binutils 2.22, gcc 4.7, uclibc 0.9.33.1 and linux 3.2.14 :
>         - an arm-xxx-eabi toolchain for the kernel
>         - an arm-xxx-uclinux-uclibceabi for the userspace apps
>       Do you confirm that it is not possible to compile the kernel with arm-xxx-uclinux-uclibceabi ? Or, may i have misconfigured the toolchain (i join the toolchain build procedure) ?

I build non-mmu ARM systems with the same toolchain. What was the failure condition
when building the kernel with the arm-yyy-uclinux-uclibceabi tool chain?


> (3) The arm-xxx-uclinux-uclibceabi with elf2flt seems to produce running bins only if it is build with the uClibc DOPIC not set.
>       Is it required to disable DOPIC ?
>       Moreover, i can't run bins produced with a arm-xxx-linux-uclibceabi toolchain and -Wl,-elf2flt (not uclinux one). Is it the expected behavior ?

Is it actually producing a FLAT format binary?
Maybe it is silently ignoring the "-Wl,-elf2flt".


> (4) The elf2flt needs to be updated to be aware of the exidx section, and some reloc types. I join the patch i currently use.

You shouldn't include a whole new elft2flt.ld for this. It is generated
(via autoconf) from the elf2flt.ld.in file. You should add your new
exidx section to that. If you want to generate a new patch with doing
it that way I can add it to the elf2flt CVS on uclinux.org.


> Given these observations, i've been able to run a linux with an hello world as the /init process.
>
> My next tests will be to run threaded programs, c++ programs, then busybox.

A good start at least.

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

  reply	other threads:[~2012-05-08  4:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-01 15:24 [Buildroot] Running linux with mmu disabled on arm (AT91) Paul Chavent
2012-05-01 15:24 ` Paul Chavent
2012-05-08  4:50 ` Greg Ungerer [this message]
2012-05-08  9:11   ` [uClinux-dev] " Paul Chavent
2012-05-08 12:01     ` Greg Ungerer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA8A5FE.3080709@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.