I'd say you're dreaming. The main problem will be the limited RAM.
In 2004, Eric Beiderman managed to get a kernel booting with 2.5MB of RAM, with a lot of functionality removed.
However, that was on x86, and you're talking about ARM. So I tried to build the smallest possible ARM kernel, for the 'versatile' platform (one of the simplest). I turned off all configurable options, including the ones that you're looking for (USB, WiFi, SPI, I2C), to see how small it would get. Now, I'm just referring to the kernel here, and this does not include any userspace components.
The good news: it will fit in your flash. The resulting zImage is 383204 bytes.
The bad news: with 256kB of RAM, it won't be able to boot:
$ size obj/vmlinux
text data bss dec hex filename
734580 51360 14944 800884 c3874 obj/vmlinux
The .text segment is bigger than your available RAM, so the kernel can't decompress, let alone allocate memory to boot, let alone run anything useful.
One workaround would be to use the execute-in-place support (CONFIG_XIP), if your system supports that (ie, it can fetch instructions directly from Flash). However, that means your kernel needs to fit uncompressed in flash, and 734kB > 700kB. Also, the .data and .bss sections total 66kB, leaving abut 190kB for everything else (ie, all dynamically-allocated data structures in the kernel).
That's just the kernel. Without the drivers you need, or any userspace.
So, yes, you're going to need a bit more RAM.
Porting the driver manually is the only way to go about it if you're unwilling to write the driver from scratch. @jeremy-kerr's right, you have license issues to be careful about, but essentially what this will mean if the driver is GPL is that your ported driver will also be GPL. You won't have to open up you're entire RTOS source code.
Three months is probably a conservative estimate for the porting effort; if you can identify the APIs used (network, interrupt, timers, waiting/locking, I/O, callback, file operation, etc.) and create a rough-and-ready map between the Linux API used and what is available on your RTOS it will make the process go MUCH more quickly, especially since you can then start to stub out the Linux API call used and "translate" it to the API and data structures used on your RTOS.
It won't be a simple task, but it's certainly doable and if the Linux driver is written well then you will have a very good idea of what each part does and why, which always makes porting easier. Good luck!
Best Answer
I am not sure what you are asking about but,
There is something interesting with your assignment:
First of all, porting a linux kernel is not an easy task !
You have two choices. Either the platform you choose is supported already and you can use it or it is not. And when I say platform I mean the whole board, not just the model of MCU. Each board may have different RAM chip & FLASH chip, use different IO assignments, clock tree, etc. All these things are pretty low level in the kernel (or in the bootloader) and would require a lot of effort to port (and to test). When I say a lot, I mean months if you are familiar with this, or maybe years if not...
I am not aware of standard Linux kernel port for Cortex-M. IFAIK the lack of MMU in Cortex-M devices is a NO-GO for a std linux kernel. You may use uClinux instead. But is it still Linux ? You would have to answer this.
This is also why you can't use a common linux distribution: Your platform won't be a PC. The RAM you will have might reach 512MB, not 4GB. Thing about a Raspberry Pi board. No standard Linux for it, but some custom distribution made specifically for it. In fact a Raspberry Pi might be OK for you here. All the system is ready, and you could focus on writing an I2C driver for your accelerometer.
Then you are talking about RTOS. First, Linux is not a real-time OS. Real-time may be added to the standard kernel (Xenomai for instance) but I am not sure why you are talking about real-time OSs here.
You also said that one option was to go with FreeRTOS. But this would violate your requirement to use a Linux kernel. And if the goal of the whole project is to learn device driver development. Using FreeRTOS or Linux is completely different in term of driver coding.
Anyway, using FreeFTOS seems a sound idea here. It comes with a lot of supported platforms including examples. It is quite easy to use (at least an order of magnitude (or maybe two) easier than porting a Linux kernel). It is real-time, this might be a requirement, depending what you plan to do with your accelerometer data. Last but not least, you may not need external RAM or FLASH. It is lightweight enough to fit into the internal memory of your MCU. A Cortex-M is fine here.
* EDIT *
I read in the history of your question that you initially said that it is supposed to be a 1 month project.
Thus you don't have the choice anymore and have basically two options:
Go for a well known embedded Linux platform that is alread up and running, such as the Raspberry Pi. And dive into Linux kernel diver development right away.
Go for a platform already supported with an I2C example of FreeRTOS. You may download FreeRTOS and look into the example folder. Find a board that has an I2C example attached to it and use that board.
I am not aware of your cost requirement for your project, but a sound dev-board might cost hundreds of dollars and may require a programmer or a development environment that may or may not be free, when a Pi is ~50$ and requires nothing.