* Re: compact flash driver
From: Bizhan Gholikhamseh (bgholikh) @ 2005-11-02 11:28 UTC (permalink / raw)
To: mcr; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
>>>>> "Alex" == Alex Zeffertt <ajz@cambridgebroadband.com> writes:
>> Hello All, Are there any compact flash driver supported for Linux
>> 2.6? If there is where can i get the source code. Thanks, Bizhan
>>
Alex> I think that CF cards just get treated the same as any other
Alex> IDE disk by linux. No special driver needed.
>Yes. There are some gotchas with newer pcmcia/cardbus flash cards.
>For instance, Silicon Systems devices claim to support IORDY, but
don't, which results in a system hang. I imagine that the same >kind of
things will show up in newer CF devices, although I think that CF can't
support DMA.
>It also depends upon how you interface CF: via an IDE controller, or
via a cardbus interface.
>I expect to have a git tree with stuff available soon.
Do you have an early release code? I can start to work at.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 2064 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: fix: swallowed chars when booting.
From: Heiko Schocher @ 2005-11-02 13:01 UTC (permalink / raw)
To: linuxppc-dev
Hello,
during I am searching the right solution for my
other patch, i found another way for solving the
swallowed chars problem when booting on SMC2.
Please comment.
thanks
Heiko Schocher
[PATCH] ppc32: Fix: swallowed chars on SMC2 Console.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..baedd74 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -552,9 +552,9 @@ static void cpm_uart_set_termios(struct
* enables, because we want to put them back if they were
* present.
*/
- prev_mode = smcp->smc_smcmr;
- smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART;
- smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN));
+ prev_mode = smcp->smc_smcmr & (SMCMR_REN | SMCMR_TEN);
+ smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART
+ | prev_mode;
} else {
sccp->scc_psmr = (sbits << 12) | scval;
}
^ permalink raw reply related
* About 2.6.14 on AMCC Yosemite board
From: KylongMu @ 2005-11-02 13:49 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: Linuxppc-embedded
In-Reply-To: <20050711142250.BC3253539FE@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
Hi, Denk
I've got my Yosemite board today, it's shows very good by default
test.
I downloaded the 2.6.14 according the repository from your website by
cogito.
with default configure, I boot with the uImage, but the system halt,
attachment
is the message.
I don't know what happen with it, pls help me.
Thanks a lot!
Kylong Mu
[-- Attachment #2: make_command.txt --]
[-- Type: text/plain, Size: 76 bytes --]
924 make yosemite_defconfig
925 make menuconfig
926 make uImage
[-- Attachment #3: bootmessage.txt --]
[-- Type: text/plain, Size: 6122 bytes --]
U-Boot 1.1.3 (Sep 7 2005 - 09:03:02)
IBM PowerPC 440 EP Rev. B
Board: AMCC YOSEMITE
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
PER: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
00 0c 105a 4d68 0180 0e
In: serial
Out: serial
Err: serial
Net: ppc_440x_eth0, ppc_440x_eth1
Hit any key to stop autoboot: 0
=> tftp 0x4000000 uImage
Waiting for PHY auto negotiation to complete.. done
Using ppc_440x_eth0 device
TFTP from server 192.168.0.93; our IP address is 192.168.0.66
Filename 'uImage'.
Load address: 0x4000000
Loading: #################################################################
#################################################################
#################################################################
#############################################
done
Bytes transferred = 1225628 (12b39c hex)
=> bootm 0x4000000 fed40000
## Booting image at 04000000 ...
Image Name: Linux-2.6.14
Created: 2005-11-02 13:20:24 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1225564 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fed40000 ...
Image Name: Yosemite Ramdisk
Created: 2005-08-30 2:13:49 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 17770706 Bytes = 16.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0ee9b000, end 0ff8d8d2 ... OK
Linux version 2.6.14 (root@dxp) (gcc �.� 3.3.3 (DENX ELDK 3.1.1 3.3.3-10)) #2 Wed Nov 2 21:20:16 CST 2005
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: ramdisk=49152 root=/dev/ram ip=192.168.1.62:::::eth0:off
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 239360k available (1876k kernel code, 708k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
Freeing initrd memory: 17354k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
SCSI subsystem initialized
usbmon: debugfs is not available
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci.0: irq 40, io mem 0xef601000
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
pegasus: v0.6.12 (2005/01/13), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new driver pegasus
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:8f:aa
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:80:8f:aa
eth1: found Generic MII PHY (0x03)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
yosemite: flash mapping: 4000000 at fc000000
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdffffff
POB0: BEAR=0xc27e319400000001 BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C015D7C8 SP: C0521E30 REGS: c0291f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: c0520000
Last syscall: 120
GPR00: 00000002 C0521E30 CEE98B10 C0242F18 00000000 00000000 C0521EE0 CEF0C3F8
GPR08: 000000FF 00000004 00000002 00000001 42254128 C0020028 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: 00000000 C0521EE0 C0242DB0 00000000 C0242F18 C0521EE0 00000000 C0242F18
NIP [00000000] 0x0
LR [c015d7c8] genprobe_new_chip+0xa8/0xc0
Call trace:
[c015d7c8] genprobe_new_chip+0xa8/0xc0
[c015d508] genprobe_ident_chips+0x3c/0x254
[c015d444] mtd_do_chip_probe+0x18/0xa0
[c01587b8] cfi_probe+0x18/0x28
[c01570c4] do_map_probe+0x40/0xe0
[c028594c] init_yosemite_flash+0x90/0xec
[c026c728] do_initcalls+0x54/0xfc
[c000137c] init+0x2c/0x13c
[c0004630] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdffffff
POB0: BEAR=0xc27e319400000001 BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C000229C SP: C0291E60 REGS: c0291f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: c0520000
Last syscall: 120
GPR00: 08000000 C0291E60 CEE98B10 C0291E70 000015D7 FFFFFFFF C0230000 C0290000
GPR08: C0230000 C000229C 00021002 C00036D0 CEE98CD8 C0020028 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: 00000000 C0521EE0 C0242DB0 00000000 C0242F18 C0521EE0 C0291F50 00000007
NIP [00000000] 0x0
LR [c000229c] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ permalink raw reply
* RE: About 2.6.14 on AMCC Yosemite board
From: Steven Blakeslee @ 2005-11-02 14:31 UTC (permalink / raw)
To: KylongMu, Wolfgang Denk; +Cc: Linuxppc-embedded
Your FLASH mapping says that FLASH starts at 0xFC000000. There should
only be 32Meg of FLASH starting at address 0xFE000000.=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of KylongMu
> Sent: Wednesday, November 02, 2005 8:50 AM
> To: 'Wolfgang Denk'
> Cc: Linuxppc-embedded@ozlabs.org
> Subject: About 2.6.14 on AMCC Yosemite board
>=20
> Hi, Denk
> I've got my Yosemite board today, it's shows very good=20
> by default test.
> I downloaded the 2.6.14 according the repository from your=20
> website by cogito.
> with default configure, I boot with the uImage, but the=20
> system halt, attachment is the message.
> I don't know what happen with it, pls help me.
>=20
> Thanks a lot!
>=20
> Kylong Mu
>=20
^ permalink raw reply
* Re: compact flash driver
From: mcr @ 2005-11-02 16:06 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964158496E9@xmb-sjc-212.amer.cisco.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Alex" == Alex Zeffertt <ajz@cambridgebroadband.com> writes:
>Do you have an early release code? I can start to work at.
I have to merge code into the torsvalds tree still.
Priority goes to actually shipping our product :-)
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQ2jj7oqHRg3pndX9AQGCeQP+KaWWyMTz8rlhLALd39vvTQqZkl32k1bq
YEs/0lZrcxwbLEPa4U+8cgc7JFgeJR0aKXr89cnSmgurOs2pzhU9SNdsY75dAywk
oJzC26nf0gXngDtv2YAb9clm2YkZgKuQUt7bQGgjfls8LXnLlQXuuIIchzbRh89K
gDBwa6VnGoY=
=csPz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: onboard pci ethernet controller(i82551)without eprom(linuxppc2.2.4 MPC5200)
From: Joshua Lamorie @ 2005-11-02 15:21 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200510082230.AA69861636@NARI-RELAYS.COM>
=E6=82=A8=E5=A5=BD,
I am using the same chip connected through PCI to a Virtex-II Pro (PPC=20
405). I do not have an EEPROM connected to the chip. However, I am=20
having problem with the code because it seems to be built specifically=20
for processors that have coherent cache. So each time the code tries to =
execute I get a kernel panic. (kernel 2.4.26, with RTAI patch)
This occurs because in many places it executes a bottom-half spin lock=20
before calling pci_free_consistent. This increments the bottom-half=20
counter and so when pci_free_consistent is called it calls BUG(); and=20
the whole thing goes Tango Uniform. I'm about to go through and try to=20
fix this, but it seems like an extremely dangerous thing for me to play=20
with.
I seem to be able to get the eepro100.c code to work, but I was hoping=20
to use the e100 driver to program an EEPROM on the board.
=E8=B0=A2=E8=B0=A2
Joshua
=C3=8F=C3=84=C3=93=C3=AA wrote:
>After i modified e100_init() in e100_main.c , the pci ethernet card coul=
d been found :
>
>bash-2.05b# ifconfig -a
>eth0 Link encap:Ethernet HWaddr FF:FF:FF:FF:FF:FF
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Memory:40000000-40000038
>
>eth1 Link encap:Ethernet HWaddr 00:04:9F:00:15:2B
> inet addr:198.87.102.215 Bcast:198.87.102.255 Mask:255.255.2=
55.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:12606 errors:42 dropped:0 overruns:0 frame:0
> TX packets:7668 errors:3 dropped:0 overruns:3 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:10596597 (10.1 Mb) TX bytes:1218624 (1.1 Mb)
> Interrupt:43
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
>
>But i still could not config eth0:
>
>bash-2.05b# ifconfig eth0 198.87.102.140
>SIOCSIFFLAGS: Resource temporarily unavailable
>
>I noticed that there was message as blow during kernel bootup:
>
>POSIX conformance testing by UNIFIX
>PCI: Probing PCI hardware
>PCI: Cannot allocate resource region 0 of device 00:1a.0
>Linux NET4.0 for Linux 2.4
>
>Intel(R) PRO/100 Network Driver - version 2.3.38-k1
>Copyright (c) 2004 Intel Corporation
>
>PCI: Enabling device 00:18.0 (0006 -> 0007)
>e100: eth0: Intel(R) PRO/100 Network Connection
>Hardware receive checksums enabled
>
>IP-Config: Failed to open eth0
>
>what is wrong?
>
>Best regards
>
>Xiayu
>
>
>
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> =20
>
--=20
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
^ permalink raw reply
* Re: About 2.6.14 on AMCC Yosemite board
From: Wolfgang Denk @ 2005-11-02 16:46 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051102135009.27C46102A@smtp.263.net>
Dear Kylong Mu,
in message <20051102135009.27C46102A@smtp.263.net> you wrote:
>
> I've got my Yosemite board today, it's shows very good by default test.
> I downloaded the 2.6.14 according the repository from your website by cogito.
> with default configure, I boot with the uImage, but the system halt, attachment
> is the message.
> I don't know what happen with it, pls help me.
...
> DRAM: 256 MB
> FLASH: 32 MB
---------^^^^^
That's the problem. The board we got from AMCC for the port and for
testing all had 64 MB flash, and there was no information that other
configurations are available too. The MTD mapping driver ist a bit
braindead at the moment and assumes 64 MB. This fails on your board.
The quick and dirty fix is to edit "drivers/mtd/maps/yosemite.c" and
replace the lines:
...
31
32 #define WINDOW_ADDR 0xfc000000
33 #define WINDOW_SIZE 0x04000000
34
...
with:
#define WINDOW_ADDR 0xFE000000
#define WINDOW_SIZE 0x02000000
We will implement a better fix (automatically adjust values according
to the values pased by the boot loader) later today / early tomorrow.
Sorry for the inconvenience.
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
If you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
^ permalink raw reply
* [PATCH] ppc - fix build warnings in arch/ppc/kernel/traps.c
From: Becky Bruce @ 2005-11-02 16:52 UTC (permalink / raw)
To: linuxppc-dev
ppc: Fix build warnings in traps.c
The latest updates to bug.h generate build warnings in traps.c in
arch/ppc. Fix print format specifiers to account for change of line type
to long from int.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit fdbe8ff0c9719da6bcbe6fedf10fb3d32c09ec92
tree 6330b8c00cd62dab8b58cd8808619cf3a1d44f69
parent 211317f02e1d2ac3ebd5bf139889160c834573da
author Becky Bruce <becky.bruce@freescale.com> Wed, 02 Nov 2005 10:47:59 -0600
committer Becky Bruce <becky.bruce@freescale.com> Wed, 02 Nov 2005 10:47:59 -0600
arch/ppc/kernel/traps.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
index f265b81..16adde6 100644
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -606,22 +606,22 @@ int check_bug_trap(struct pt_regs *regs)
if (bug->line & BUG_WARNING_TRAP) {
/* this is a WARN_ON rather than BUG/BUG_ON */
#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%d\n",
+ xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
bug->function, bug->file,
bug->line & ~BUG_WARNING_TRAP);
#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%d\n",
+ printk(KERN_ERR "Badness in %s at %s:%ld\n",
bug->function, bug->file,
bug->line & ~BUG_WARNING_TRAP);
dump_stack();
return 1;
}
#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%d!\n",
+ xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
bug->function, bug->file, bug->line);
xmon(regs);
#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%d!\n",
+ printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
bug->function, bug->file, bug->line);
return 0;
^ permalink raw reply related
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 16:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.17408.247708.622755@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 15:43 +1100, Paul Mackerras wrote:
> Those errors were all due to getting powerbook sleep code included
> because you have CONFIG_PM=y. I have changed things so that that code
> doesn't get included on a 64-bit build (at least until BenH gets sleep
> going on the G5 :).
OK, now the Fedora rawhide kernel builds for ppc64 with arch/powerpc and
runs on both my POWER5 and G5 test boxes. I need this if I want nvram
support on the G5 though.
Should we be using CONFIG_GENERIC_NVRAM on ppc64, and actually allowing
the nvram support to be optional?
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -351,7 +350,7 @@ void __init pmac_setup_arch(void)
find_via_pmu();
smu_init();
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_NVRAM) || defined(CONFIG_PPC64)
pmac_nvram_init();
#endif
--
dwmw2
^ permalink raw reply
* [PATCH] ppc32 8xx: export symbols required for modular IDE
From: Marcelo Tosatti @ 2005-11-02 14:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
diff-tree 6ace3f3688d39df333975c0a1257f6364975b75f (from eea4169e9343e5e464355a442eca5c5cd6f3485e)
Author: Marcelo Tosatti <marcelo@pegasos.cnet>
Date: Tue Oct 25 17:12:43 2005 -0500
ppc32 8xx: export symbols required for modular IDE
Building modules, stage 2.
MODPOST
*** Warning: "__ide_mm_insl" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_outsw" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_insw" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_outsl" [drivers/ide/ide-core.ko] undefined!
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 2ccb58f..5152db8 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -136,6 +136,11 @@ EXPORT_SYMBOL(outw);
EXPORT_SYMBOL(outl);
EXPORT_SYMBOL(outsl);*/
+EXPORT_SYMBOL(__ide_mm_insl);
+EXPORT_SYMBOL(__ide_mm_outsw);
+EXPORT_SYMBOL(__ide_mm_insw);
+EXPORT_SYMBOL(__ide_mm_outsl);
+
EXPORT_SYMBOL(_insb);
EXPORT_SYMBOL(_outsb);
EXPORT_SYMBOL(_insw);
^ permalink raw reply related
* [PATCH] ppc32 8xx: Fix harmless warning in 8xx_io/commproc.c
From: Marcelo Tosatti @ 2005-11-02 14:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
diff-tree eea4169e9343e5e464355a442eca5c5cd6f3485e (from 3fff5da0af579a9cfadedca55dff888cde61b954)
Author: Marcelo Tosatti <marcelo@pegasos.cnet>
Date: Tue Oct 25 17:10:10 2005 -0500
Fix harmless warning in 8xx_io/commproc.c
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
index 5bbb8e2..973e609 100644
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -83,6 +83,8 @@ extern uint m8xx_cpm_hostalloc(uint size
extern int m8xx_cpm_hostfree(uint start);
extern void m8xx_cpm_hostdump(void);
+extern void cpm_load_patch(volatile immap_t *immr);
+
/* Buffer descriptors used by many of the CPM protocols.
*/
typedef struct cpm_buf_desc {
^ permalink raw reply related
* [PATCH] ppc32 8xx: fix cpm_dpalloc() comment
From: Marcelo Tosatti @ 2005-11-02 14:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
Current comment on top of m8xx_cpm_dpinit is wrong.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 18fa51c..4306deb 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -390,9 +390,8 @@ void m8xx_cpm_dpinit(void)
/*
* Allocate the requested size worth of DP memory.
- * This function used to return an index into the DPRAM area.
- * Now it returns the actuall physical address of that area.
- * use m8xx_cpm_dpram_offset() to get the index
+ * This function returns an offset into the DPRAM area.
+ * Use cpm_dpram_addr() to get the virtual address of the area.
*/
uint cpm_dpalloc(uint size, uint align)
{
^ permalink raw reply related
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-02 9:50 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200511020055.58010.pantelis.antoniou@gmail.com>
On Wed, Nov 02, 2005 at 12:55:57AM +0200, Pantelis Antoniou wrote:
> On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> > On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > > Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> > > address fixes the problem.
> >
> > Hi Panto,
> >
> > Its working fine around here. How much of a vanilla 2.6.14 your is?
> >
> > [root@CAS root]# cat /proc/cpuinfo
> > processor : 0
> > cpu : 8xx
> > clock : 48MHz
> > bus clock : 48MHz
> > revision : 0.0 (pvr 0050 0000)
> > bogomips : 47.82
> > [root@CAS root]# uname -a
> > Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
> >
> >
>
> Vanila 2.6.14 worked fine too.
>
> It's the mm patches that started coming in later.
> Unfortunately the version did not change, so I can't provide it.
> Did you used a current git tree?
No I did not - will do and chase the bug.
Thanks.
^ permalink raw reply
* [PATCH] ppc32: Fixed warning
From: Vitaly Bordug @ 2005-11-02 19:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 153 bytes --]
This adds missing header and thus fix the warning issued by ming prototype.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 8xx_setup.patch --]
[-- Type: text/x-patch, Size: 289 bytes --]
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -45,6 +45,7 @@
#include <asm/bootinfo.h>
#include <asm/time.h>
#include <asm/xmon.h>
+#include <asm/ppc_sys.h>
#include "ppc8xx_pic.h"
^ permalink raw reply
* SM501 Frame Buffer driver on PPC
From: Absolut Hunter @ 2005-11-03 1:40 UTC (permalink / raw)
To: linuxppc-embedded
All,
I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
board. Using the Denx Kernel 2.4.25 I see that most of this is already
included in the kernel.
However a few questions:
The TQM5200 Board uses this driver, but I am gathering this is a PCI based
video setup?; Our board uses a local bus memory interface. I.e. we have
setup the SM501 to be in the SH-3/4 Slave mode.
We have dedicated 32Megs of Video memory to be local only to the SM501, and
mapped it to 0xF8000000 on /CS6, placing the registers at 0xFBE00000
Anyway, I have the UPMA machine setup to communicate with the SM501 and have
verified basic communication with registers, etc.. When using Linux the
kernel Oops's when register_framebuffer is called. I have setup the
voyager.h file to use the correct addresses.
Has anyone used the SM501 driver with this type of NON-Unified memory
architecture? I am guessing this can be confusing to the driver since the
frame buffer registers inside the SM501 need to be using offset ZERO instead
of the 0xF8000000 like the MPC8280 sees.
Thanks,
-Russell McGuire
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Dan Malek @ 2005-11-03 4:30 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <000901c5e017$91aef880$6405a8c0@absolut>
On Nov 2, 2005, at 8:40 PM, Absolut Hunter wrote:
> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture?
What do you mean, non-unified?
> I am guessing this can be confusing to the driver since the
> frame buffer registers inside the SM501 need to be using offset ZERO
> instead
> of the 0xF8000000 like the MPC8280 sees.
The SM501 PCI driver assumes the addresses are from the PCI
base address, not from zero. Properly using the local bus address
in a similar way should work just fine.
Thanks.
-- Dan
^ permalink raw reply
* 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-03 6:33 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org; +Cc: linuxppc-dev list
For those who experience crashes on sleep and/or wakeup (typically due
to USB) with 2.6.14, I made a test patch that might help. Please let me
know if it makes things more reliable.
http://gate.crashing.org/~benh/fix-ohci-sleep.diff
Note that the patch is totally untested here so it may be just plain
bogus :)
Ben.
^ permalink raw reply
* RE: SM501 Frame Buffer driver on PPC
From: Martin Krause @ 2005-11-03 8:19 UTC (permalink / raw)
To: Absolut Hunter, linuxppc-embedded
Hi Russell,
Absolut Hunter wrote on Thursday, November 03, 2005 2:40 AM:=20
> The TQM5200 Board uses this driver, but I am gathering this is a PCI
> based=20
> video setup?; Our board uses a local bus memory interface. I.e. we
> have=20
> setup the SM501 to be in the SH-3/4 Slave mode.
On the TQM5200 the SM501 is connected over the local bus, not over
PCI. The SH-4 Interface is used.
> We have dedicated 32Megs of Video memory to be local only to the
> SM501, and mapped it to 0xF8000000 on /CS6, placing the registers at
> 0xFBE00000=20
>=20
> Anyway, I have the UPMA machine setup to communicate with the SM501
> and have verified basic communication with registers, etc.. When
> using Linux the=20
> kernel Oops's when register_framebuffer is called. I have setup the
> voyager.h file to use the correct addresses.
Yes,
#define FB_PHYSICAL_ADDR 0xF8000000
#define REG_PHYSICAL_ADDR 0xFBE00000=20
should do the job (if the addresses are correct).
> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture? I am guessing this can be confusing to the driver since
> the=20
> frame buffer registers inside the SM501 need to be using offset ZERO
> instead=20
> of the 0xF8000000 like the MPC8280 sees.
I'm not sure, what you mean with NON-Unified memory. Note that the
TQM5200 uses the memory integrated in the SM501 as framebuffer. So
the SM501 is configured to use internal memory. If you want to use=20
external memory, you have to change the SM501 initialisation. Take
a look at the DRAM Control register of the SM501. Pin GPIO12 is
used during reset to enable or disable "Embedded Memory Control".
Please note, that the framebuffer driver does all register accesses
32-bit wide. Make sure your hardware supports this.
Maybe you have to change endianness (little/big).
Regards,
Martin
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrişor @ 2005-11-03 9:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1130999620.4680.28.camel@gaston>
On 11/3/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> For those who experience crashes on sleep and/or wakeup (typically due
> to USB) with 2.6.14, I made a test patch that might help. Please let me
> know if it makes things more reliable.
>
> http://gate.crashing.org/~benh/fix-ohci-sleep.diff
So this supposed to work with the USB sleep support enabled, right?
If this works then I will be very thankful!
I hope I have the time to test this patch this evening.
> Note that the patch is totally untested here so it may be just plain
> bogus :)
No problem.
AIUI, this should allow me to put my PB 5,2 to sleep while a usb stick
is mounted and come back from sleep with no problem and the stick to
be still mounted, right?
--
Regards,
EddyP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Clemens Koller @ 2005-11-03 11:00 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <000901c5e017$91aef880$6405a8c0@absolut>
Hello, Russell,
> I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
> board. Using the Denx Kernel 2.4.25 I see that most of this is already
> included in the kernel.
I am using the SM501 on PCI on Kernel 2.6 and updated several things in the
driver - not really the same contstruction area as you are working on.
But if you need some code, please let me know (off-list). I posted some things
in the past in this list and on fb-devel, too - just have a look.
The endianess on PCI on ppc is still an issue (I haven't investigated this
problem further during the last month).
I hope that I'll find some time to setup a webpage to publish that
stuff, soon...
Best regards,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Mark Chambers @ 2005-11-03 14:05 UTC (permalink / raw)
To: Clemens Koller, Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <4369EDD3.1010309@anagramm.de>
> The endianess on PCI on ppc is still an issue (I haven't investigated this
> problem further during the last month).
>
There really shouldn't be an endian issue on SM501 since registers are
32 bit. What we do have is the 5200 that does byte swapping on PCI
for no good reason (IMHO)
--Mark Chambers
^ permalink raw reply
* RE: SM501 Frame Buffer driver on PPC
From: Martin Krause @ 2005-11-03 14:16 UTC (permalink / raw)
To: Mark Chambers, Clemens Koller, Absolut Hunter; +Cc: linuxppc-embedded
Mark Chambers wrote on Thursday, November 03, 2005 3:06 PM:=20
> > The endianess on PCI on ppc is still an issue (I haven't
> > investigated this problem further during the last month).
> >=20
>=20
> There really shouldn't be an endian issue on SM501 since registers are
> 32 bit. What we do have is the 5200 that does byte swapping on PCI
> for no good reason (IMHO)
We experienced a byte swapping issue on the SM501, too, although it
is connected via the local plus bus with the MPC5200 and not via PCI
bus.
In 16 bpp mode bytes appear to be swapped in a very ugly way.
Unfortunately we have no explanation for this, nor a real
workaround.
-- Martin Krause
^ permalink raw reply
* [PATCH] fs_enet build fix
From: Vitaly Bordug @ 2005-11-03 14:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Due to the recent update of the platform code, some platform device
drivers fail to compile. This fix is for fs_enet, adding #include of a
new header, to which a number of platform stuff has been relocated.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: fs_enet_fix.patch --]
[-- Type: text/x-patch, Size: 1349 bytes --]
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -37,6 +37,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <linux/vmalloc.h>
#include <asm/pgtable.h>
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/immap_cpm2.h>
#include <asm/mpc8260.h>
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
^ permalink raw reply
* Re: Board Bringup problem with 2.6.13.4
From: Andrei Konovalov @ 2005-11-02 14:07 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <43688AAD.5050208@comcast.net>
Your problem seems to be due to the CPU_213 errata:
ftp://ftp.xilinx.com/pub/documentation/misc/ppc405f6v5_2_0.pdf, page 22
Best regards,
Andrei
David H. Lynch Jr wrote:
> I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based
> ppc405.
> with memory from 0x0 through 0x7fffffff
>
>
>
> Right now I get:
>
> >Starting MonitorX.elf: V3.3.2.0.
> >
> >loaded at: 00400000 0047F13C
> >board data at: 0047D128 0047D13C
> >relocated to: 00405300 00405314
> >zimage at: 00405A95 0047CE71
> >avail ram: 00480000 08000000
> >
> >Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc
> looptype=squashfs cdroot splash=silentttttt
> >Uncompressing Linux......done.
> >Now booting the kernel
>
> I have been able to trace execution into head_4xx.S to immediately
> before turn_on_mmu:
> But immediately after this I lose the ability to trace.
>
> I have been tracing things with a status port at 0x70000000 I can write
> to and read from the host side with code like
>
> lis r14,0x7000 /* debugging port */
> li r15,0x2305 /* value to output */
> stw r15,4(r14) eieio
>
> after turn_on_mmu executes this does not seem to work.
> looking at other code it appeared that I needed to add
> tophy(r14,r14) prior to the stw
> but that does not seem to help.
>
> What do I need to do to be able to continue to use my debug port ?
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH 2.6.14] ppc32: Allow for bigger compressed kernels
From: Tom Rini @ 2005-11-03 18:32 UTC (permalink / raw)
To: linuxppc-dev, Andrew Morton
The ppc (not ppc64) boot loader (zimage wrapper) has a hard coded limit of
4 MB on the size of an uncompressed kernel it can boot. The boot loader has
been changed to dynamically determine the largest possible kernel and
support it. Relocating the boot loader to a higher address (currently
located at 8 MB) will provide additional room.
Signed-off-by: Mark Bellon <mbellon@mvista.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
diff --git a/arch/ppc/boot/simple/misc.c b/arch/ppc/boot/simple/misc.c
--- a/arch/ppc/boot/simple/misc.c
+++ b/arch/ppc/boot/simple/misc.c
@@ -7,10 +7,10 @@
* your serial console. If a machine meets these requirements, it can quite
* likely use this code during boot.
*
- * Author: Matt Porter <mporter@mvista.com>
+ * Author: Tom Rini <trini@mvista.com>
* Derived from arch/ppc/boot/prep/misc.c
*
- * 2001 (c) MontaVista, Software, Inc. This file is licensed under
+ * 2001-2005 (c) MontaVista, Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
@@ -56,6 +56,11 @@
#define INTERACTIVE_CONSOLE 1
#endif
+#define ONE_MB (1 << 20)
+#define MAX_BI_RECS (8 * 1024)
+#define MAX_AVAIL_MEM (4 * ONE_MB)
+#define RAM_RESERVE (4 * ONE_MB)
+
char *avail_ram;
char *end_avail;
char *zimage_start;
@@ -97,7 +102,8 @@ decompress_kernel(unsigned long load_add
#endif
char *cp;
struct bi_record *rec;
- unsigned long initrd_loc = 0, TotalMemory = 0;
+ unsigned long initrd_loc, TotalMemory;
+ unsigned long max_kernel, top_free;
#if defined(CONFIG_SERIAL_8250_CONSOLE) || defined(CONFIG_SERIAL_MPSC_CONSOLE)
com_port = serial_init(0, NULL);
@@ -119,9 +125,6 @@ decompress_kernel(unsigned long load_add
*/
TotalMemory = get_mem_size();
- /* assume the chunk below 8M is free */
- end_avail = (char *)0x00800000;
-
/*
* Reveal where we were loaded at and where we
* were relocated to.
@@ -153,7 +156,6 @@ decompress_kernel(unsigned long load_add
* The zImage and initrd will be between start and _end, so they've
* already been moved once. We're good to go now. -- Tom
*/
- avail_ram = (char *)PAGE_ALIGN((unsigned long)_end);
puts("zimage at: "); puthex((unsigned long)zimage_start);
puts(" "); puthex((unsigned long)(zimage_size+zimage_start));
puts("\n");
@@ -164,11 +166,51 @@ decompress_kernel(unsigned long load_add
puts(" "); puthex((unsigned long)(&__ramdisk_end));puts("\n");
}
- avail_ram = (char *)0x00400000;
- end_avail = (char *)0x00800000;
+ /*
+ * If there is sufficent memory move the available RAM area after
+ * the zImage (but stay away from the top of RAM). Otherwise fudge
+ * it to fit in below the zImage as it did in the past.
+ */
+
+ top_free = _ALIGN((unsigned long)(_end) + ONE_MB - 1, ONE_MB);
+
+ if ((TotalMemory != 0) &&
+ ((top_free + MAX_AVAIL_MEM + RAM_RESERVE) < TotalMemory)) {
+ avail_ram = (char *) top_free;
+
+ /*
+ * We're linked in the middle of RAM and the kernel starts
+ * at zero. This means that the kernel must fit between
+ * zero and our starting address. Figure out the highest
+ * address below this that will allow a complete
+ * uncompressed kernel and bi_recs to fit - the maximum
+ * kernel size.
+ */
+
+ max_kernel = (unsigned long) &start;
+
+ while (1) {
+ avail_ram = (char *) bootinfo_addr(max_kernel);
+
+ if ((avail_ram + MAX_BI_RECS) < ((char *) &start))
+ break;
+
+ max_kernel -= MAX_BI_RECS;
+ }
+ }
+ else {
+ max_kernel = ((unsigned long) &start) - MAX_AVAIL_MEM;
+ avail_ram = max_kernel;
+ }
+
+ end_avail = avail_ram + MAX_AVAIL_MEM;
+
puts("avail ram: "); puthex((unsigned long)avail_ram); puts(" ");
puthex((unsigned long)end_avail); puts("\n");
+ /* Document the limitation */
+ puts("max kernel: "); puthex(max_kernel); puts("\n");
+
if (keyb_present)
CRT_tstc(); /* Forces keyboard to be initialized */
#ifdef CONFIG_GEMINI
@@ -222,32 +264,12 @@ decompress_kernel(unsigned long load_add
puts("\n");
puts("Uncompressing Linux...");
- gunzip(NULL, 0x400000, zimage_start, &zimage_size);
+ gunzip(NULL, max_kernel, zimage_start, &zimage_size);
puts("done.\n");
/* get the bi_rec address */
rec = bootinfo_addr(zimage_size);
- /* We need to make sure that the initrd and bi_recs do not
- * overlap. */
- if ( initrd_size ) {
- unsigned long rec_loc = (unsigned long) rec;
- initrd_loc = (unsigned long)(&__ramdisk_begin);
- /* If the bi_recs are in the middle of the current
- * initrd, move the initrd to the next MB
- * boundary. */
- if ((rec_loc > initrd_loc) &&
- ((initrd_loc + initrd_size) > rec_loc)) {
- initrd_loc = _ALIGN((unsigned long)(zimage_size)
- + (2 << 20) - 1, (2 << 20));
- memmove((void *)initrd_loc, &__ramdisk_begin,
- initrd_size);
- puts("initrd moved: "); puthex(initrd_loc);
- puts(" "); puthex(initrd_loc + initrd_size);
- puts("\n");
- }
- }
-
bootinfo_init(rec);
if ( TotalMemory )
bootinfo_append(BI_MEMSIZE, sizeof(int), (void*)&TotalMemory);
@@ -258,7 +280,7 @@ decompress_kernel(unsigned long load_add
if (initrd_size) {
unsigned long initrd[2];
- initrd[0] = initrd_loc;
+ initrd[0] = (unsigned long)(&__ramdisk_begin);
initrd[1] = initrd_size;
bootinfo_append(BI_INITRD, sizeof(initrd), &initrd);
--
Tom Rini
http://gate.crashing.org/~trini/
^ 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