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: http://www.snapgear.com
On Fri, Aug 02, 2002 at 04:34:38PM +1000, Greg Ungerer wrote:
> 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
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
[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 Dave,
Dave Jones wrote:
> On Fri, Aug 02, 2002 at 04:34:38PM +1000, Greg Ungerer wrote:
> > 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 ?
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: http://www.snapgear.com
On Sat, Aug 03, 2002 at 01:29:55AM +1000, gerg wrote:
> 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.
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
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Hi Dave,
Dave Jones wrote:
> On Sat, Aug 03, 2002 at 01:29:55AM +1000, gerg wrote:
> > 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.
>
> 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 :-)
> I didn't check the code in detail, but
> is there really that little that can be shared between
> the regular mm/ ?
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: http://www.snapgear.com
Hi David,
David Woodhouse wrote:
> [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?
> --- 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.
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.
> +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.
> + 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.
> --- 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?
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: http://www.snapgear.com
On Sat, Aug 03, 2002 at 01:54:26AM +1000, gerg wrote:
> > I didn't check the code in detail, but
> > is there really that little that can be shared between
> > the regular mm/ ?
> 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.
> 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
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
[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,
David Woodhouse wrote:
> [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: http://www.snapgear.com