: linux-2.5.30uc0 MMU-less patches
PATCH 1/1 : linux-2.5.30uc0 MMU-less patches
Hi All,
I have a new set of uClinux (MMU-less) patches for 2.5.30 at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
I have coded a generic MTD map driver to replace the old crufty blkmem driver. The blkmem driver will be going away in future patches.
Other than that it is still all working nicely.
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: www.snapgear.com
Quoted 3 lines · Greg Ungerer
I have a new set of uClinux (MMU-less) patches for 2.5.30 at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
One thing really puzzles me.
Why is there SGI VisWS, X86-foo, ACPI and god-knows-what-else in arch/m68knommu/config.in ?
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Hi Dave,
Quoted 8 lines · Dave Jones
Quoted 3 lines · Greg Ungerer
I have a new set of uClinux (MMU-less) patches for 2.5.30 at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/One thing really puzzles me.
Why is there SGI VisWS, X86-foo, ACPI and god-knows-what-else inarch/m68knommu/config.in?
Yep, there sure is some crap in there :-)
Obviously left over from the original copy out
from arch/i386/config.in.
I have cleaned all that silly stuff out for the
next patch.
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: www.snapgear.com
Quoted 6 lines · gerg
Yep, there sure is some crap in there :-)
Obviously left over from the original copy out
fromarch/i386/config.in.I have cleaned all that silly stuff out for the
next patch.
With the silly nits like that aside, it leaves just the more serious 'issues' such as those brought up by Willy earlier.
The whole idea of a seperate mmnommu (or was it nommumm/ ?) directory seemed a bit odd-looking too. (Asides from the horrible name) I didn't check the code in detail, but is there really that little that can be shared between the regular mm/ ?
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Hi Dave,
Quoted 8 lines · Dave Jones
Quoted 6 lines · gerg
Yep, there sure is some crap in there :-)
Obviously left over from the original copy out
fromarch/i386/config.in.I have cleaned all that silly stuff out for the
next patch.
Quoted 7 lines
With the silly nits like that aside, it leaves just the more serious 'issues' such as those brought up by Willy earlier.
The whole idea of a seperate mmnommu (or was it nommumm/ ?) directory seemed a bit odd-looking too. (Asides from the horrible name)
It surely is a horrible name :-)
Quoted 3 lines
I didn't check the code in detail, but
is there really that little that can be shared between the regularmm/?
No, there is actually a lot in common. Probably something like 70%. This is really a question of organization.
I would much prefer to see the non-mmu support in with mm. But it would mean a few #ifdef's in there to allow for the differences.
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: www.snapgear.com
Quoted 5 lines · gerg
Quoted 3 lines
I didn't check the code in detail, but
is there really that little that can be shared between the regularmm/?No, there is actually a lot in common. Probably something like 70%. This is really a question of organization.
That's what I guessed on just a cursory glance at the patch.
Quoted 3 lines
I would much prefer to see the non-mmu support in with mm. But it would mean a few #ifdef's in there to allow for the differences.
Versus massive code duplication, I think the ifdef's would be a better approach, especially if you can hide them away in headers.
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 2 lines · [email protected] said:
I have coded a generic MTD map driver to replace the old crufty
blkmem driver. The blkmem driver will be going away in future patches.
--- linux-2.5.30/drivers/mtd/maps/snapgear-uc.c Thu Jan 1 10:00:00 1970
+++ linux-2.5.30uc0/drivers/mtd/maps/snapgear-uc.c Mon Jul 15 21:29:25 2002
+#ifdef CONFIG_NFTL
+#include <linux/mtd/nftl.h>
+#endif
You shouldn't need that.
+int flash_eraseconfig(void)
+{
This will cause an oops if it gets woken by a signal -- you leave and the the 'struct erase_info' on your stack frame, which you passed to the asynchronous erase call, goes bye bye.
+ ROOT_DEV = MKDEV(NFTL_MAJOR, 1);
Oh, I see -- if we fail to find a file system we recognise on the NOR flash, try booting from DiskOnChip. Does this really live here?
--- linux-2.5.30/drivers/mtd/mtdblock.c Fri Aug 2 15:15:41 2002
+++ linux-2.5.30uc0/drivers/mtd/mtdblock.c Fri Aug 2 16:00:13 2002
- if (req->flags & REQ_CMD)
+ if (! (req->flags & REQ_CMD))
Yes.
+#ifdef MAGIC_ROM_PTR
+static int
+mtdblock_romptr(kdev_t dev, struct vm_area_struct * vma)
No, although the fix I'm happy with is going to take a while to get implemented so maybe in the short term. This is likely to get rejected on other grounds anyway; perhaps separate it and don't submit it for inclusion just now?
--
dwmw2
Hi David,
Quoted 4 lines · David Woodhouse
Quoted 2 lines · [email protected] said:
I have coded a generic MTD map driver to replace the old crufty blkmem driver. The blkmem driver will be going away in future patches.
Did you have a look at uclinux.c, that is the one I was referring to here?
Quoted 7 lines
drivers/mtd/maps/snapgear-uc.c +3
-0+#ifdef CONFIG_NFTL +#include <linux/mtd/nftl.h> +#endif You shouldn't need that.
There is one board setup supported by this that uses DiskOnChip (the CONFIG_SH_SECUREEDGE5410 define). But your probably right, it wouldn't need nftl.h.
Quoted 4 lines
drivers/mtd/maps/snapgear-uc.c +2
-0+int flash_eraseconfig (void ) +{This will cause an oops if it gets woken by a signal -- you leave and the the 'struct
erase_info' on your stack frame, which you passed to the asynchronous erase call, goes bye bye.
OK, I'll get that fixed.
Quoted 3 lines
drivers/mtd/maps/snapgear-uc.c +1
-0+ROOT_DEV =MKDEV (NFTL_MAJOR ,1 );Oh, I see -- if we fail to find a file system we recognise on the NOR flash, try booting from DiskOnChip. Does this really live here?
Well, it actually support for a completely different board - it doesn't have NOR flash at all.
This code supports a wide variety of boards, with mixtures of NOR flash and/or DiskOnChip.
Quoted 11 lines
drivers/mtd/mtdblock.c +1
-1-if (req->flags &REQ_CMD ) +if (! (req->flags &REQ_CMD ))Yes.
drivers/mtd/mtdblock.c +3
-0+#ifdef MAGIC_ROM_PTR +static int +mtdblock_romptr (kdev_t dev,struct vm_area_struct * vma)
Quoted 1 line
No, although the fix I'm happy with is going to take a while to get implemented so maybe in the short term. This is likely to get rejected on other grounds anyway; perhaps separate it and don't submit it for inclusion just now?
Sounds good to me. The most important is the uclinux.c support. Since that means I can get rid of the blkmem driver all together from the uClinux patches.
Thanks
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: www.snapgear.com
Quoted 2 lines · [email protected] said:
Did you have a look at
uclinux.c, that is the one I was referring to
here?
I remember it being there, don't remember objecting to anything in it ;)
--
dwmw2
Hi David,
Quoted 7 lines · David Woodhouse
Quoted 2 lines · [email protected] said:
Did you have a look at
uclinux.c, that is the one I was referring to here?I remember it being there, don't remember objecting to anything in it ;)
Must be alright then :-)
It is pretty simple, almost trivial.
I am just about to put up a new patch set that removes all the MAGIC_ROM_POINTER stuff from the MTD code (amongst many other clean ups). The MTD patches within it are pretty clean now.
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: www.snapgear.com