* Re: Serial issue
From: Lee Revell @ 2006-07-26 22:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1153950324.2927.6.camel@mindpipe>
On Wed, 2006-07-26 at 17:45 -0400, Lee Revell wrote:
> I'm trying to connect to a Yosemite 440 PPC board using the serial
> console. I've tried everything in every Linux Serial FAQ and HOWTO but
> no matter what, I can receive but I cannot transmit.
I've resolved the problem - unlike my reference system, with this host,
hardware flow control must be disabled for it to work.
Sorry for the noise.
Lee
^ permalink raw reply
* Re: Serial issue
From: Wolfgang Denk @ 2006-07-26 21:57 UTC (permalink / raw)
To: Lee Revell; +Cc: linuxppc-embedded
In-Reply-To: <1153950324.2927.6.camel@mindpipe>
In message <1153950324.2927.6.camel@mindpipe> you wrote:
> I'm trying to connect to a Yosemite 440 PPC board using the serial
> console. I've tried everything in every Linux Serial FAQ and HOWTO but
> no matter what, I can receive but I cannot transmit.
Did you disable hardware flow control in your communication program?
Which communication program do you use, btw? I recommend C-kermit;
for details see also
http://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.?stickboard=yosemite
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is a nanocentury.
- Tom Duff, Bell Labs
^ permalink raw reply
* Serial issue
From: Lee Revell @ 2006-07-26 21:45 UTC (permalink / raw)
To: linuxppc-embedded
I'm trying to connect to a Yosemite 440 PPC board using the serial
console. I've tried everything in every Linux Serial FAQ and HOWTO but
no matter what, I can receive but I cannot transmit.
I know the cable is good, and the PPC board seems OK as I can see all
the boot messages. Could it be a bug in my host's serial port? I'm
using a Via EPIA M6000.
$ sudo cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:0 tx:0 rx:5379 oe:7 RTS|DTR|DSR|CD
No matter what I do, tx bytes is stuck at 0. I've tried irq 0 (polling)
and irq 4. No difference at all.
Help...
Lee
^ permalink raw reply
* RE: caches on Virtex 4
From: Martin, Tim @ 2006-07-26 21:18 UTC (permalink / raw)
To: heiguga, linuxppc-embedded
Robert,
There are several registers/etc that affect the caches on the Virtex4
PPC core.
Step 1 - Make sure your FPGA is configured to have caches in the memory
regions you're interested in caching. Your FPGA designer should have
done this in the EDK (check options in the MHS file).
Step 2 - Make sure the individual cache regions are enabled. Look at
the Xilinx standalone BSP to see how this works, or read the processor
manual. E.g. xcache_l.c (a Xilinx standalone BSP file) in
XCache_EnableDCache modifies SGR, DCWR, and DCCR SPRs.
Xcache_EnableICache modifies SGR and ICCR SPRs.
Step 3- Make sure the cache configuration register (CCR0) is configured
correctly.
By default, I'm pretty sure you only need to worry about Step 1, as I
thought Step2 and 3 were handled by the kernel early in the boot process
and/or u-boot.
> -----Original Message-----
> From: linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.or
> g] On Behalf Of heiguga
> Sent: Wednesday, July 26, 2006 10:59 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: caches on Virtex 4
>=20
> Hi!
>=20
> I am working on an ml403 board (virtex4 with ppc core). I am=20
> sucessfully using Linux 2.4 and 2.6.
> I have done a few performance tests with networking, applications...
>=20
> How can i ensure, that the caches are turned on? (is there a special
> Register?)
> Where are the caches turned on?
>=20
> nice greetings
> Robert
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* RE: Slow boot with NFS, server not responding
From: Edward Jubenville @ 2006-07-26 19:55 UTC (permalink / raw)
To: Andrei Konovalov, Matej Kupljen; +Cc: linuxppc-embedded
In-Reply-To: <44C65097.2030601@ru.mvista.com>
Andrei wrote:
> Did you try using ethereal or tcpdump to see what is going on the wire?
I ran ethereal on the NFS server and on a PC connected to the same hub as
the target board highlighted the problem. Many NFS READ REPLY messages from
the server were getting lost on their way to the target board. The default
timeout was slow (about 1 second) so boot time was grossly extended. The
packets were getting dropped by a Bay Networks switch. Bypassing the switch
temporarily solved the problem, but I needed a more robust solution.
Matej wrote:
> We solved this by specifying additional kernel command line parameter:
> nfsroot=,tcp
> which specifies that for the NFS TCP should be used instead of UDP.
I tried that, and the behavior changed only a little bit. I would still get
the original error messages, but I would also get TCP checksum errors
reported. I think the problematic switch was being overwhelmed. I then
looked at other NFS mount arguments, and tried lowering read/write sizes to
fit into a single Ethernet packet.
I tried:
nfsroot=...,rsize=1024,wsize=1024
and that fixed the problem!
Thanks for the help!
Ed Jubenville
^ permalink raw reply
* caches on Virtex 4
From: heiguga @ 2006-07-26 17:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I am working on an ml403 board (virtex4 with ppc core). I am
sucessfully using Linux 2.4 and 2.6.
I have done a few performance tests with networking, applications...
How can i ensure, that the caches are turned on? (is there a special
Register?)
Where are the caches turned on?
nice greetings
Robert
^ permalink raw reply
* using BRAM for heavly used Code (on Virtex4fx)
From: Robert Zach so-logic @ 2006-07-26 17:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I am working on an ml403 board (virtex4 with ppc core). I am
sucessfully using Linux 2.4 and 2.6.
I have done a few performance tests with networking, applications...
In the Virtex 4 is it possible to use BRAM(which are 10 times faster
then the normal RAM)...
I would like to connect this BRAMS in a special address area...
Questions:
1.1. Is it possible to write a linker script, that places heavly used
Code(or importend Interrupt Routines...) of the kernel in my special
Adress Area(on the BRAM)?
Has anyone already written such a Linker script?
1.2. Or do I have to tell the bootloader to copy the special marked
(how?) heavly used Code in this special Area?
Has anyone done such a thing?
2. Is there a way to tell the Kernel to place heavily used
Application Code or Data automatically in my special Adress Area?
Has anyone worked on such a thing?
Nice greetings
Robert
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Johannes Berg @ 2006-07-26 17:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <1153864334.18353.8.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Tue, 2006-07-25 at 16:52 -0500, Benjamin Herrenschmidt wrote:
> They should still, for sure. Johannes, please sync with Paulus since I
> think you posted previous version of at least some of these that he's
> about to push to Linus via the powerpc tree.
Hm, I don't think I ever posted 'final' versions of these that I signed
off, but I'll take a look.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Milton Miller @ 2006-07-26 14:06 UTC (permalink / raw)
To: cthomas, linuxppc-embedded
On Tue Jul 25 2006 05:30:39 PM CDT, Clint Thomas wrote:
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does not
> need it to boot the linux kernel. I want to load an uncompressed linux
> kernel into memory and start the execution of the kernel, without using
> any kind of bootloader. Is this possible? Or does linux need some kind
> of firmware or other software to tell it to start executing? Thanks for
> any info you might have.
To run a powerpc (not ppc, which will be removed) kernel, in addition to the uncompressed kernel you will need to supply a device tree structure, point r3 to it, zero r5, and set r4 to the load address (zero as you have described). See Documentation/powerpc/booting-without-of.txt for details. Then arrange for you processor to start executing at address 0. Note that /vmlinux has an elf header, you can use objcopy to remove it or adjust r4 and your start point; the kernel will copy itself to 0, clear bss and set up the stack. The device tree structure must be placed above the bss space in memory, not just the initialized data.
milton
^ permalink raw reply
* Re: DRM git vs. Linux 2.6.17
From: Michel Dänzer @ 2006-07-26 14:38 UTC (permalink / raw)
To: Dave Airlie; +Cc: linuxppc-dev, dri-devel
In-Reply-To: <1153899787.20778.99.camel@thor.lorrainebruecke.local>
On Wed, 2006-07-26 at 09:43 +0200, Michel Dänzer wrote:
>
> I suspect this might be a PPC specific kernel build system issue related
> to Modules.symvers,
Actually, now that my x86_64 box is back up, it happens there as well,
so maybe it's related to the Debian toolchain or kernel packaging.
Apologies to linuxppc-dev for the false alarm.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Andrei Konovalov @ 2006-07-26 10:45 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
Hi Clint,
You may want to look at the arch/ppc/boot/simple bootwrapper.
This wrapper links together with the compressed kernel image
into single file. One just needs to load this file into memory
and pass control to the wrapper. The bootwrapper uncompresses
the kernel into memory and passes the board information in bd_t structure.
As an example, Xilinx ML300 or ML403 boards (without any firmware)
can be booted this way: load zImage.elf into RAM (e.g. using JTAG
debugger) and jump to the the wrapper entry point.
This stuff is not in arch/powerpc yet, but recently Mark Greer
has posted the patches to fix that:
[PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
Thanks,
Andrei
Clint Thomas wrote:
> Hey guys,
>
> I have gone through the Linuxppc embedded and dev lists for information
> related to what I am trying to do, but was unable to find exactly what
> i'm looking for.
>
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does not
> need it to boot the linux kernel. I want to load an uncompressed linux
> kernel into memory and start the execution of the kernel, without using
> any kind of bootloader. Is this possible? Or does linux need some kind
> of firmware or other software to tell it to start executing? Thanks for
> any info you might have.
>
> Clinton Thomas
> cthomas@soneticom.com
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Slow boot with NFS, server not responding
From: Kalle Pokki @ 2006-07-26 9:52 UTC (permalink / raw)
To: Edward Jubenville; +Cc: linuxppc-embedded
In-Reply-To: <GPECLCIGPLHEOMGPMCPAOEIIDNAA.edjubenville@adelphia.net>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On 7/25/06, Edward Jubenville <edjubenville@adelphia.net> wrote:
I am having trouble booting the kernel with a root file system over NFS.
> Once the kernel has mounted the file system, it cycles through this pair
> of
> messages, endlessly:
>
> nfs: server 192.168.0.39 not responding, still trying
> nfs: server 192.168.0.39 OK
Try connecting to an old half-duplex hub instead of a full-duplex switch to
see if it works. Perhaps the duplex setting is not consistent between the
network driver and PHY.
I have a board with exactly the same symptoms, but I've not yet had the time
to look into this. However using the old hub provided a temporary "fix"...
[-- Attachment #2: Type: text/html, Size: 1167 bytes --]
^ permalink raw reply
* Re: Slow boot with NFS, server not responding
From: Matej Kupljen @ 2006-07-26 9:03 UTC (permalink / raw)
To: Edward Jubenville; +Cc: linuxppc-embedded
In-Reply-To: <GPECLCIGPLHEOMGPMCPAOEIIDNAA.edjubenville@adelphia.net>
Hi
> I am having trouble booting the kernel with a root file system over NFS.
> Once the kernel has mounted the file system, it cycles through this pair of
> messages, endlessly:
>
> nfs: server 192.168.0.39 not responding, still trying
> nfs: server 192.168.0.39 OK
We had the same problems on a DBAU1200 board, because that board uses
smc91c111 chip, which has small RX buffers, and a lot of RX overruns
happened.
We solved this by specifying additional kernel command line parameter:
nfsroot=,tcp
which specifies that for the NFS TCP should be used instead of UDP.
I hope this helps.
BR,
Matej
^ permalink raw reply
* Re: DRM git vs. Linux 2.6.17
From: Michel Dänzer @ 2006-07-26 7:43 UTC (permalink / raw)
To: Dave Airlie; +Cc: linuxppc-dev, dri-devel
In-Reply-To: <Pine.LNX.4.64.0607251030220.30301@skynet.skynet.ie>
On Tue, 2006-07-25 at 10:31 +0100, Dave Airlie wrote:
> Did you build you kernel with CONFIG_DRM=y? if so don't.
>
> to use DRM CVS you need to make sure in-kernel DRM isn't built-in.
Thanks, but I'm quite aware of that. :)
I suspect this might be a PPC specific kernel build system issue related
to Modules.symvers, so I'm CC'ing linuxppc-dev and including the
original post below for reference. Any hints appreciated.
> On Tue, 25 Jul 2006, Michel Dnzer wrote:
>
> Building DRM git against 2.6.17, I get:
>
> Building modules, stage 2.
> MODPOST
> *** Warning: "drm_addbufs_agp" [/home/michdaen/src/mesa-git/drm/linux-core/drm] duplicated symbol!
>
> and the same for a lot of DRM core symbols (possibly all of them). The
> resulting DRM core module loads, but the driver doesn't:
>
> Jul 24 13:47:27 thor kernel: radeon: disagrees about version of symbol drm_open
> Jul 24 13:47:27 thor kernel: radeon: Unknown symbol drm_open
>
> Removing Module.symvers from the DRM and kernel trees before building
> the DRM avoids these problems. Any ideas where the root of this lies?
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Kalle Pokki @ 2006-07-26 6:15 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
On 7/26/06, Clint Thomas <cthomas@soneticom.com> wrote:
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does not
> need it to boot the linux kernel. I want to load an uncompressed linux
> kernel into memory and start the execution of the kernel, without using any
> kind of bootloader. Is this possible? Or does linux need some kind of
> firmware or other software to tell it to start executing? Thanks for any
> info you might have.
>
Once the hardware is initialised, it is pretty straightforward to boot the
linux kernel. All you have to have is the kernel at address zero, struct
bd_info filled in some place in memory, kernel command line stored in
memory, and registers r3 ... r7 containing pointers to these.
For reference, look
1) include/asm-ppc/ppcboot.h for example struct bd_info
2) arch/ppc/syslib/m8260_setup.c for the registers
If you have some custom hardware, you need to create (basically empty)
platform code, since the existing ones would try to touch some board control
registers you don't have.
But remember, you need to initialise the memory controller and all sorts of
things yourself somehow - with a JTAG debugger or a custom boot loader.
[-- Attachment #2: Type: text/html, Size: 1682 bytes --]
^ permalink raw reply
* [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Haren Myneni @ 2006-07-26 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Milton Miller II, Nathan Lynch, External List
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
Created this patch based on Nathan's posting
(http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024451.html). If OK,
please send it to upstream.
Thanks
Haren
Noticing the following might_sleep warning (dump_stack()) during kdump
testing when CONFIG_DEBUG_SPINLOCK_SLEEP is enabled. All secondary CPUs
will be calling rtas_set_indicator with interrupts disabled to remove
them from global interrupt queue.
BUG: sleeping function called from invalid context at
arch/powerpc/kernel/rtas.c:463
in_atomic():1, irqs_disabled():1
Call Trace:
[C00000000FFFB970] [C000000000010234] .show_stack+0x68/0x1b0 (unreliable)
[C00000000FFFBA10] [C000000000059354] .__might_sleep+0xd8/0xf4
[C00000000FFFBA90] [C00000000001D1BC] .rtas_busy_delay+0x20/0x5c
[C00000000FFFBB20] [C00000000001D8A8] .rtas_set_indicator+0x6c/0xcc
[C00000000FFFBBC0] [C000000000048BF4] .xics_teardown_cpu+0x118/0x134
[C00000000FFFBC40] [C00000000004539C] .pseries_kexec_cpu_down_xics+0x74/0x8c
[C00000000FFFBCC0] [C00000000002DF08] .crash_ipi_callback+0x15c/0x188
[C00000000FFFBD50] [C0000000000296EC] .smp_message_recv+0x84/0xdc
[C00000000FFFBDC0] [C000000000048E08] .xics_ipi_dispatch+0xf0/0x130
[C00000000FFFBE50] [C00000000009EF10] .handle_IRQ_event+0x7c/0xf8
[C00000000FFFBF00] [C0000000000A0A14] .handle_percpu_irq+0x90/0x10c
[C00000000FFFBF90] [C00000000002659C] .call_handle_irq+0x1c/0x2c
[C00000000058B9C0] [C00000000000CA10] .do_IRQ+0xf4/0x1a4
[C00000000058BA50] [C0000000000044EC] hardware_interrupt_entry+0xc/0x10
--- Exception: 501 at .plpar_hcall_norets+0x14/0x1c
LR = .pseries_dedicated_idle_sleep+0x190/0x1d4
[C00000000058BD40] [C00000000058BDE0] 0xc00000000058bde0 (unreliable)
[C00000000058BDF0] [C00000000001270C] .cpu_idle+0x10c/0x1e0
[C00000000058BE70] [C000000000009274] .rest_init+0x44/0x5c
To fix this issue, rtas_set_indicator_fast() is added so that will not
wait for RTAS 'busy' delay and this new function is used for kdump (in
xics_teardown_cpu()) and for CPU hotplug ( xics_migrate_irqs_away()).
Signed-off-by: Haren Myneni <haren@us.ibm.com>
[-- Attachment #2: ppc64-add-rtas-set-indicator-fast.patch --]
[-- Type: text/x-patch, Size: 2462 bytes --]
diff -Naurp 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2618-rc2/arch/powerpc/kernel/rtas.c
--- 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2006-07-25 19:34:11.000000000 -0700
+++ 2618-rc2/arch/powerpc/kernel/rtas.c 2006-07-25 19:33:16.000000000 -0700
@@ -569,6 +569,27 @@ int rtas_set_indicator(int indicator, in
}
EXPORT_SYMBOL(rtas_set_indicator);
+/*
+ * Ignoring RTAS extended delay
+ */
+int rtas_set_indicator_fast(int indicator, int index, int new_value)
+{
+ int rc;
+ int token = rtas_token("set-indicator");
+
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return -ENOENT;
+
+ rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
+
+ WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
+
+ if (rc < 0)
+ return rtas_error_rc(rc);
+
+ return rc;
+}
+
void rtas_restart(char *cmd)
{
if (rtas_flash_term_hook)
diff -Naurp 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2618-rc2/arch/powerpc/platforms/pseries/xics.c
--- 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:34:41.000000000 -0700
+++ 2618-rc2/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:33:36.000000000 -0700
@@ -796,7 +796,7 @@ void xics_teardown_cpu(int secondary)
* so leave the master cpu in the group.
*/
if (secondary)
- rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 -
default_distrib_server, 0);
}
@@ -813,7 +813,7 @@ void xics_migrate_irqs_away(void)
xics_set_cpu_priority(cpu, 0);
/* remove ourselves from the global interrupt queue */
- status = rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 - default_distrib_server, 0);
WARN_ON(status < 0);
diff -Naurp 2618-rc2.orig/include/asm-powerpc/rtas.h 2618-rc2/include/asm-powerpc/rtas.h
--- 2618-rc2.orig/include/asm-powerpc/rtas.h 2006-07-25 19:34:27.000000000 -0700
+++ 2618-rc2/include/asm-powerpc/rtas.h 2006-07-25 19:33:57.000000000 -0700
@@ -170,6 +170,7 @@ extern int rtas_get_sensor(int sensor, i
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
extern int rtas_set_indicator(int indicator, int index, int new_value);
+extern int rtas_set_indicator_fast(int indicator, int index, int new_value);
extern void rtas_progress(char *s, unsigned short hex);
extern void rtas_initialize(void);
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: bennett78 @ 2006-07-25 23:38 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]
Clint Thomas wrote:
> Hey guys,
>
> I have gone through the Linuxppc embedded and dev lists for
> information related to what I am trying to do, but was unable to find
> exactly what i'm looking for.
>
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does
> not need it to boot the linux kernel. I want to load an uncompressed
> linux kernel into memory and start the execution of the kernel,
> without using any kind of bootloader. Is this possible? Or does linux
> need some kind of firmware or other software to tell it to start
> executing? Thanks for any info you might have.
You seem to be looking for a striped down U-boot functionality:
o copy flash to ram and run code
but to do this:
o processor registers need to be initilized
o caches need to be flushed
o interrupts need to be disabled
o C environment (stack) needs to be setup
U-boot is fairly small compared to a x86 BIOS which has to find
multiple boot device choices, yet supports multiple architectures.
I'm using a BDI2000 to load/debug u-boot running in SDRAM
for a new PPC hardware design. U-boot is probably easier to
debug than the kernel!
U-boot has other features that help with initial H/W turnon:
o it's a debug/monitor
o ram test
o ram/register read/modify
o u-boot environment
o IP address, mac address
o Linux boot options - NFS verses flash
o Ethernet/NFS option using a server enables:
o debugging kernel changes
o debugging kernel driver modules
o quick change of application processes
o cross compile target code on server to local target
o telnet to embedded H/W
o knows how to flash partitions
o u-boot (/dev/mtd0) (well I use the BDI to flash here)
o can flash kernel (/dev/mtd1)
o can flash root fs (/dev/mtd2)
o can flash config data (/dev/mtd3)
o this partitioning will help with future F/W updates
o kind of required if your flash is soldered to the board
o to read/write flash requires u-boot to relocate itself to ram
>
> Clinton Thomas
> cthomas@soneticom.com
> _______________________________________________
>
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Frank Bennett
*/Technical Contractor/*
/Triad Systems Engineering
200 West Mountain Avenue, Suite 103C
Ft. Collins, CO 80521
/http://www.traidsyseng.com <http://www.triadsyseng.com>
frank.bennett@triadsyseng.com <mailto:frank.bennett@triadsyseng.com>/
/
"I think there's a world market for about five computers."
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
[-- Attachment #2: Type: text/html, Size: 5234 bytes --]
^ permalink raw reply
* Booting Linux Kernel without bootloader
From: Clint Thomas @ 2006-07-25 22:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hey guys,
I have gone through the Linuxppc embedded and dev lists for information
related to what I am trying to do, but was unable to find exactly what
i'm looking for.
Basically, the system I want linux running on does not require the
initialization of hardware that U-boot provides, or at least it does not
need it to boot the linux kernel. I want to load an uncompressed linux
kernel into memory and start the execution of the kernel, without using
any kind of bootloader. Is this possible? Or does linux need some kind
of firmware or other software to tell it to start executing? Thanks for
any info you might have.
Clinton Thomas
cthomas@soneticom.com
[-- Attachment #2: Type: text/html, Size: 1100 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Benjamin Herrenschmidt @ 2006-07-25 21:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <7015.131.234.232.48.1153840399.squirrel@secure.sipsolutions.net>
On Tue, 2006-07-25 at 17:13 +0200, Johannes Berg wrote:
> Takashi Iwai wrote:
>
> > Thanks, now all patches are on ALSA tree.
>
> Thanks.
> These should still go into 2.6.18, will that be possible?
They should still, for sure. Johannes, please sync with Paulus since I
think you posted previous version of at least some of these that he's
about to push to Linus via the powerpc tree.
Ben.
^ permalink raw reply
* Re: powermac: More powermac backlight fixes
From: Benjamin Herrenschmidt @ 2006-07-25 21:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, aris, johannes, linux-kernel
In-Reply-To: <20060724200315.d3c80ed0.akpm@osdl.org>
On Mon, 2006-07-24 at 20:03 -0700, Andrew Morton wrote:
> On Sat, 15 Jul 2006 15:09:00 +0200
> Michael Hanselmann <linux-kernel@hansmi.ch> wrote:
>
> > This patch fixes several problems:
> > - The legacy backlight value might be set at interrupt time. Introduced
> > a worker to prevent it from directly calling the backlight code.
> > - via-pmu allows the backlight to be grabbed, in which case we need to
> > prevent other kernel code from changing the brightness.
> > - Don't send PMU requests in via-pmu-backlight when the machine is about
> > to sleep or waking up.
> > - More Kconfig fixes.
> >
> > ...
> >
> > static void pmac_backlight_key_worker(void *data);
> > +static void pmac_backlight_set_legacy_worker(void *data);
> > +
> > static DECLARE_WORK(pmac_backlight_key_work, pmac_backlight_key_worker, NULL);
> > +static DECLARE_WORK(pmac_backlight_set_legacy_work, pmac_backlight_set_legacy_worker, NULL);
>
> I see schedule_work()s in there, but no flush_scheduled_work()s or anything
> like that. Generally, this means there are races against rmmod, close(),
> etc.
Can this be rmmod'ed ? No code at hand right now, but the old version
certainly couldn't and the PMU driver who calls that can't neither. It's
not a file descriptor neither.
> >
> > +void pmac_backlight_disable()
> > +{
> > + atomic_inc(&kernel_backlight_disabled);
> > +}
> > +
> > +void pmac_backlight_enable()
> > +{
> > + atomic_dec(&kernel_backlight_disabled);
> > +}
> > +
>
> So if userspace calls ioctl(PMU_IOC_GRAB_BACKLIGHT) eleven times, eleven
> enables are needed? (Actually, eleven open()/close() sequences, I think).
It makes sense to do it his way... You do that to stop kernel from
handling the backlight keys as long as at least one userspace client has
set the "grab" and thus basically says it handles them there. When they
all are gone and/or their fd closed, the backlight control returns to
the kernel default version
> Methinks you wanted just
>
> kernel_backlight_disabled = 1;
Nope, I think he's right there. There are cases where both gnome and
pbbuttons for example say to the kernel they handle the backlight keys.
A bit dodgy but it actually works and you want the kernel to properly
refcount before re-enabling it's own implementation.
Ben.
^ permalink raw reply
* PPC 82xx (MPC8270) PCI host bridge resource allocation issue
From: Tony Hardie @ 2006-07-25 21:13 UTC (permalink / raw)
To: linuxppc-embedded
Hiya, (we are running a custom board very similar to pq2fads)
I am having some issues with the resource allocation of the host bus in
2.6.17.3 where by on startup the kernel complains below the lines:
[ 8.824450] PCI: Cannot allocate resource region 0 of device
0000:00:00.0
[ 8.843507] PCI: Cannot allocate resource region 1 of device
0000:00:00.0
We are using the same memory map (did'nt) override the pq2fads code
I also output lspci. What should it be doing here? How do I correct
this?
Cheers
Tony
[ 0.000000] PCI Autoconfig: Found Bus 0, Device 17, Function 0
[ 0.000000] PCI Autoconfig: BAR 0x10, Mem size=3D0x1000,
address=3D0xaffff000
[ 0.000000] PCI Autoconfig: BAR 0x14, Mem size=3D0x8000,
address=3D0xafff0000
[ 0.000000] PCI Autoconfig: Found Bus 0, Device 18, Function 0
[ 0.000000] PCI Autoconfig: BAR 0x10, Mem size=3D0x10000,
address=3D0xaffe0000
[ 0.000000] PCI Autoconfig: Found Bus 0, Device 19, Function 0
[ 0.000000] PCI Autoconfig: BAR 0x10, Mem size=3D0x100000,
address=3D0xafe00000
[ 0.000000] PCI Autoconfig: Found Bus 0, Device 20, Function 0
[ 0.000000] PCI Autoconfig: BAR 0x10, Mem size=3D0x100000,
address=3D0xafd00000
[ 0.000000] PCI Autoconfig: BAR 0x14, Mem size=3D0x100000,
address=3D0xafc00000
[ 0.000000] arch/ppc/platforms/netcom_stix.c: configuring brgc1
[ 0.000000] Built 1 zonelists
[ 0.000000] Kernel command line: console=3DttyCPM0,115200
root=3D/dev/mtdblock1 rootfstype=3Djffs2 init=3D/linuxrc rw
[ 0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes)
[ 8.607666] cpm_uart: console: compat mode
[ 8.731735] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
[ 8.738628] Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 8.758208] Memory: 127488k available (1544k kernel code, 700k data,
96k init, 0k highmem)
[ 8.785841] Mount-cache hash table entries: 512
[ 8.791590] NET: Registered protocol family 16
[ 8.795039] PCI: Probing PCI hardware
[ 8.800789] PCI: bridge rsrc 0..1ffffff (101), parent c01b86b4
[ 8.805075] PCI: bridge rsrc 80000000..9fffffff (1200), parent
c01b86d0
[ 8.811662] PCI: bridge rsrc a0000000..afffffff (200), parent
c01b86d0
[ 8.818187] PCI:0000:00:00.0: Resource 0: 00000000-0001ffff (f=3D200)
[ 8.824450] PCI: Cannot allocate resource region 0 of device
0000:00:00.0
[ 8.831240] PCI: parent is c024a070: a0000000-afffffff (f=3D200)
[ 8.837156] PCI:0000:00:00.0: Resource 1: 00000000-07ffffff =
(f=3D1208)
[ 8.843507] PCI: Cannot allocate resource region 1 of device
0000:00:00.0
[ 8.850301] PCI: parent is c024a054: 80000000-9fffffff (f=3D1200)
[ 8.856309] PCI:0000:00:11.0: Resource 0: affff000-afffffff (f=3D200)
[ 8.862575] PCI:0000:00:11.0: Resource 1: afff0000-afff7fff (f=3D200)
[ 8.868847] PCI:0000:00:12.0: Resource 0: affe0000-affeffff (f=3D200)
[ 8.875115] PCI:0000:00:13.0: Resource 0: afe00000-afefffff (f=3D200)
[ 8.881382] PCI:0000:00:14.0: Resource 0: afd00000-afdfffff (f=3D200)
[ 8.887643] PCI:0000:00:14.0: Resource 1: afc00000-afcfffff (f=3D200)
00:00.0 Host bridge: Motorola MPC8265A/8266/8272/8270/8280 (rev 20)
Flags: bus master, 66Mhz, fast devsel, latency 248
Memory at <unassigned> (32-bit, prefetchable)
Capabilities: [48] #06 [0000]
00:11.0 Bridge: Texas Instruments PCI2040 PCI to DSP Bridge Controller
Flags: medium devsel, IRQ 19
Memory at 00000000affff000 (32-bit, non-prefetchable) =
[size=3D4K]
Memory at 00000000afff0000 (32-bit, non-prefetchable) =
[size=3D32K]
Capabilities: [50] Power Management version 1
00:12.0 Co-processor: Broadcom Corporation BCM5823 Crypto Accelerator
(rev 01)
Subsystem: Broadcom Corporation: Unknown device 0200
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 20
Memory at 00000000affe0000 (32-bit, non-prefetchable) =
[size=3D64K]
Capabilities: [48] Power Management version 2
00:13.0 Network controller: Agere Systems T8110 H.100/H.110 TDM switch
(rev 04)
Flags: bus master, medium devsel, latency 128, IRQ 22
Memory at 00000000afe00000 (32-bit, non-prefetchable) =
[size=3D1M]
00:14.0 Bridge: NET (Network Equipment Technologies) STIX 4 Port T1/E1
Card (rev 04)
Subsystem: NET (Network Equipment Technologies) STIX 4 Port
T1/E1 Card
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 23
Memory at 00000000afd00000 (32-bit, non-prefetchable) =
[size=3D1M]
Memory at 00000000afc00000 (32-bit, non-prefetchable) =
[size=3D1M]
Capabilities: [dc] Power Management version 1
Capabilities: [e4] #06 [0094]
Capabilities: [e8] Vital Product Data
Tony Hardie B.Sc
VX Software Architect
Net.com
6900 Paseo Padre Parkway
Fremont
CA, 94555
Ph: 510-574-2386
Mob: 510-449-4339
^ permalink raw reply
* [PATCH] powerpc: minor comment fix for misc_64.S
From: Geoff Levand @ 2006-07-25 21:05 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
A minor comment fix for misc_64.S.
From: Takao Shinohara
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: a/arch/powerpc/kernel/misc_64.S
===================================================================
--- a.orig/arch/powerpc/kernel/misc_64.S 2006-07-25 12:38:44.000000000 -0700
+++ a/arch/powerpc/kernel/misc_64.S 2006-07-25 13:44:56.000000000 -0700
@@ -687,7 +687,7 @@
/* clear out hardware hash page table and tlb */
ld r5,0(r27) /* deref function descriptor */
mtctr r5
- bctrl /* ppc_md.hash_clear_all(void); */
+ bctrl /* ppc_md.hpte_clear_all(void); */
/*
* kexec image calling is:
^ permalink raw reply
* Re: [PATCH] clean up pseries hcall interfaces
From: Geoff Levand @ 2006-07-25 20:55 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060725144124.GA3769@krispykreme>
Anton Blanchard wrote:
> Hi Geoff,
>
>> Seems like this in needed too... Untested.
>
> Looks good but the patch appears to be line wrapped in a few places.
>
> Anton
Sorry, I sent that out with a Web based mail client. This one
should be OK.
-Geoff
Change the scope of some pSeries routines now called through
ppc_md to static.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
--
Index: a/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- a.orig/arch/powerpc/platforms/pseries/lpar.c 2006-07-18 12:37:47.000000000 -0700
+++ a/arch/powerpc/platforms/pseries/lpar.c 2006-07-20 05:18:59.000000000 -0700
@@ -268,7 +268,7 @@
cpu, hwcpu, vpa, ret);
}
-long pSeries_lpar_hpte_insert(unsigned long hpte_group,
+static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
unsigned long va, unsigned long pa,
unsigned long rflags, unsigned long vflags,
int psize)
@@ -494,7 +494,7 @@
* Take a spinlock around flushes to avoid bouncing the hypervisor tlbie
* lock.
*/
-void pSeries_lpar_flush_hash_range(unsigned long number, int local)
+static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
{
int i;
unsigned long flags = 0;
^ permalink raw reply
* [PATCH] CEDE on non-SMT
From: Jake Moilanen @ 2006-07-25 20:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
On the JS21 systems, they have the SPLPAR hypertas set, but are not SMT
capable. So, they are not making the h_cede call. This is causing the
hypervisor to have to queue up work for the hdecr, taking an excessive
amount of time in maintenance code, and causing jitter on the box.
Making the h_cede call helps alleviate that problem.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Index: 2.6-msi/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/setup.c 2006-07-25
14:49:26.000000000 -0500
+++ 2.6-msi/arch/powerpc/platforms/pseries/setup.c 2006-07-25
14:52:49.000000000 -0500
@@ -501,7 +501,8 @@
}
/*
- * Cede if the other thread is not idle, so that it can
+ * If not SMT, cede processor. If CPU is running SMT
+ * cede if the other thread is not idle, so that it can
* go single-threaded. If the other thread is idle,
* we ask the hypervisor if it has pending work it
* wants to do and cede if it does. Otherwise we keep
@@ -514,7 +515,8 @@
* very low priority. The cede enables interrupts, which
* doesn't matter here.
*/
- if (!lppaca[cpu ^ 1].idle || poll_pending() == H_PENDING)
+ if (!cpu_has_feature(CPU_FTR_SMT) || !lppaca[cpu ^ 1].idle
+ || poll_pending() == H_PENDING)
cede_processor();
out:
^ permalink raw reply
* Re: powermac: More powermac backlight fixes
From: Michael Hanselmann @ 2006-07-25 20:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, johannes, aris, linux-kernel
In-Reply-To: <20060725184406.GA12226@hansmi.ch>
On Tue, Jul 25, 2006 at 08:44:06PM +0200, Michael Hanselmann wrote:
> On Mon, Jul 24, 2006 at 08:03:15PM -0700, Andrew Morton wrote:
> > I see schedule_work()s in there, but no flush_scheduled_work()s or anything
> > like that. Generally, this means there are races against rmmod, close(),
> > etc.
After discussing it with Aristeu, we came to the conclusion that it's
not dangerous. The generic backlight code can not be compiled as a
module. If a framebuffer driver unloads, it'll set pmac_backlight to
NULL. The workers check for it and don't do anything if true. So, if the
worker is called after unloading the module, it won't do anything.
Here's the other patch which fixes a little error in the patch you just
added to your tree. Without the patch, pbbuttonsd and other applications
changing the backlight will fail.
---
diff -Nrup --exclude-from linux-exclude-from linux-2.6.18-rc2-git4.orig/arch/powerpc/platforms/powermac/backlight.c linux-2.6.18-rc2-git4/arch/powerpc/platforms/powermac/backlight.c
--- linux-2.6.18-rc2-git4.orig/arch/powerpc/platforms/powermac/backlight.c 2006-07-25 20:51:05.000000000 +0200
+++ linux-2.6.18-rc2-git4/arch/powerpc/platforms/powermac/backlight.c 2006-07-25 20:52:02.000000000 +0200
@@ -140,9 +140,6 @@ static int __pmac_backlight_set_legacy_b
{
int error = -ENXIO;
- if (atomic_read(&kernel_backlight_disabled))
- return -EBUSY;
-
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight) {
struct backlight_properties *props;
@@ -170,11 +167,17 @@ static int __pmac_backlight_set_legacy_b
static void pmac_backlight_set_legacy_worker(void *data)
{
+ if (atomic_read(&kernel_backlight_disabled))
+ return;
+
__pmac_backlight_set_legacy_brightness(pmac_backlight_set_legacy_queued);
}
/* This function is called in interrupt context */
void pmac_backlight_set_legacy_brightness_pmu(int brightness) {
+ if (atomic_read(&kernel_backlight_disabled))
+ return;
+
pmac_backlight_set_legacy_queued = brightness;
schedule_work(&pmac_backlight_set_legacy_work);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox