> Kenneth Albanowski wrote:
> > I'm working with uClinux, which fits quite well in less then 512kB of ROM,
>
> Hmm, that's text+data+bss of a recent 2.1 kernel ?
No! Sorry, that's text+data of a semi-recent 2.0 kernel. 2.1 is in theory
portable to the uC branch, but I've not worked on it yet. And bss doesn't
need to go in the image, of course. If you can run the kernel out of ROM,
you only need RAM for data+bss.
> Interesting ... I've tried to build a "null" 2.1.125 kernel (no file
> systems, no networking, no devices, no executable formats, etc.) for the
> ARM, and I still got a fairly huge thing:
>
> text data bss dec hex filename
> 312836 27636 93324 433796 69e84 vmlinux
>
> Seems that your 68k code is much more dense than my ARM code.
Hmm, seems a bit large (given that I've got a smaller image with ext2,
networking, several device drivers, a simple binary format, etc.), but
that is 68k code, and very likely is denser.
> > I find this very interesting, from an eclectic viewpoint.
>
> ;-) I've abandoned that idea by now ... it's just too messy. The way to
> insert the gaps would have had to be something like this:
>
> - obtain the sections and their sizes from all modules (plus alignment
> constraints, etc.)
> - calculate the right set of modules to use, while preserving the
> original sequence of sections (e.g. we want head* at the beginning :-)
> - create a linker script with the appropriate output sections
Ye gods... Yes, you're right, that'll work, at the cost of skipping the
end of the 512K chunks -- or at the cost of time to solve the knapsack
problem for each segment to find the optimal packing. :-)
> Ah no, they see perfect virtual memory anyway. The idea was simply to
> avoid using virtual memory for the kernel too.
Gotcha. My feeling is that it would be, but then again I've been working
without an MMU, and a completely flat memory layout. Note that if you
don't flatten out kernel memory, I'm not sure how well the normal
allocators are going to work.
> Then there's another problem, of course: the size of the kernel's memory
> map is proportional to end_mem-start_mem, so if I pretend to have a few
> MB worth of RAM between start_mem and end_mem, it'll quickly grow to a
> few hundreds of kilobytes.
<shrug> It'll be double, but I've never felt it was worth worrying about.
And you'll probably have more memory to waste then I do.
> > See if you can ditch initrd: if you can boot off a ROM disk,
>
> The use of ROM shouldn't be required, although you probably have to use
> some CompactFlash (unless you want to run the Psion with NFS over PPP ;-)
> The 6 MB ROM in the machine is forbidden territory before we're really
> really, I mean *really* sure that Linux is stable on that box. Even then,
> changing/replacing the internal ROMs may be technically unattractive.
_Oh_. Right, of course. Again, I'm used to being able to swap out or
rewrite the ROMs, one way or another. Everything is different if you only
can run from RAM.
And I don't even want to think about running from CompactFlash. Better
just to write an hd driver them.
> But with nice linear VM for the kernel, initrd should be trivial to use.
> Famous last words, I know :-)
Aside from initrd's general nastyness (hooks all over the place, at least
in 2.0.x), yes, it should be much easier to work with.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/