Hi All,
An updated uClinux patch is available at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1.patch.gz
Changelog:
1. v850 update
2. cleaned up mm/page_alloc.c
Smaller specific patches:
. FEC ColdFire 5272 ethernet driver
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-fec.patch.gz
. m68k/ColdFire/v850 serial drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-serial.patch.gz
. 68328 frame buffer
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-fb.patch.gz
. binfmt_flat loader
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-binflat.patch.gz
. m68knommu architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-m68knommu.patch.gz
. v850 architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-v850.patch.gz
. mm (MMU-less) only patch
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-mm.patch.gz
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Wed, Oct 16, 2002 at 01:25:49AM +1000, Greg Ungerer wrote:
> Hi All,
>
> An updated uClinux patch is available at:
>
> http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1.patch.gz
>
> Changelog:
>
> 1. v850 update
There are a bunch of CVS .#* files left from this one.
v850_defs.h wants updating to the generic generate-asm-offsets.h
mechanism (check the toplevel Makefile)
Please stop the ugly symlink hell with the linker scripts -
we have vmlinux.lds.S for that.
it should read something like:
#include <linux/config.h>
#ifdef BOARD1
#include "board1.lds"
#else
...
#endif
for v850
Could you please explain the rootfs hacks in v850?
I don't think we want those in mainline but rather generic
initrd/initramfs.
Also please remove arch/v850/sim/* - that stuff doesn't
belong into the kernel tree.
> 2. cleaned up mm/page_alloc.c
Why do you put set_page_refs into a header? Separating it out
looks good to me, but IMHO it should stay in page_alloc.c.
BTW, are you sure that you don't need to set the refs in the
other caller of prep_new_page? To me it looks like you should
and then you could merge it into prep_new_page.
Also, what is CONFIG_CONTIGUOUS_PAGE_ALLOC doing? It seems not
fully implemented but adds lots of uglieness :)
CONFIG_NO_MMU_LARGE_ALLOCS might want a saner name, btw
(CONFIG_LARGE_ALLOCS?).
General commets:
- Config.in files have three-space, not two-space indentation
- I don't think you want to keep around the old binfmt_flat
format when merghin into mainline
- MAX_SHARED_LIBS is never used
Hi Miles,
Miles Bader wrote:
> Here's a v850 update for 2.5.42uc1.
I have rolled this into, linux-2.5.43uc0.
I have also removed the gdb patches under arch/v850.
> I addressed two of Christoph Hellwig's concerns, (1) vmlinux.lds.S
> [barf] and (2) the asm-constant generation mechanism.
>
> He also complained about using the MD driver &c instead of initrd, but
> I'm not sure what do about that -- it'd be nice to use a `standard'
> solution, but when I originally looked at the initrd stuff, it seemed
> very convoluted and confusing; since earlier lkml discussion had pointed
> to using MD as the nearest thing to the old blkmem device, that seemed
> like the way to go.
I very much like using a specific MTD map driver. I haven't carried
my initrd patches through to the 2.5 code yet. But it was pretty
simple to do for 2.4...
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
Hi Christoph,
Christoph Hellwig wrote:
> There are a bunch of CVS .#* files left from this one.
Cleaned out now.
> v850_defs.h wants updating to the generic generate-asm-offsets.h
> mechanism (check the toplevel Makefile)
Miles cleaned this up.
> Please stop the ugly symlink hell with the linker scripts -
> we have vmlinux.lds.S for that.
Hmph. Hardly seems any better...
> Could you please explain the rootfs hacks in v850?
> I don't think we want those in mainline but rather generic
> initrd/initramfs.
>
> Also please remove arch/v850/sim/* - that stuff doesn't
> belong into the kernel tree.
Done.
>>2. cleaned up mm/page_alloc.c
>
> Why do you put set_page_refs into a header?
It looked might it might be usefull elsewhere.
(but currently isn't used for anything else).
> Separating it out
> looks good to me, but IMHO it should stay in page_alloc.c.
> BTW, are you sure that you don't need to set the refs in the
> other caller of prep_new_page? To me it looks like you should
> and then you could merge it into prep_new_page.
No, you don't want that.
> Also, what is CONFIG_CONTIGUOUS_PAGE_ALLOC doing? It seems not
> fully implemented but adds lots of uglieness :)
It was a second allocator that more cleverly allocated large
memory chunks - not using the power of 2 allocator. I have
not carried this into the 2.5 patches. Very nice to have,
since you suffer much more from memory fragmentation without
VM. But not strictly neccessary, and to minimize and simplify
the current patch sets I left it out.
Cleanup out all references to it now.
> CONFIG_NO_MMU_LARGE_ALLOCS might want a saner name, btw
> (CONFIG_LARGE_ALLOCS?).
Yes, no doubt the NO_MMU name is universally disliked :-)
Changed to COFNIG_LARGE_ALLOCS now.
>
> General commets:
> - Config.in files have three-space, not two-space indentation
Fixed.
> - I don't think you want to keep around the old binfmt_flat
This isn't old. It is the primary format used on uClinux. ELF
and a.out are not practical, since you would need to do the final
link/locate on them at exec load time (you won't know what address
in memory they will get loaded to until them). You don have the
VM luxary of just locating it at a fixed address at compile time.
FLAT format is a light weight, mostly architecture independant
way to carry around relocs, and to keep the program binaries
small.
> format when merghin into mainline
> - MAX_SHARED_LIBS is never used
Another "feature" I have not carried into 2.5. Removed.
Thanks
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
> This isn't old. It is the primary format used on uClinux. ELF
> and a.out are not practical, since you would need to do the final
> link/locate on them at exec load time (you won't know what address
> in memory they will get loaded to until them). You don have the
> VM luxary of just locating it at a fixed address at compile time.
>
> FLAT format is a light weight, mostly architecture independant
> way to carry around relocs, and to keep the program binaries
> small.
I don't meant binfmt_flat itself but the support for the old-style relocs
that is still in the code.
BTW, does binfmt_flat for for any non-uClinux port?
Christoph Hellwig wrote:
>>This isn't old. It is the primary format used on uClinux. ELF
>>and a.out are not practical, since you would need to do the final
>>link/locate on them at exec load time (you won't know what address
>>in memory they will get loaded to until them). You don have the
>>VM luxary of just locating it at a fixed address at compile time.
>>
>>FLAT format is a light weight, mostly architecture independant
>>way to carry around relocs, and to keep the program binaries
>>small.
>>
>
> I don't meant binfmt_flat itself but the support for the old-style relocs
> that is still in the code.
OK, I'll have a look at that.
> BTW, does binfmt_flat for for any non-uClinux port?
Don't beleive so.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Tue, 2002-11-26 at 07:49, Miles Bader wrote:
> Hi,
>
> This patch adds more stuff to include/linux/elf.h for the v850 (used by
> the new module loader).
To save cluttering a linux/*.h file couldnt the module loader for v850
include an asm/*.h file holding the extra info ?
Alan Cox <[email protected]> writes:
> > This patch adds more stuff to include/linux/elf.h for the v850 (used by
> > the new module loader).
>
> To save cluttering a linux/*.h file couldnt the module loader for v850
> include an asm/*.h file holding the extra info ?
I suppose so, but the v850 is not exceptional in this regard.
The various relocation type constants (R_...) in elf.h are completely
unused in the kernel on _every_ architecture, except by the new module
loader.
If tidying is needed, then it seems like the best thing would be to move
all the arch-specific stuff into the corresponding <asm/elf.h> file for
each architecture. I presume the reason this hasn't been done is simply
convention -- userland elf.h files are also giant conglomerations of
defines for every supported architecture ...
-Miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page
On Wed, 2002-11-27 at 01:19, Miles Bader wrote:
> If tidying is needed, then it seems like the best thing would be to move
> all the arch-specific stuff into the corresponding <asm/elf.h> file for
> each architecture. I presume the reason this hasn't been done is simply
> convention -- userland elf.h files are also giant conglomerations of
> defines for every supported architecture ...
I agree entirely. So lets start with v850 8)
Alan Cox <[email protected]> writes:
> > If tidying is needed, then it seems like the best thing would be to move
> > all the arch-specific stuff into the corresponding <asm/elf.h> file for
> > each architecture.
>
> I agree entirely. So lets start with v850 8)
Okay. I sent the previous patch to Linus and he doesn't seem to have
taken it; perhaps your suggestion will fare better.
I'd like to remain consistent with other archs though -- does anyone
want to make a patch (I guess just move all the R_... constants) for them?
-Miles
--
Yo mama's so fat when she gets on an elevator it HAS to go down.