Ramdisk image on flash.

Ramdisk image on flash.

[Krishnakumar. R]

Hi,

Is there any way that I can keep 
a ramdisk image (containing the root filesystem)
in a flash device and boot to it.


The ramdisk should be separate from the
kernel image.


Thanks in advance
Regards
KK

Re: Ramdisk image on flash.

[Pete Popov]

On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
> Hi,
> 
> Is there any way that I can keep 
> a ramdisk image (containing the root filesystem)
> in a flash device and boot to it.

Yes, and other architectures have support for passing arguments to the
kernel that tell it where the ramdisk is. I don't know that we've done
that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
this list is already working on it (I think someone actually is working
on it and was preparing a patch for Ralf).

> The ramdisk should be separate from the kernel image.

Pete

Re: Ramdisk image on flash.

[Tibor Polgar]

Pete Popov wrote:
> 
> On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
> > Hi,
> >
> > Is there any way that I can keep
> > a ramdisk image (containing the root filesystem)
> > in a flash device and boot to it.
> 
> Yes, and other architectures have support for passing arguments to the
> kernel that tell it where the ramdisk is. I don't know that we've done
> that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
> this list is already working on it (I think someone actually is working
> on it and was preparing a patch for Ralf).

For having separate initrd and kernel load we also need an aware bootloader
that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
i386 specific.    The Yamon i've patched "COULD" be made to do it.   

> 
> > The ramdisk should be separate from the kernel image.

How is this currently done in non-mips archs?   I know lilo and Druid can do
this with a configuration file and hard sector addressing into a filesystem,
but i never understood how they avoid/get around file fragmentation issues.

Tibor

Re: Ramdisk image on flash.

[Mark Salter]

>>>>> Tibor Polgar writes:

> Pete Popov wrote:
>> 
>> On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
>> > Hi,
>> >
>> > Is there any way that I can keep
>> > a ramdisk image (containing the root filesystem)
>> > in a flash device and boot to it.
>> 
>> Yes, and other architectures have support for passing arguments to the
>> kernel that tell it where the ramdisk is. I don't know that we've done
>> that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
>> this list is already working on it (I think someone actually is working
>> on it and was preparing a patch for Ralf).

> For having separate initrd and kernel load we also need an aware bootloader
> that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
> i386 specific.

Not at all. RedBoot can be used to pass a command line to MIPS kernels. It
would be simple to add the passing of a ramdisk address. It already supports
ramdisks from ARM and SH kernels.

--Mark

Re: Ramdisk image on flash.

[Tibor Polgar]

> >> On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
> >> > Hi,
> >> >
> >> > Is there any way that I can keep
> >> > a ramdisk image (containing the root filesystem)
> >> > in a flash device and boot to it.
> >>
> >> Yes, and other architectures have support for passing arguments to the
> >> kernel that tell it where the ramdisk is. I don't know that we've done
> >> that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
> >> this list is already working on it (I think someone actually is working
> >> on it and was preparing a patch for Ralf).
> 
> > For having separate initrd and kernel load we also need an aware bootloader
> > that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
> > i386 specific.
> 
> Not at all. RedBoot can be used to pass a command line to MIPS kernels. It
> would be simple to add the passing of a ramdisk address. It already supports
> ramdisks from ARM and SH kernels.

The original poster wanted a setup where the initrd was NOT part of the
kernel, which begs the question of how/where it would be put into flash so
something could load/uncompress it.   I'd love to have a way to decouple the
two so i wouldn't have to recompile the kernel when i change the root image,
but still not waste any space in flash.   I guess they could be written one
after the other and the loader is just given a "load map" of where each one
resides.   Would this satisfy Krishnakumar's requirements?

Tibor

Re: Ramdisk image on flash.

[Mark Salter]

>>>>> Tibor Polgar writes:

>> >> On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
>> >> > Hi,
>> >> >
>> >> > Is there any way that I can keep
>> >> > a ramdisk image (containing the root filesystem)
>> >> > in a flash device and boot to it.
>> >>
>> >> Yes, and other architectures have support for passing arguments to the
>> >> kernel that tell it where the ramdisk is. I don't know that we've done
>> >> that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
>> >> this list is already working on it (I think someone actually is working
>> >> on it and was preparing a patch for Ralf).
>> 
>> > For having separate initrd and kernel load we also need an aware bootloader
>> > that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
>> > i386 specific.
>> 
>> Not at all. RedBoot can be used to pass a command line to MIPS kernels. It
>> would be simple to add the passing of a ramdisk address. It already supports
>> ramdisks from ARM and SH kernels.

> The original poster wanted a setup where the initrd was NOT part of the
> kernel, which begs the question of how/where it would be put into flash so
> something could load/uncompress it.   I'd love to have a way to decouple the
> two so i wouldn't have to recompile the kernel when i change the root image,
> but still not waste any space in flash.   I guess they could be written one
> after the other and the loader is just given a "load map" of where each one
> resides.   Would this satisfy Krishnakumar's requirements?

The ARM kernel separates the two and RedBoot handles that. There are a
number of approaches. Typically, RedBoot is used to store the separate
images in flash. You can then have a script that loads them into memory
and starts the kernel. You could have a script grab the two images off
of a tftp server. etc.

--Mark

Re: Ramdisk image on flash.

[Dan Malek]

Tibor Polgar wrote:

> The original poster wanted a setup where the initrd was NOT part of the
> kernel, which begs the question of how/where it would be put into flash so
> something could load/uncompress it. 

I regularly do this with compressed kernels (zImage) on PowerPC, ARM, and
Alchemy MIPS processors.  I attach the compressed ramdisk to the zImage,
usually with "cat" and some shell scripts.  The zImage uncompressor code
will relocate the ramdisk (and potentially ask for additional kernel
command line parameters) and will tell the kernel where the ramdisk is
located.  I don't have to recompile the kernel to do this, and best of
all it doesn't require any special boot rom knowledge of the image.  It
works with all boot roms that can load a binary image into a memory location
(not everyone uses RedBoot) :-)  Another advantage is exactly the same
image that you repeatedly test by loading over tftp or with a debugger
can be written into flash memory without modification.  It removes the
need to actually have to write to flash to test the image that will be
eventually written to flash.  You just jump to the start of the image to
uncompress/relocate/initialize/jump to kernel regardless of where it
is located.

When using ramdisks from flash, you must relocate them to RAM because the
kernel thinks it can add the pages used by the compressed ramdisk into the
free pool once the ramdisk is uncompressed into the file system cache.  The
uncompressor code I mentioned above will test the start address of the
image and copy it to ram if necessary.

There are a couple of things keeping me from making a patch for the MIPS
kernel.  This method is in conflict with the "compiled in" ramdisk method,
and reserving the "bootmem" pages to ensure the kernel doesn't allocate the
compressed ramdisk pages before they are freed doesn't work well compared
to other architectures.  I'm still running on luck with this latter problem,
but I think I can fix it.  I don't know yet what to do about the conflicts
and assumptions made about the compiled-in ramdisk.

Thanks.


	-- Dan

Re: Ramdisk image on flash.

[Jun Sun]

On Thu, Feb 20, 2003 at 03:35:15PM -0500, Dan Malek wrote:
> Tibor Polgar wrote:
> 
> > The original poster wanted a setup where the initrd was NOT part of the
> > kernel, which begs the question of how/where it would be put into flash so
> > something could load/uncompress it. 
> 
> I regularly do this with compressed kernels (zImage) on PowerPC, ARM, and
> Alchemy MIPS processors.  I attach the compressed ramdisk to the zImage,
> usually with "cat" and some shell scripts.  The zImage uncompressor code
> will relocate the ramdisk (and potentially ask for additional kernel
> command line parameters) and will tell the kernel where the ramdisk is
> located.  I don't have to recompile the kernel to do this, and best of
> all it doesn't require any special boot rom knowledge of the image.  It
> works with all boot roms that can load a binary image into a memory location
> (not everyone uses RedBoot) :-)  Another advantage is exactly the same
> image that you repeatedly test by loading over tftp or with a debugger
> can be written into flash memory without modification.  It removes the
> need to actually have to write to flash to test the image that will be
> eventually written to flash.  You just jump to the start of the image to
> uncompress/relocate/initialize/jump to kernel regardless of where it
> is located.
>

Looks like you have the solution that I called for. :-)
 
> 
> There are a couple of things keeping me from making a patch for the MIPS
> kernel.  This method is in conflict with the "compiled in" ramdisk method,
> and reserving the "bootmem" pages to ensure the kernel doesn't allocate the
> compressed ramdisk pages before they are freed doesn't work well compared
> to other architectures.  I'm still running on luck with this latter problem,
> but I think I can fix it.  I don't know yet what to do about the conflicts
> and assumptions made about the compiled-in ramdisk.
>

The compiled-in one uses a configure option.  Perhaps you can rely on that
to differentiate?  Once the new method get stable, I am in favor to 
covert all embedded ramdisk to the new one.

Jun

Re: Ramdisk image on flash.

[Pete Popov]

On Thu, 2003-02-20 at 12:44, Jun Sun wrote:
> On Thu, Feb 20, 2003 at 03:35:15PM -0500, Dan Malek wrote:
> > Tibor Polgar wrote:
> > 
> > > The original poster wanted a setup where the initrd was NOT part of the
> > > kernel, which begs the question of how/where it would be put into flash so
> > > something could load/uncompress it. 
> > 
> > I regularly do this with compressed kernels (zImage) on PowerPC, ARM, and
> > Alchemy MIPS processors.  I attach the compressed ramdisk to the zImage,
> > usually with "cat" and some shell scripts.  The zImage uncompressor code
> > will relocate the ramdisk (and potentially ask for additional kernel
> > command line parameters) and will tell the kernel where the ramdisk is
> > located.  I don't have to recompile the kernel to do this, and best of
> > all it doesn't require any special boot rom knowledge of the image.  It
> > works with all boot roms that can load a binary image into a memory location
> > (not everyone uses RedBoot) :-)  Another advantage is exactly the same
> > image that you repeatedly test by loading over tftp or with a debugger
> > can be written into flash memory without modification.  It removes the
> > need to actually have to write to flash to test the image that will be
> > eventually written to flash.  You just jump to the start of the image to
> > uncompress/relocate/initialize/jump to kernel regardless of where it
> > is located.
> >
> 
> Looks like you have the solution that I called for. :-)
>  
> > 
> > There are a couple of things keeping me from making a patch for the MIPS
> > kernel.  This method is in conflict with the "compiled in" ramdisk method,
> > and reserving the "bootmem" pages to ensure the kernel doesn't allocate the
> > compressed ramdisk pages before they are freed doesn't work well compared
> > to other architectures.  I'm still running on luck with this latter problem,
> > but I think I can fix it.  I don't know yet what to do about the conflicts
> > and assumptions made about the compiled-in ramdisk.
> >
> 
> The compiled-in one uses a configure option.  Perhaps you can rely on that
> to differentiate?  Once the new method get stable, I am in favor to 
> covert all embedded ramdisk to the new one.

Me too. Keep in mind too that there is no "standard" zImage support in
mips right now.  I'm not sure what Dan is using for the zImage support,
that but that's another patch that needs to make its way in the source
tree.  I added zImage support in the form of an arch/mips/zboot
directory and supporting files, but that never made it in linux-mips.org
because it added yet another copy of zlib (my argument was, so what, all
the other arches do it).

Pete

Re: Ramdisk image on flash.

[Dan Malek]

Pete Popov wrote:

> Me too. Keep in mind too that there is no "standard" zImage support in
> mips right now.  I'm not sure what Dan is using for the zImage support,

I took what you had started, copied lots of stuff from the same thing
I did for PowerPC a long time ago, and actually improved on that (I think) :-).
It seems every Alchemy processor I work with has a different boot rom,
so like PowerPC this gives us the ability to also format kernel calling
conventions in addition to zImage/initrd booting and flexibility.

> that but that's another patch that needs to make its way in the source
> tree.

I'll get it there :-)

> ....  I added zImage support in the form of an arch/mips/zboot
> directory and supporting files, but that never made it in linux-mips.org
> because it added yet another copy of zlib (my argument was, so what, all
> the other arches do it).

Yeah, I know about zlib.  I have "fixed" this more than once on PowerPC
to use the kernel zlib, but it still hasn't stuck in the source tree :-)
I'll try to get it right when I do a MIPS patch.

Thanks.


	-- Dan

Re: Ramdisk image on flash.

[Jun Sun]

On Thu, Feb 20, 2003 at 12:01:49PM -0800, Tibor Polgar wrote:
> > >> On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
> > >> > Hi,
> > >> >
> > >> > Is there any way that I can keep
> > >> > a ramdisk image (containing the root filesystem)
> > >> > in a flash device and boot to it.
> > >>
> > >> Yes, and other architectures have support for passing arguments to the
> > >> kernel that tell it where the ramdisk is. I don't know that we've done
> > >> that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
> > >> this list is already working on it (I think someone actually is working
> > >> on it and was preparing a patch for Ralf).
> > 
> > > For having separate initrd and kernel load we also need an aware bootloader
> > > that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
> > > i386 specific.
> > 
> > Not at all. RedBoot can be used to pass a command line to MIPS kernels. It
> > would be simple to add the passing of a ramdisk address. It already supports
> > ramdisks from ARM and SH kernels.
> 
> The original poster wanted a setup where the initrd was NOT part of the
> kernel, which begs the question of how/where it would be put into flash so
> something could load/uncompress it.   I'd love to have a way to decouple the
> two so i wouldn't have to recompile the kernel when i change the root image,
> but still not waste any space in flash.   I guess they could be written one
> after the other and the loader is just given a "load map" of where each one
> resides.   Would this satisfy Krishnakumar's requirements?
>

For the sanity of kernel, I also favor leaving ramfs root outside kernel.
It would be nice if we can do the following :

1) create kernel ELF as normal
2) outside the kernel, create .o file that is ramfs root
3) outside the kernel, we use a separate tool/program that combines
   1) and 2) into a new ELF file.  The entry point of the new ELF file
   would append ramfs parameters (such as "initrd=xxxx") to the args
   and then jump to kernel_entry.

There are some difficulties, but looks very possible.

Jun

Re: Ramdisk image on flash.

[Guido Guenther]

On Thu, Feb 20, 2003 at 12:37:32PM -0800, Jun Sun wrote:
> 1) create kernel ELF as normal
> 2) outside the kernel, create .o file that is ramfs root
> 3) outside the kernel, we use a separate tool/program that combines
>    1) and 2) into a new ELF file.  The entry point of the new ELF file
>    would append ramfs parameters (such as "initrd=xxxx") to the args
>    and then jump to kernel_entry.
This is basically what we do for IP22 in debian. We embed kernel and
initrd together with a small loader into one ELF executable. The prom
tftboots and starts the loader. The loader then moves the kernel to it's
loadaddres, puts the initrd to an appropriate address and jumps into
the kernel passing all the necessary args.
 -- Guido

Re: Ramdisk image on flash.

[Alan Cox]

On Thu, 2003-02-20 at 20:01, Tibor Polgar wrote:
> The original poster wanted a setup where the initrd was NOT part of the
> kernel, which begs the question of how/where it would be put into flash so
> something could load/uncompress it.   I'd love to have a way to decouple the
> two so i wouldn't have to recompile the kernel when i change the root image,
> but still not waste any space in flash.   I guess they could be written one
> after the other and the loader is just given a "load map" of where each one
> resides.   Would this satisfy Krishnakumar's requirements?

You probably also want them aligned to 256Kbyte after or similar so that you
can drop the initrd into a seperate erase block on the flash. There are
people doing this. Its actually not hard to hardwire an address into the
initrd code.

Red Boot knows how to do this nicely and it may be a good approach. It does
all the work for this on the ipaq for example.

You can also run some kernels out of flash, I've helped someone get the x86
kernels running from flash for example.

Re: Ramdisk image on flash.

[Pete Popov]

On Thu, 2003-02-20 at 11:30, Tibor Polgar wrote:
> Pete Popov wrote:
> > 
> > On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
> > > Hi,
> > >
> > > Is there any way that I can keep
> > > a ramdisk image (containing the root filesystem)
> > > in a flash device and boot to it.
> > 
> > Yes, and other architectures have support for passing arguments to the
> > kernel that tell it where the ramdisk is. I don't know that we've done
> > that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
> > this list is already working on it (I think someone actually is working
> > on it and was preparing a patch for Ralf).
> 
> For having separate initrd and kernel load we also need an aware bootloader
> that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
> i386 specific.    The Yamon i've patched "COULD" be made to do it.   

I haven't looked at how initrd support is really done in other arches. But I
think the kernel copies the initrd image from its original location to a
new location, so I don't see why the original location couldn't be in
flash.  You could just pass the physical address to the kernel, and have
the kernel load it from flash to ram. 
 
Pete

Re: Ramdisk image on flash.

[Brian Murphy]

Tibor Polgar wrote:

>Pete Popov wrote:
>  
>
>>On Wed, 2003-02-19 at 22:05, Krishnakumar. R wrote:
>>    
>>
>>>Hi,
>>>
>>>Is there any way that I can keep
>>>a ramdisk image (containing the root filesystem)
>>>in a flash device and boot to it.
>>>      
>>>
>>Yes, and other architectures have support for passing arguments to the
>>kernel that tell it where the ramdisk is. I don't know that we've done
>>that for MIPS, yet.  It wouldn't be too hard to do and maybe someone on
>>this list is already working on it (I think someone actually is working
>>on it and was preparing a patch for Ralf).
>>    
>>
>
>For having separate initrd and kernel load we also need an aware bootloader
>that knows where to find the ramdisk.   RedBoot, from what i read, seems to be
>i386 specific.    The Yamon i've patched "COULD" be made to do it.   
>  
>
RedBoot is very portable and not at all i386 specific. I just ported it 
to the LASAT
boards I support in the linux kernel - it took a few days. When you have 
ported it
you almost instantly have a really nice embedded operating system too. 
Perhaps
you were confusing it with GRUB?

How this helps with ramdisks I don't know :-).

/Brian

Re: Ramdisk image on flash.

[Guido Guenther]

On Thu, Feb 20, 2003 at 10:27:27AM -0800, Pete Popov wrote:
> Yes, and other architectures have support for passing arguments to the
> kernel that tell it where the ramdisk is. I don't know that we've done
We're using a patch for the debian kernels that allows to pass the
initrd's loadaddress and size on the kernel's command line. If this is of
some use I can send a patch.
 -- Guido

Re: Ramdisk image on flash.

[Dan Malek]

Guido Guenther wrote:

> We're using a patch for the debian kernels that allows to pass the
> initrd's loadaddress and size on the kernel's command line. If this is of
> some use I can send a patch.

Thanks.  I think that patch has been posted in the past because I am
using it in what I am doing.  I would actually like to pass this as
enviornment variables, since the command lines are getting quite long
in some cases and IMHO should really reflect general driver/kernel
options.


	-- Dan

Re: Ramdisk image on flash.

[Atsushi Nemoto]

>>>>> On Thu, 20 Feb 2003 11:35:09 +0530, "Krishnakumar. R" <krishnakumar@naturesoft.net> said:
krishnakumar> Is there any way that I can keep a ramdisk image
krishnakumar> (containing the root filesystem) in a flash device and
krishnakumar> boot to it.

If your flash device can be accessed as MTD block device, you can use
"root=/dev/mtdblockN load_ramdisk=1" (and also "ramdisk_start=N") boot
option to load your (compressed) ramdisk image from the flash device.

This method needs following patch (for 2.4.20).  Also, this method
does not need initrd support or bootloader support.

--- linux-2.4.20/init/do_mounts.c	Wed Dec 25 15:30:02 2002
+++ linux/init/do_mounts.c	Wed Dec 25 16:56:40 2002
@@ -883,6 +883,18 @@
 		}
 	} else if (is_floppy && rd_doload && rd_load_disk(0))
 		ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
+#if defined(CONFIG_MTD_BLOCK) || defined(CONFIG_MTD_BLOCK_RO)
+#ifndef MTD_BLOCK_MAJOR
+#define MTD_BLOCK_MAJOR 31
+#endif
+	else if (MAJOR(ROOT_DEV) == MTD_BLOCK_MAJOR && rd_doload) {
+#ifdef CONFIG_BLK_DEV_RAM
+		create_dev("/dev/ram", MKDEV(RAMDISK_MAJOR, 0), NULL);
+#endif
+		if (rd_load_image("/dev/root"))
+			ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
+	}
+#endif
 	mount_root();
 out:
 	sys_umount("/dev", 0);
---
Atsushi Nemoto

fixup_bigphys_addr and DBAu1500 dev board

[Jeff Baitis]

Gentlemen:

I've just received a DBAu1500 development board, along with a Texas Instruments
PCI1510 CardBus bridge PCI card.  As such, I believe that I'm interested in
addressing the full 36 bit physical address space on the board.

I've installed the cross-compiling toolchain from
{ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3}. mipsel-linux-gcc reports
version 2.96, mipsel-linux-ld reports 2.13.90.0.16. I have successfully built
other kernels with this toolchain for my board.

I checked out the latest linux_2_4 as of yesterday, copied the default
config for my board (cp arch/mips/defconfig-db1500), did 'make oldconfig',
and then 'make dep && make vmlinux'.

At the final linking of the kernel, here's what happened:

    mipsel-linux-ld -G 0 -static  -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o init/do_mounts.o \
            --start-group \
            arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o \
             drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pcmcia/pcmcia.o drivers/net/wireless/wireless_net.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o \
            net/network.o \
            arch/mips/lib/lib.a /home/baitisj/au_dev/mips_linux/linux/lib/lib.a arch/mips/au1000/db1x00/db1x00.o arch/mips/au1000/common/au1000.o \
            --end-group \
            -o vmlinux
    arch/mips/au1000/db1x00/db1x00.o(.text.init+0x160): In function `au1x00_setup':
    : undefined reference to `fixup_bigphys_addr'
    arch/mips/au1000/db1x00/db1x00.o(.text.init+0x164): In function `au1x00_setup':
    : undefined reference to `fixup_bigphys_addr'
    make: *** [vmlinux] Error 1


I took a look at arch/mips/au1000/db1x00/setup.c, and it appears that I'm
running into issues with:

    #if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_AU1500)
      extern phys_t (*fixup_bigphys_addr)(phys_t phys_addr, phys_t size);
    #endif

I recursively grepped through my kernel source and could find no other
references to 'fixup_bigphys_addr'.

I browsed the CVS log for setup.c, resulting in the following:

    Revision 1.1.2.2 / Mon Dec 16 18:00:48 2002 UTC (2 months ago) by ppopov
    Branch: linux_2_4
    Changes since 1.1.2.1: +30 -0 lines
    Diff to previous 1.1.2.1 to branchpoint 1.1

    - cleaned up dead code
    - updated the Db1x pci code to patch the Pb1500
    - renamed __ioremap_fixup to fixup_bigphys_addr to match a new
    36 bit address patch.


    Revision 1.1.2.1 / Wed Dec 11 06:12:29 2002 UTC (2 months, 1 week ago) by
                       ppopov
    Branch: linux_2_4
    Changes since 1.1: +212 -0 lines
    Diff to previous 1.1

    Alchemy Au1x updates:
    - better config options to separate CPU and boards specific options
    - Added support for the Db1x boards
    - fixed usbdev compile problems
    - update to Pb1500 pci code

My next move was to cvs up -D "one month ago" my kernel_2_4 source. I cleaned,
and repeated the compiling procedure above, with the same result.

I'd love to know where this mystery fixup_bigphys_addr comes from!?

Thank you all for your hard work! I look forward to contributing in any
way that I can.


Best regards,

Jeff



-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: fixup_bigphys_addr and DBAu1500 dev board

[Dan Malek]

Jeff Baitis wrote:

> I'd love to know where this mystery fixup_bigphys_addr comes from!?

You need the 36-bit patch from Pete that is not yet part of the
linux-mips tree.

You can find it on linux-mips.org in /pub/linux/mips/people/ppopov.

Have fun!


	-- Dan

Re: fixup_bigphys_addr and DBAu1500 dev board

[Pete Popov]

On Fri, 2003-02-21 at 12:40, Dan Malek wrote:
> Jeff Baitis wrote:
> 
> > I'd love to know where this mystery fixup_bigphys_addr comes from!?
> 
> You need the 36-bit patch from Pete that is not yet part of the
> linux-mips tree.
> 
> You can find it on linux-mips.org in /pub/linux/mips/people/ppopov.

Thanks Dan.

Jeff, the patch still applies almost 100% cleanly (just a couple of
"offsets" messages). Let me know if you have problems. There is a readme
in my directory that describes all the patches. 

Pete

Re: fixup_bigphys_addr and DBAu1500 dev board

[Jeff Baitis]

Dan & Pete:

Thank you very much for your help!

I've patched things up, and my kernel runs, but the yenta_socket kernel module
still locks the system. Time to break out GDB and take a look at everything!
Please let me know if ya'll have some suggestions. :*)

After the 36-bit PCI patch, I had to alter include/asm-mips/io.h in order to
get drivers/net/wireless to compile. Preprocessor expansion of outw_p in the
hermes.h -> hermes_enable_interrupt and hermes_set_irqmask inline functions
caused some issues; I hope this patch is of some use!

Regards,

Jeff


diff -u -r1.29.2.19 include/asm-mips/io.h
--- include/asm-mips/io.h        28 Nov 2002 23:04:11 -0000      1.29.2.19
+++ include/asm-mips/io.h        22 Feb 2003 03:44:27 -0000
@@ -329,12 +329,25 @@
        SLOW_DOWN_IO;                                                   \
 } while(0)
 
-#define outw_p(val,port)                                               \
-do {                                                                   \
-       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
-               __ioswab16(val);                                        \
-       SLOW_DOWN_IO;                                                   \
-} while(0)
+/* baitisj */
+static inline u16 outw_p(u16 val, unsigned long port)
+{
+    register u16 retval;
+    do {
+        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
+            __ioswab16(val);
+        SLOW_DOWN_IO;
+    } while(0);
+    return retval;
+}
+/*  
+ *  #define outw_p(val,port)                                           \
+ *  do {                                                                       \
+ *     *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
+ *             __ioswab16(val);                                        \
+ *     SLOW_DOWN_IO;                                                   \
+ *  } while(0)
+ */
 
 #define outl_p(val,port)                                               \
 do {                                                                   \



On Fri, Feb 21, 2003 at 03:40:44PM -0500, Dan Malek wrote:
> Jeff Baitis wrote:
> 
> > I'd love to know where this mystery fixup_bigphys_addr comes from!?
> 
> You need the 36-bit patch from Pete that is not yet part of the
> linux-mips tree.
> 
> You can find it on linux-mips.org in /pub/linux/mips/people/ppopov.
> 
> Have fun!
> 
> 
> 	-- Dan
> 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: fixup_bigphys_addr and DBAu1500 dev board

[Geert Uytterhoeven]

On Fri, 21 Feb 2003, Jeff Baitis wrote:
> -#define outw_p(val,port)                                               \
> -do {                                                                   \
> -       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
> -               __ioswab16(val);                                        \
> -       SLOW_DOWN_IO;                                                   \
> -} while(0)
> +/* baitisj */
> +static inline u16 outw_p(u16 val, unsigned long port)
> +{
> +    register u16 retval;
> +    do {
> +        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
> +            __ioswab16(val);
> +        SLOW_DOWN_IO;
> +    } while(0);
> +    return retval;
> +}

You don't need the `do { ... } while (0)' construct in an inline function.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: fixup_bigphys_addr and DBAu1500 dev board

[Pete Popov]

On Fri, 2003-02-21 at 19:50, Jeff Baitis wrote:
> Dan & Pete:
> 
> Thank you very much for your help!
> 
> I've patched things up, and my kernel runs, but the yenta_socket kernel module
> still locks the system. Time to break out GDB and take a look at everything!
> Please let me know if ya'll have some suggestions. :*)

yenta socket? There's no hardware on the board to support this.

pcmcia is always a pain in the neck to setup, but it does work on the Db
and Pb boards cause I very recently tested it. Note that I've tested it
only as a module though. The defconfig-db1500 in linux-mips.org already
has pcmcia support turned on. The socket driver module you'll end up
with is drivers/pcmcia/au1x00_ss.o. That's the module you want to load.
Note also that there is a small patch in my directory for pcmcia.

I've tested wireless cards in the past, but not recently. Recently I've
tested ata cards only. You might want to start with that as proof that
you have everything else working.

> After the 36-bit PCI patch, I had to alter include/asm-mips/io.h in order to
> get drivers/net/wireless to compile. Preprocessor expansion of outw_p in the
> hermes.h -> hermes_enable_interrupt and hermes_set_irqmask inline functions
> caused some issues; I hope this patch is of some use!

Only if Ralf applies it :)

Pete

> Regards,
> 
> Jeff
> 
> 
> diff -u -r1.29.2.19 include/asm-mips/io.h
> --- include/asm-mips/io.h        28 Nov 2002 23:04:11 -0000      1.29.2.19
> +++ include/asm-mips/io.h        22 Feb 2003 03:44:27 -0000
> @@ -329,12 +329,25 @@
>         SLOW_DOWN_IO;                                                   \
>  } while(0)
>  
> -#define outw_p(val,port)                                               \
> -do {                                                                   \
> -       *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
> -               __ioswab16(val);                                        \
> -       SLOW_DOWN_IO;                                                   \
> -} while(0)
> +/* baitisj */
> +static inline u16 outw_p(u16 val, unsigned long port)
> +{
> +    register u16 retval;
> +    do {
> +        retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
> +            __ioswab16(val);
> +        SLOW_DOWN_IO;
> +    } while(0);
> +    return retval;
> +}
> +/*  
> + *  #define outw_p(val,port)                                           \
> + *  do {                                                                       \
> + *     *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
> + *             __ioswab16(val);                                        \
> + *     SLOW_DOWN_IO;                                                   \
> + *  } while(0)
> + */
>  
>  #define outl_p(val,port)                                               \
>  do {                                                                   \
> 
> 
> 
> On Fri, Feb 21, 2003 at 03:40:44PM -0500, Dan Malek wrote:
> > Jeff Baitis wrote:
> > 
> > > I'd love to know where this mystery fixup_bigphys_addr comes from!?
> > 
> > You need the 36-bit patch from Pete that is not yet part of the
> > linux-mips tree.
> > 
> > You can find it on linux-mips.org in /pub/linux/mips/people/ppopov.
> > 
> > Have fun!
> > 
> > 
> > 	-- Dan
> > 
> > 
> > 

Re: fixup_bigphys_addr and DBAu1500 dev board

[Jeff Baitis]

Yes, the DBAu1500 board does not have CardBus support. We want to support
802.11A/G, so at the moment I have a 3.3V PCI card with a Texas Instruments
1510 CardBus bridge. A lot of modern wireless cards are CardBus-only, so that's
why we have decided to incorporate the TI bridge into our boards.

If someone out there has some notes or tips concerning getting PCMCIA working
under this architecture, I would greatly appreciate the information.

Take care, and thanks again!

-Jeff


On Mon, Feb 24, 2003 at 09:46:24AM -0800, Pete Popov wrote:
> On Fri, 2003-02-21 at 19:50, Jeff Baitis wrote:
> > Dan & Pete:
> > 
> > Thank you very much for your help!
> > 
> > I've patched things up, and my kernel runs, but the yenta_socket kernel module
> > still locks the system. Time to break out GDB and take a look at everything!
> > Please let me know if ya'll have some suggestions. :*)
> 
> yenta socket? There's no hardware on the board to support this.
> 
> pcmcia is always a pain in the neck to setup, but it does work on the Db
> and Pb boards cause I very recently tested it. Note that I've tested it
> only as a module though. The defconfig-db1500 in linux-mips.org already
> has pcmcia support turned on. The socket driver module you'll end up
> with is drivers/pcmcia/au1x00_ss.o. That's the module you want to load.
> Note also that there is a small patch in my directory for pcmcia.
> 
> I've tested wireless cards in the past, but not recently. Recently I've
> tested ata cards only. You might want to start with that as proof that
> you have everything else working.
> 
> > After the 36-bit PCI patch, I had to alter include/asm-mips/io.h in order to
> > get drivers/net/wireless to compile. Preprocessor expansion of outw_p in the
> > hermes.h -> hermes_enable_interrupt and hermes_set_irqmask inline functions
> > caused some issues; I hope this patch is of some use!
> 
> Only if Ralf applies it :)
> 
> Pete

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: fixup_bigphys_addr and DBAu1500 dev board

[Pete Popov]

On Tue, 2003-02-25 at 13:54, Jeff Baitis wrote:
> Yes, the DBAu1500 board does not have CardBus support. We want to support
> 802.11A/G, so at the moment I have a 3.3V PCI card with a Texas Instruments
> 1510 CardBus bridge. A lot of modern wireless cards are CardBus-only, so that's
> why we have decided to incorporate the TI bridge into our boards.

Ah, yes, that's true.  Just FYI, I had to debug a cardbus problem months
ago on a different architecture, so I did it on the Pb1500 instead. It
was a pci-cardbus adapter and I did get it to work,eventually, with a
cardbus wireless card. Unfortunately I didn't have time to clean it up
and submit it anywhere, internally or externally, and the bits died at
some point. 

So what you're trying to do is not hopeless but it will require some
debugging :)

Pete

> If someone out there has some notes or tips concerning getting PCMCIA working
> under this architecture, I would greatly appreciate the information.
> 
> Take care, and thanks again!
> 
> -Jeff
> 
> 
> On Mon, Feb 24, 2003 at 09:46:24AM -0800, Pete Popov wrote:
> > On Fri, 2003-02-21 at 19:50, Jeff Baitis wrote:
> > > Dan & Pete:
> > > 
> > > Thank you very much for your help!
> > > 
> > > I've patched things up, and my kernel runs, but the yenta_socket kernel module
> > > still locks the system. Time to break out GDB and take a look at everything!
> > > Please let me know if ya'll have some suggestions. :*)
> > 
> > yenta socket? There's no hardware on the board to support this.
> > 
> > pcmcia is always a pain in the neck to setup, but it does work on the Db
> > and Pb boards cause I very recently tested it. Note that I've tested it
> > only as a module though. The defconfig-db1500 in linux-mips.org already
> > has pcmcia support turned on. The socket driver module you'll end up
> > with is drivers/pcmcia/au1x00_ss.o. That's the module you want to load.
> > Note also that there is a small patch in my directory for pcmcia.
> > 
> > I've tested wireless cards in the past, but not recently. Recently I've
> > tested ata cards only. You might want to start with that as proof that
> > you have everything else working.
> > 
> > > After the 36-bit PCI patch, I had to alter include/asm-mips/io.h in order to
> > > get drivers/net/wireless to compile. Preprocessor expansion of outw_p in the
> > > hermes.h -> hermes_enable_interrupt and hermes_set_irqmask inline functions
> > > caused some issues; I hope this patch is of some use!
> > 
> > Only if Ralf applies it :)
> > 
> > Pete