headers
n2690165 | 1 Nov 2002 03:01
Picon

How to download compiled kernel via Multi-ice?

Hi, everybody~~~

I'm a new one to this list. I want to port armlinux to arm integrator
with 7tdmi. 
After I compiled kernel 2.4.18 with patch-2.4.18-rmk7, I don't know how
to download this kernel into the board, because AXD with multi-ice need
a .axf.Can every one tell me how to download it with multi-ice and AXD?
BTW, there are two file vmlinux and zImage, which image I should
download ?
Thanks in advance~~~

Andy

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 1 comment |
headers
Nicolas Pitre | 1 Nov 2002 04:11

Re: development kernels for the iPaq

On Thu, 31 Oct 2002, Russell King - ARM Linux wrote:

> On Thu, Oct 31, 2002 at 02:50:11PM +0100, Tomá¹ Ka¹párek wrote:
> > I'm not sure (i dont have it here) but mtdblock(rw) was almost fine and
> > updated, but the btdblock_ro.* code was probably untouched for longer
> > time so I did some modifications to be able to use it (I used 2.5.6 at
> > that time) (see MTD CVS)
> 
> Oh, Al's also got an updated mtdblock_ro.c driver.  But note - it is
> misnamed.  It isn't a "read only" driver, it's actually an "uncached"
> driver.  It still allows writing to RAM MTD devices.

Well that's probably a bug then.  I wrote the mtdblock driver at the time
because the generic block layer couldn't (and still can't) cope with large
flash block sizes.

I think mtdblock_ro should be nuked IMHO, but dwmw2 still keeps it around 
for some reasons.

Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 2 comments |
headers
Greg KH | 1 Nov 2002 09:08
Gravatar

Re: [PATCH] 2.5.44 sa-1111 ohci hcd

On Mon, Oct 28, 2002 at 04:13:01PM -0800, Christopher Hoover wrote:
> [ Sorry; this time without patch mangling ... ]
> 
> 
> Dereferencing hcd.pdev will always oops with SA-1111.  It has to be
> treated as a cookie, not a pointer in any common OHCI HCD code.
> 
> Apparently we need a clean way to go from struct device * to struct
> ohci_hcd *.  I added dev_to_ohci that does the obvious thing and added
> separate implementations for PCI and SA-1111.  Two implementations is
> ugly but I didn't think it wise (for me) to hack on the PCI/driverfs
> interface, so I just cut & paste the old code.
> 
> Two patches.  The first is a diff from linux-2.5.44 and
> linux-2.5.44-rmk1.  It is from rmk and adds a struct device pointer to
> ohci_hcd.

Why?  What is that needed for?  Oh wait, you don't have a pci device,
right?  So where in the device tree does the sa111 controller show up?
What type of bus is it on?

> +struct ohci_hcd *dev_to_ohci(struct device *dev) {
> +	struct pci_dev *pdev = 
> +		container_of (dev, struct pci_dev, dev);
> +	struct ohci_hcd	*ohci = 
> +		container_of (pci_get_drvdata (pdev), struct ohci_hcd, hcd);
> +
> +	return ohci;
> +}
(Continue reading)

Permalink | Reply | 2 comments |
headers
Holger Schurig | 1 Nov 2002 10:13
Picon

Re: Simple power management without APM or APCI?

> My question is.. Is this feasible at all?? What are the major things that
> can go wrong if I do this? Anyone?

This depends very much on the driver. I for example will face Power Management 
issues on my PXA250 target early next year. One thing that I'm doing right 
now is to enable power to the MAXIM RS-232 level driver when a port get's 
opened and disable the power to the chip the the port get's closed. I will 
also look into the CKEN register of the PXA (clock enable register). With 
that I can disable the PLL frequency generation to various parts of the chip.

However, many things can go wrong.

For example, I might be possible that some chip or PLL needs time to 
stabilize, so after enabling some kind of hardware I might have to wait for 
some amount of time.

Also, some chips might loose their configuration, so I might have to keep 
state of them and reprogram them. This can be complicated and not be done in 
the kernel, for example if your "chip" is as complex as a GSM module.

Also, an approach like "power the driver once the port gets open()ed" is 
certainly easier to do than "power the driver when there is data activity 
from the CPU, but disable it when not, even when the driver is officially 
open()ed" takes more thought, sweat and programming hours.

So I will certainly have to learn more about PM, APM (I saw in the cerf-patch 
from Intrinsyc some apm.c module that was derived from ipaq work), hotplug 
and of course lots of chip manufacturer's PDF reference manuals. And I'm 
afraid that you will do this, too.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Schurig | 1 Nov 2002 10:16
Picon

Re: 2.4.18-rmk7, xconfig, MTD menu disabled when SA1100 is selected

> I can understand this (given lattest kernel developments) but which is
> considered the "canonical" interface for configuring a kernel? Is it
> menuconfig, config, or simply editing ".config" file by hand?

I can't say what is canonical (or if something is), but xconfig was always too 
ugly for me, so I used "make menuconfig" and "$EDITOR .config; make 
oldconfig" all the time with great success.

Hmm, I like "make xconfig" with Roman Zippel's new kernel config tool :-)

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Nov 2002 10:46
Picon

Re: How to download compiled kernel via Multi-ice?

On Fri, Nov 01, 2002 at 10:01:02AM +0800, n2690165 wrote:
> I'm a new one to this list. I want to port armlinux to arm integrator
> with 7tdmi. 

Linux will never run on an ARM7TDMI - it doesn't have a MMU.  You should
be looking at uclinux, which doesn't require a MMU.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Nov 2002 10:54
Picon

Re: development kernels for the iPaq

On Thu, Oct 31, 2002 at 10:11:28PM -0500, Nicolas Pitre wrote:
> On Thu, 31 Oct 2002, Russell King - ARM Linux wrote:
> > Oh, Al's also got an updated mtdblock_ro.c driver.  But note - it is
> > misnamed.  It isn't a "read only" driver, it's actually an "uncached"
> > driver.  It still allows writing to RAM MTD devices.
> 
> Well that's probably a bug then.  I wrote the mtdblock driver at the time
> because the generic block layer couldn't (and still can't) cope with large
> flash block sizes.

It doesn't look like a bug - its a deliberate piece of code that
specifically enables write access for RAM MTD devices.  Also, it
was David that pointed out to me that it was misnamed.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 0 comments |
headers
Magnusson, Johan | 1 Nov 2002 13:01
Picon

Re: Simple power management without APM or APCI?

Thanks for answering Holger!

I see what you mean about the problems with turning off the clock for som
periphials. The thing I was wondering about is how basic Linux functionality
will react if I alter the clock frequecy. 

I can set my PLL in a mode where it does'nt multply the crystal frequecy,
which means that the system clock frequency then is my raw crystal
frequency. As I vaugly remeber it, something like CPU_FREQUENCY or close to
that is a "#define" in Linux (or?). This will mean that alot of stuff will
cease to work (e.g. serialport drivers that rely on this defined frequency
to calculate divisors etc. (true??)). This may be OK. Although I may require
one or two periphial drivers to work but this can perhaps be done by
restarting them, assuming that they are modifified by me to get their
frequency as an in-argument or from a global variable. 

The thing that I am most koncerned about is that some parts of Linux, the
parts controlling processes, timer related things and really fundamental
stuff will die or worse (whatever that is :( . I know NOTHING about this in
Linux...

Shall I abandon this stupid project or ?

Best Regards 
Johan K Magnusson

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
(Continue reading)

Permalink | Reply | 1 comment |
headers
Holger Schurig | 1 Nov 2002 14:15
Picon

Re: Simple power management without APM or APCI?

> I see what you mean about the problems with turning off the clock for som
> periphials. The thing I was wondering about is how basic Linux
> functionality will react if I alter the clock frequecy.

Oh, we spoke from different thinks.

I meant to turn inidivual PPLs on and off, e.g. for Bluetooth UART, 
FullFunction UART, I2S, I2C, USB Client ...    assuming that a stopped PLL in 
a CMOS chip consumes less power.

You spoke about the CPU frequency generator PLL. Linux has already 
infrastructure for CPU frequency changes, at least on some CPUs (e.g. 
SA1110).

> As I vaugly remeber it, something like CPU_FREQUENCY or close to
> that is a "#define" in Linux (or?). 

It is. Surely

   http://www.google.com/linux?q=cpufreq

is your friend.

> This will mean that alot of stuff will cease to work

Not necessarily. This depends on your CPU. For example, on the PXA250 the cpu 
frequency is independent from the serial frequency. But memory timing and LCD 
controller timing is.

You have to put hooks into your drivers so that your driver get's informed
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Nov 2002 18:49
Favicon

Re: development kernels for the iPaq


nico <at> cam.org said:
>  I think mtdblock_ro should be nuked IMHO, but dwmw2 still keeps it
> around  for some reasons. 

ucLinux people wanted it for its simplicity. If we could configure out the 
caching from mtdblock.c, or at least make it not allocate the cache for 
readonly opens or devices where erasesize <= sector size (or RAM) then we 
should be able to drop it.

--
dwmw2

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 0 comments |

Gmane