* Platform devices on MPC8245
From: Mark Brown @ 2005-08-31 12:26 UTC (permalink / raw)
To: linuxppc-embedded
I'm having some trouble using the platform device support for the
MPC8245 using memory map B, set up using mpc10x_bridge_init(). When
that function registers the host bridge it registers addresses
0x80000000-0xfebfffff for the bridge but by default (with EUMB mapped to
MPC10X_MAPB_EUMB_BASE) the platform devices on the chip are also within
this address range. The problem I'm seeing is that when
platform_device_register() comes to call request_resource() on the
devices that call fails because the addresses have already been
allocated to the PCI host bridge.
I'm sure I must be missing something really obvious about how this is
supposed to work but I can't for the life of me see what. Changing the
platform code to use insert_resource() rather than request_resource()
allows the devices to register and be used but that seems rather too
drastic to be it.
Thanks for any help.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: Mapping huge user buffers for DMA
From: Clemens Koller @ 2005-08-31 14:03 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <431496FC.3090208@icarus.com>
Hello, Stephen!
Please have a look at the whole thread around my posts at:
http://lkml.org/lkml/2005/8/4/201
I am working on an mpc8540 (e500) ppc and we are pushing
data from the local bus directly to the userspace
mlock()ed memory with the dma engine, using scatter/gather
(chaining and page/chunk-defragmentation/compression) transfers.
Currently, I send the application's user virtual and mlock()ed
address to the kernel driver through an ioctl and do an iopa()
at the user virtual addresses (pages) to get to the physical
addresses (pages). The system works stable and we can fill up
the whole memory (192MByte) with currently 144MByte/s
(still improvements possible).
If you are interested in our design, feel free to contact
me directly.
Greets,
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
Stephen Williams wrote:
>
> I have a PPC405GPr system with an image processing device, that
> is creating potentially huge amounts of data. In one setup I
> have a 256Meg system, and I'm trying to map a 192Meg destination
> buffer using map_user_kiovec and an array of kiobufs.
>
> I'm finding, however, that I'm getting an Oops in map_user_kiovec
> when it tries this, and I'm wondering where I need to look for
> any limits I might be overrunning.
>
> Also, I've been considering skipping kiobufs all together and
> instead using code like this (lifted from map_user_kiobuf)
>
> /* Try to fault in all of the necessary pages */
> down_read(&mm->mmap_sem);
> /* rw==READ means read from disk, write into memory area */
> err = get_user_pages(current, mm, va, pgcount,
> (rw==READ), 0, iobuf->maplist, NULL);
> up_read(&mm->mmap_sem);
>
> to get the user pages directly. This is really what I want, and
> I do not need the other functionality of kiobufs. Is the
> get_user_pages function kosher for use by drivers? Is there
> a limit to what get_user_pages may map?
>
>
^ permalink raw reply
* Re: Did anybody use netatalk on ppc??
From: Clemens Koller @ 2005-08-31 14:15 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linux-ppc-embedded
In-Reply-To: <20050831090821.4D4ED681F2@ozlabs.org>
Hello, Johnson!
Advice?
This is the wrong list for questions like this, I guess.
However we run netatalk also on our systems (mostly ix86)
on an utf-8 reiserfs filesystem and we used convmv to
solve some character translation issues to/from non-utf-8
filesystems.
You might want to check with google and the netatalk
lists.
Greets,
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
JohnsonCheng wrote:
> Dear All,
>
>
>
> I have used netatalk2.0.3 with Unicode on x86, it's no problem.
>
> Then I port it to ppc board, compiler is OK and also can running.
>
> Unfortunately, I have trouble on Unicode issue, I found it doesn't work.
>
> Does someone give me some advice??
>
>
>
>
>
> Thanks,
>
> Johnson Cheng
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Andrey Volkov @ 2005-08-31 15:50 UTC (permalink / raw)
To: Sylvain Munaut, Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <4309D3CF.4030201@246tNt.com>
Hello Sylvain, Wolfgang
Sorry for silence, I was out of office last week.
(And will be absent at next two weeks too).
Wolfgang, first question to you:
May be you are know where I could find (if it exist)
BestComm (SmartComm) API for mystic MGT5100?
Sylvain Munaut wrote:
>
> But I'm not sure including that into the Documentation/ directory is
> such a good idea. Changing documentation that's there requires sending
> patch to Linus and get it processed etc ... And since It's mostly
> reverse engineering, it's probably going to change often as we get a
> better understanding.
I agree with Wolfgang's opinion: when I seek description of some kernel
part, I'm firstly check Documentation/, next grepping kernel tree.
In any case, when doco will be completed it will not changed often.
>
> We could publish it as a Wiki (that's a tendency these days ;) so that
> everyone can contribute easily and post code examples etc ... What do
> you think ?
Agree, good think. Wolfgang, is it appropriately to use WIKI of denx.de?
> See comments below for the "real" comments ;)
>
>>+[18:17] WS Write Size (see above)
>>+[16:16] ??????????????
>>+[15:15] Destination index prefix,
>>+ if set (i.e. =1), then bitfield [13:10]
>>+ contain index number, and [14:14] have
>>+ meaning of indirect addressing flag.
>>+ If this field cleared then field
>>+ [14:10] contain index of VARIABLE.
>>+[14:14] Indirect addressing by idx,
>>+ (and only by idx) flag, or high bit of
>>+ variable index.
>>+[13:10] index of DESTINATION/SOURCE idx/var.
>>+
>>+[09:09] ???? For some cases 1, for another 0.????
>>+
>>+[08:08] Same as in [14:10], but for source.
>>+[07:03] Same as in [14:10], but for source.
>>+[02:00] EU3 Number of function, which will execute
>>+ on EU#3.
>
>
> [2:0] is FN but what do you exactly mean it is. The only thing I notice
> is that if it =1 then the source is "EU3()" ... whatever that means.
>
> Also, I'm not sure it has something to do with the FDT since there is
> only 3 bits.
With first 7 functions, as I understand. In theory it may be any
function (depend on functions arrangement in FDT).
>>+Note: For DRD1A exist special case, aka NOP, which act as
>>+task terminator. Fields, in this case, have next meanings:
>>+
>>+[31:28] Reserved must be 0.
>>+[27:27] TFD Transfer Frame Done.
>>+[26:26] INT Interrupt.
>>+[25:21] INIT Initiator (aka requestor) number. Usually 0,
>>+ or ALWAYS INITIATOR.
>>+[16:00] NOP code Must be 0x1f8
>
>
> Where did you see that that you could use theses bit in NOP ?
INT - was used in image_rtos1/TASK_PCI_TX for example.
INIT,TFD - my assumption, not sure certainly.
>>+Ex. Please, pay attention to first two lines: since MORE is set,
>>+codes for idx2 and var13 are in different fields, then for case
>>+where MORE is not set (var4 = var2).:
>>+ 0x10601010 -- DRD1A: var4 = var2; FN=0 MORE init=3 WS=0 RS=0
>>+ 0x00008868 -- DRD1A: idx2 = var13; FN=0 init=0 WS=0 RS=0
>>+ 0x0404c999 -- DRD1A: *idx2 = EU3(); FN=1 INT init=0 WS=2 RS=0
>>+ 0x000001f8 -- DRD1A: NOP
>>+ 0x040001f8 -- DRD1A: INT init=0
>>+
>>+Next two DRDs are ALWAYS coupled, i.e it is impossible to using
>>+DRD2B1 without preceded DRD2A, but any (?fixme?) number DRD2B1
>>+may followed by DRD2A.
>
> ? AFAIU it's either
> DRD2A, DRD2B1
> or
> DRD2A, DRDF2B2
Oops, I miss DRD2B2, but then situation become more clean:
DRD2B2 - load accumulator of execution unit.
Then 0x1f code in DRD2B1 OP2 (and may be in OP1) mean EU accumulator.
>>+2) DRD2A - setup bestcomm Execution Unit (EU)
>>+Bitfields encodings:
>>+
>>+Bits num. Name Desc
>>+[31:31] MORE ?????????
>>+[30:29] EXT must be always initialized
>>+ by 3 (binary 11)
>
>
> What I have is that
> [31:29] Always 011 - Indicates a DRD2A.
> [28:28] MORE - Same meaning as before. Just tells if the following
> (here that's the one that is after the corresponding DRD2B{1,2}) DRD is
> in the same loop or if it's in the previous loop level ?
>
>>+[27:27] TFD Transfer Frame Done.
>>+[26:21] INIT Initiator number.
>>+[20:19] RS Read Size
>>+[18:17] WS Write Size
>>+[16:04] reserved, must be 0
>
> They are the function number to use in EU#{0,1,2} but in MPC5200, only
> EU3 is implemented.
I extend description.
>>+[03:00] EU3 Number of function, which will execute
>>+ on EU#3 at DRD2B1 time.
>>+Ex:
>>+ 0x60140002 -- DRD2A: EU3=2 EXT init=0 WS=2 RS=2
>>+
>>+3) DRD2B1 - execute function and store result of it.
>
>
> Can't find the piece if paper where I wrote about DRD2B1 ...
> For DRD2B2 there is only 1 example I know of, so quite hard to deduce
> anything.
Two if be more precisely :), both in CRC16 u-code.
>>+4) LCD - run followed loop microcode, or may be used for checking
>>+some conditions. LCD may be nested (only two levels are supported).
>
> Two levels ? Didn't know that but sure there is no example with 3 levels.
Ok, I remove this sentence, it was born, because I doesn't found
how loops are terminated (as you point, it was absence of bit in
DRD :) ).
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Mark A. Greer @ 2005-08-31 16:04 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev
In-Reply-To: <20050831055934.871E41C00097@mwinf1107.wanadoo.fr>
On Wed, Aug 31, 2005 at 07:55:49AM +0100, Nicolas DET wrote:
> > This is a good idea. I suspect that most of the gain is from
> > turning off snooping and flushing/invalidating the cache explicitly.
> > Implementation-wise, I'd rather we not manipulate the MV643XX_ETH_BAR_?
> > registers directly in the driver. Today that is done in platform
> > setup code. This has promise but needs to be reworked.
>
> Yeah, the point was to have no snooping for this part of the chip.
> The descriptors in SRAM, and the data in DDR. This give a serious boost.
>
> I noticed MV643xx memory performances are really higher when turning
> off snoop (not only for ethernet).
>
> Well, I confess manipulating such thing here, is not totaly smart.
> However I don't really know where to put them.
> Maybe, somewhere in arch/ppc ?
>
> Because, at some pooint the driver will need to have this modified in order
> to reall work correctly.
>
> For example, if you use a module with that option (it will disable
> snooping) and then 'rmmod & modprobe' a new module without it will not work
> (no snooping as the new module expect!).
>
> Conclusion: yes, touching ETH_BAR isn't really well here, but where could
> we move it ?
The enet->mem BARs are configured in
arch/ppc/syslib/mv64xc60.c:mv64360_config_io2mem_windows().
You can choose how the BAR reg is configured via the mv64x60_setup_info's
'enet_options' member. The setup_info is passed in from your platform file
via mv64x60_init() at setup_arch() time. There are examples arch/ppc/platforms.
The enet->sram window can be set up any way you want it in the platform
file as well. Again, there are examples in arch/ppc/platforms.
IMHO, the platform file should be where things like that belong.
Mark
^ permalink raw reply
* Re: Remove progress msgs from MMU_init()
From: Mark A. Greer @ 2005-08-31 16:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17173.9962.887710.771803@cargo.ozlabs.ibm.com>
On Wed, Aug 31, 2005 at 01:41:30PM +1000, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > Does anyone object to this patch?
>
> Seems fine to me. Those progress calls are only for debugging.
Thanks Paul.
I'll send the patch to Andrew as soon as the next -mm patch comes out.
Mark
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Mark A. Greer @ 2005-08-31 16:17 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050831160417.GA3848@mag.az.mvista.com>
On Wed, Aug 31, 2005 at 09:04:17AM -0700, Mark A. Greer wrote:
> The enet->mem BARs are configured in
> arch/ppc/syslib/mv64xc60.c:mv64360_config_io2mem_windows().
Doh, that should be arch/ppc/syslib/mv64x60.c:...
> IMHO, the platform file should be where things like that belong.
Should be, "IMHO, the platform file *is* where things like that belong."
Mark
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Sven Luther @ 2005-08-31 16:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050831160417.GA3848@mag.az.mvista.com>
On Wed, Aug 31, 2005 at 09:04:17AM -0700, Mark A. Greer wrote:
> On Wed, Aug 31, 2005 at 07:55:49AM +0100, Nicolas DET wrote:
> > > This is a good idea. I suspect that most of the gain is from
> > > turning off snooping and flushing/invalidating the cache explicitly.
> > > Implementation-wise, I'd rather we not manipulate the MV643XX_ETH_BAR_?
> > > registers directly in the driver. Today that is done in platform
> > > setup code. This has promise but needs to be reworked.
> >
> > Yeah, the point was to have no snooping for this part of the chip.
> > The descriptors in SRAM, and the data in DDR. This give a serious boost.
> >
> > I noticed MV643xx memory performances are really higher when turning
> > off snoop (not only for ethernet).
> >
> > Well, I confess manipulating such thing here, is not totaly smart.
> > However I don't really know where to put them.
> > Maybe, somewhere in arch/ppc ?
> >
> > Because, at some pooint the driver will need to have this modified in order
> > to reall work correctly.
> >
> > For example, if you use a module with that option (it will disable
> > snooping) and then 'rmmod & modprobe' a new module without it will not work
> > (no snooping as the new module expect!).
> >
> > Conclusion: yes, touching ETH_BAR isn't really well here, but where could
> > we move it ?
>
> The enet->mem BARs are configured in
> arch/ppc/syslib/mv64xc60.c:mv64360_config_io2mem_windows().
Which is not used in the pegasos code path, as we are chrp though.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Mark A. Greer @ 2005-08-31 17:07 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050831163313.GA25391@localhost.localdomain>
On Wed, Aug 31, 2005 at 06:33:13PM +0200, Sven Luther wrote:
> Which is not used in the pegasos code path, as we are chrp though.
I wondered that after I sent the email. So, yep, chrp_pegasos_eth.c
seem reasonable to me.
Mark
^ permalink raw reply
* Re: ??: Question about SMC serial port on MPC8270 in u-boot
From: Wolfgang Denk @ 2005-08-31 20:36 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E865068@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E865068@ydmail.sbell.com.cn> you wrote:
>
> Now the UART can work. But another question comes :
> The u-Boot reboot forever when enter
...
I already told you that such questions are off topic here. Please ask
on the U-Boot mailinglist instead. But read the FAQ before posting.
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
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Wolfgang Denk @ 2005-08-31 20:46 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <4315D1DC.1000607@varma-el.com>
Dear Andrey,
in message <4315D1DC.1000607@varma-el.com> you wrote:
>
> Wolfgang, first question to you:
> May be you are know where I could find (if it exist)
> BestComm (SmartComm) API for mystic MGT5100?
We did not test the current code on the Icecube with the 5100, but
previous versions used to run fine (well, within the limitations of
the 5100, that is). So if the current code on our CVS server does not
run, just check out an oder version. You can search the history of
changes for example here:
http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git
like that:
http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git&a=search&s=bestcomm
> Agree, good think. Wolfgang, is it appropriately to use WIKI of denx.de?
Yes, of course. Just let me know what you want and we can create a
new web (I don't see any good existing place where this fits).
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
"The number of Unix installations has grown to 10, with more
expected." - The Unix Programmer's Manual, 2nd Edition, June, 1972
^ permalink raw reply
* Re: linuxppc-2.4.30-pre1 crashes with root fs on Xilinx SystemACE
From: Tony Lee @ 2005-09-01 1:11 UTC (permalink / raw)
To: Peter Ryser; +Cc: linuxppc-embedded
In-Reply-To: <4313FA43.1040206@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
Keith,
Some suggestions, before you verify your hw board/FPGA works fine with
SYSACE,
* don't use sysace as root fs.
* use a ram fs as root fs.
* Next, load sysace driver a loadable driver module. It works, I tried it.
* check mount read only and see if it works.
* Next, mount it writable.
We have some issues with sysace driver initially, everything works out fine
later.
There were small errors in our HW layout.
I had to hack the sysace driver left and right to id the problem. But at the
end, after I fixed the layout problem from the fpga's ucf file, the original
driver
run perfectly without any modification.
In my experiences, the ppc linux distribution and its linux sysace driver
are good
if everything is setup correctly.
One minor issues: The sysace driver's write performance sucks. I have to
explain
to others why the upgrade 10 MBytes files with usb flash writer takes tens
of
seconds. When we do it from linux (nfs or ftp), it tooks minutes to sync.
Peter, maybe you can push the xilinx a bit on sysace write performance? :-)
-Tony
On 8/29/05, Peter Ryser <peter.ryser@xilinx.com> wrote:
>
> Hi Keith,
>
> I sent you a private email but for other interested people:
> Downloading the latest linuxppc-2.4 kernel I could boot from and access
> System ACE CF without problems on a ML403 (Virtex-4, 4VFX12) and a ML310
> (Virtex-II Pro, 2VP30) using EDK 7.1.2. In both cases I started with
> config_xilinx_ml300.
>
> - Peter
>
>
>
> Keith J Outwater wrote:
>
> >Hello -
> >Per a previous suggestion from this list, I rsynced the linuxppc-2.4
> >kernel sources from MontaVista and modified the kernel to run on my
> custom
> >ppc405/VirtexII Pro based system with U-Boot as the bootloader.
> >When I try to use the SystemACE device as the root filesystem, the kernel
> >crashes with a sig 11. Looking at the 'oops' output it appears the
> >SystemACE driver may be to blame. The crash is random - sometimes I get
> >all the way to login as root and then things crash on a file copy or a
> >file read.
> >Before I start digging deeper, is anyone running a VirtexIIPro based
> >system with the root filesystem in the CF card attached to a SystemACE?
> >I'm wondering if I really have the best kernel and SystemACE driver.
> >BTW, I'm developing the hardware design using Xilinx EDK 7.02i.
> >Thanks,
> >Keith
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
-Tony
Having fun with FPGA HW + ppc + Linux
[-- Attachment #2: Type: text/html, Size: 3732 bytes --]
^ permalink raw reply
* Machine check - D-Cache search parity error occurs on a ppc440 core
From: Shawn Jin @ 2005-09-01 1:49 UTC (permalink / raw)
To: ppcembed
Hi,
When the kernel starts /sbin/init, a machine check occurs showing it's
a d-cache search parity error. The CPU is a ppc440 core.
What usually causes this kind of exception? The user's manual of 440
core lists three possible situation where such an exception will
occur.
1) Multi-hit parity error on any instr that does a CAM lookup
2) Tag or data parity errors on load instr
3) Tag parity erros on dcbf, dcbi, dcbst instr
Both 1) and 3) are excluded in this case because the internal cpu core
signals show dcrTagEvenSearchParityError is set. Why did this error
happen? It's a cpu bug?
Anyone has seen this error before? Please share your experience.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 72k init
Machine check in kernel mode.
D-Cache Search Parity Error
Oops: machine check, sig: 7 [#1]
NIP: C0000D20 LR: 30001BA8 SP: 7FFFFC80 REGS: c00e5f50 TRAP: 0202 Not ta=
inted
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK =3D c016cab0[1] 'init' THREAD: c1fca000
Last syscall: 11=20
GPR00: 00000001 7FFFFC80 00000000 00000000 AAAA0000 30025160 30024B18 00000=
DF8=20
GPR08: 30024B80 0000012A 0000037E 30000AC8 00000254 00000000 02004D00 00000=
000=20
GPR16: 00000000 00000001 FFFFFFFF 01FFDF58 00000000 007FFF00 00000003 7FFFF=
F10=20
GPR24: 00000002 7FFFFC90 300002C4 7FFFFC88 3000195C 30000000 C00011C8 30001=
8C0=20
NIP [c0000d20] DataTLBError+0x0/0xa0
LR [30001ba8] 0x30001ba8
Kernel panic - not syncing: Attempted to kill init!
Best regards,
-Shawn.
^ permalink raw reply
* PayPal Account Security Measures
From: service @ 2005-09-01 1:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1860 bytes --]
^ permalink raw reply
* PayPal Account Security Measures
From: service @ 2005-09-01 1:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1860 bytes --]
^ permalink raw reply
* linux hangs after uncompress kernel image
From: lily @ 2005-09-01 3:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
i work on octobusHPPC405EP board . when I try to bring up the kernel i meet the problem that linux hangs after uncompressing image:
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
=>iminfo 1000000
## Checking Image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
<hang>
what's the problem??
[-- Attachment #2: Type: text/html, Size: 2273 bytes --]
^ permalink raw reply
* A question regarding ramdisks
From: Adrian B. Weissman @ 2005-09-01 5:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello:
I am having some configuration / problems with
using a ramdisk and the 2.6.12 Kernel for a ppc 7447A
processor, using u-boot version 0.3.0
Here is what I am doing, I make uImage, after
configuring ramdisk support
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RAMFS=y
I then set my bootargs in uboot to
root=/dev/ram rw
I then load my kernel and ramdisk image into
memory and specify to boot the kernel with the ramdisk
in uboot via
bootm 0x300000 0x10000000
The following is the output:
U-Boot 0.3.0 (Jun 29 2005 - 09:50:51)SKY Computers
1.1.3
CPU: MPC7447A v1.1 @ 1399.650 MHz
BOARD: HDPU_COMPUTE_BLADE SINGLE
BUS: 133300000
DRAM: 512 MB
******************************************************
Please Wait, Scrubbing SDRAM to initialize ECC bits...
******************************************************
FLASH: [65536kB@fc000000] 64 MB
In: serial
Out: serial
Err: serial
Net: ### Error: Phy is not active
mv_enet0
=> bootp
bootp
### Error: Phy is not active
BOOTP broadcast 1
DHCP client bound to address 10.0.0.5
ARP broadcast 1
TFTP from server 10.0.0.254; our IP address is
10.0.0.5
Filename 'adrian/uImage.adr'.
Load address: 0x300000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
done
Bytes transferred = 1661461 (195a15 hex)
=> tftpboot 0x10000000 adrian/ramdisk.img
tftpboot 0x10000000 adrian/ramdisk.img
### Error: Phy is not active
ARP broadcast 1
TFTP from server 10.0.0.254; our IP address is
10.0.0.5
Filename 'adrian/ramdisk.img'.
Load address: 0x10000000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
###############
done
Bytes transferred = 1403903 (156bff hex)
=> bootm 0x300000 0x10000000
bootm 0x300000 0x10000000
## Booting image at 00300000 ...
Image Name: Linux-2.6.12-2_0_2
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 1661397 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 10000000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip
compressed)
Data Size: 1403839 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 1fe47000, end 1ff9dbbf ... OK
Total memory = 512MB; using 1024kB for hash table (at
80400000)
Linux version 2.6.12-2_0_2 (root@1_4_0_0) (gcc version
3.3) #18 Wed Aug 31 16:49:39 EDT 2005
SKY HDPU Compute Blade
Built 1 zonelists
Kernel command line: root=/dev/ram rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
time_init: decrementer frequency = 33.325000 MHz
Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Memory: 514304k available (2388k kernel code, 1264k
data, 132k init, 0k highmem)
Mount-cache hash table entries: 512
scheduling while atomic: swapper/0x00000002/0
Call trace:
[80007b1c] dump_stack+0x18/0x28
[80250614] schedule+0x764/0x768
[80004980] syscall_exit_work+0x108/0x10c
[8037d78c] proc_root_init+0x164/0x170
[80390000] __log_buf+0xb9c/0x8000
[8036a68c] start_kernel+0x18c/0x1c4
[00003a30] 0x3a30
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 2 of PCI bridge 2
SCSI subsystem initialized
Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: MPSC driver $Revision: 1.1.1.1 $
ttyMM0 at MMIO 0xf1008000 (irq = 36) is a MPSC
ttyMM1 at MMIO 0xf1009000 (irq = 38) is a MPSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 2 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
Sky CPU State Driver v1.1
MV-643xx 10/100/1000 Ethernet Driver
eth0: port 0 with MAC address 00:50:c2:1f:10:cd
eth0: RX NAPI Enabled
st: Version 20050312, fixed bufsize 32768, s/g segs
256
physmap flash device: 4000000 at fc000000
phys_mapped_flash: Found 2 x16 devices at 0x0 in
32-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition definition
Creating 6 MTD partitions on "phys_mapped_flash":
0x00000000-0x04000000 : "No FS"
mtd: Giving out device 0 to No FS
0x00000000-0x03400000 : "Root FS"
mtd: Giving out device 1 to Root FS
0x03400000-0x03c00000 : "User FS"
mtd: Giving out device 2 to User FS
0x03c00000-0x03ec0000 : "Kernel Image"
mtd: Giving out device 3 to Kernel Image
0x03ec0000-0x03f00000 : "bootEnv"
mtd: Giving out device 4 to bootEnv
0x03f00000-0x04000000 : "bootROM"
mtd: Giving out device 5 to bootROM
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144
bytes)
TCP: Hash tables configured (established 131072 bind
65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(1,0)
<0>Rebooting in 180 seconds..
However, the kernel is unable to mount the block.
I have tried the following:
1. Setting root=/dev/ram0 rw
2. Setting root=/dev/ram ramdisk_start=0x1fe47000
Thus, spelling out where the ramdisk is unpacked by
uboot to the Kernel.
3. tftpboot 0x10000000 adrian/ramdisk.gz and
root=/dev/ram ramdisk_start=0x10000000, thus loading
the compressed ramdisk right into memory.
4. Combining the ramdisk and kernel image, with a
uboot header via Wolfgang's directions:
http://www.denx.de/twiki/bin/view/DULG/CombiningKernelAndRamdisk
After looking through uboot, there really is no
super custom cpu initialization. And the bootm
command works solid. So I don't think having a
somewhat old version of uboot is the reason. But I
am out of ideas.
1. My question is why don't I see
"RAMDISK: Compressed image found at block 0"
instead of the Kernel Panic? Am I missing some
arguments? noinitrd, ramdisk_start, ramdisk_size,
etc?
2. Does uboot have issues with this processor,
MPX bus, ramdisks? I don't think so, but has anyone
seen an issue with version 0.3.0 of uboot?
3. Also, I am using the SELF ramdisk provided on
Wolfgang Denk's U-boot and Linux guide. ( Thank you
Wolfgang!!!) and am able once booted via nfs to
mount the ramdisk without a problem. Thus, I believe
the ramdisk is ok.
Any pointers, comments, constructive critisism
would be greatly appreciated. And yes, I have read
through several archives quite abit before posting.
A close example of my problem is
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019071.html
However, no solution was posted.
Regards and thanks in advance!
Adrian
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: linux hangs after uncompress kernel image
From: John F Davis @ 2005-09-01 6:58 UTC (permalink / raw)
To: lily; +Cc: linuxppc-embedded-bounces, linuxppc-embedded
In-Reply-To: <000801c5aea9$059f01e0$fa0cc9ca@lcj3bdfa4e34dd>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Hello Lily,
Maybe you could try to put in some printk's and see which line of code
generates an exception.
JD
"lily" <lichanjuan04@st.lzu.edu.cn>
Sent by: linuxppc-embedded-bounces@ozlabs.org
09/01/2005 05:55 AM
To
<linuxppc-embedded@ozlabs.org>
cc
Subject
linux hangs after uncompress kernel image
i work on octobusHPPC405EP board . when I try to bring up the kernel i
meet the problem that linux hangs after uncompressing image:
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33
MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
=>iminfo 1000000
## Checking Image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
<hang>
what's the problem?? _______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3242 bytes --]
^ permalink raw reply
* Re: A question regarding ramdisks
From: Murray.Jensen @ 2005-09-01 7:16 UTC (permalink / raw)
To: Adrian B. Weissman; +Cc: linuxppc-embedded
In-Reply-To: <20050901054650.11322.qmail@web35208.mail.mud.yahoo.com>
On Wed, 31 Aug 2005 22:46:50 -0700 (PDT), "Adrian B. Weissman" writes:
> Here is what I am doing, I make uImage, after
>configuring ramdisk support
>
>CONFIG_BLK_DEV_RAM=y
>CONFIG_BLK_DEV_RAM_COUNT=2
>CONFIG_BLK_DEV_RAM_SIZE=4096
>CONFIG_INITRAMFS_SOURCE=""
>CONFIG_RAMFS=y
Do you have CONFIG_BLK_DEV_INITRD enabled? Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Question about ELDK and i18n...
From: David Jander @ 2005-09-01 8:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am using ELDK-3.1, and I am not getting i18n to work. I have looked at
recent changelog of ELDK and newer (CVS) versions don't seem to fix any bug
in that direction.
The installation seems ok, the locale-files are all there as it seems.
I have tried this as a test:
# LANG=es_ES strace tar
in the output, I can see these relevant lines:
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
- This does not matter.
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
- OK, good. locale.alias is read
open("/usr/lib/locale/es_ES/LC_IDENTIFICATION", O_RDONLY) = 3
- Also looks fine, read the locales identification.
open("/usr/lib/locale/es/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such
file or directory)
- Here I am puzzled. Why? Maybe this is not important.
Then there are no more calls to open or stat with files in "/usr/lib/locale"
nor "/usr/share/locale" as argument, and I can't figure out why. What am I
doing wrong? Is this version of glibc in ELDK broken?
Best regards,
--
David Jander
^ permalink raw reply
* Re: [PATCH] MPC8xx PCMCIA driver
From: Dominik Brodowski @ 2005-09-01 8:53 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Russell King, linux-kernel, linux-ppc-embedded
In-Reply-To: <20050830024840.GA5381@dmt.cnet>
Hi,
On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> Russell: The driver is using pccard_nonstatic_ops for card window
> management, even though the driver its marked SS_STATIC_MAP (using
> mem->static_map).
This is obviously broken. Where does it fail if pccard_static_ops is used?
> +typedef struct {
> + u_int regbit;
> + u_int eventbit;
> +} event_table_t;
No typedefs, please.
Dominik
^ permalink raw reply
* Re: Question about ELDK and i18n...
From: Wolfgang Denk @ 2005-09-01 9:18 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200509011009.24114.david.jander@protonic.nl>
Dear David,
in message <200509011009.24114.david.jander@protonic.nl> you wrote:
>
> I am using ELDK-3.1, and I am not getting i18n to work. I have looked at
> recent changelog of ELDK and newer (CVS) versions don't seem to fix any bug
> in that direction.
There is no fix yet, but the problem is known :-(
> The installation seems ok, the locale-files are all there as it seems.
No.
> I have tried this as a test:
>
> # LANG=es_ES strace tar
>
> in the output, I can see these relevant lines:
>
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> - This does not matter.
It does. For the setlocale() call to succeed, an additional file is
needed, apart from the locale files themselves. It is a
locale-archive file in the /usr/lib/locale directory on the target.
This file is still missing in the ELDK glibc RPM.
> open("/usr/share/locale/locale.alias", O_RDONLY) = 3
>
> - OK, good. locale.alias is read
>
> open("/usr/lib/locale/es_ES/LC_IDENTIFICATION", O_RDONLY) = 3
>
> - Also looks fine, read the locales identification.
>
> open("/usr/lib/locale/es/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such
> file or directory)
>
> - Here I am puzzled. Why? Maybe this is not important.
>
> Then there are no more calls to open or stat with files in "/usr/lib/locale"
> nor "/usr/share/locale" as argument, and I can't figure out why. What am I
> doing wrong? Is this version of glibc in ELDK broken?
There is a problem with locale support. The contents of the
'locale-archive' file is endian-dependent. This means that we can't
use the existing tools on the x86 (= little endian) ELDK build host
to generate it for a big-endian target.
As a workaround, the locale files can be generated natively on the
target, using for example the following command:
# localedef -i de_DE -f ISO-8859-1 de_DE
Hope this helps.
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
There is, however, a strange, musty smell in the air that reminds me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit. - Larry Wall in Configure from the perl distribution
^ permalink raw reply
* Re: [PATCH] MPC8xx PCMCIA driver
From: Magnus Damm @ 2005-09-01 11:44 UTC (permalink / raw)
To: Dominik Brodowski, Marcelo Tosatti, linux-ppc-embedded,
linux-kernel, Russell King, Dan Malek, Pantelis Antoniou
In-Reply-To: <20050901085319.GB6285@isilmar.linta.de>
Hello all,
Nice to see that this driver gets forward ported to 2.6. I originally
wrote it for pcmcia-cs, but it made its way into 2.4 after a while.
Thanks to all the people who added code and fixes.
I'm not sure how the current Linux pcmcia layer works, and I am not
involved in powerpc land anymore so I have no comments on the porting
work or the driver itself.
On 9/1/05, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> > Russell: The driver is using pccard_nonstatic_ops for card window
> > management, even though the driver its marked SS_STATIC_MAP (using
> > mem->static_map).
>=20
> This is obviously broken. Where does it fail if pccard_static_ops is used=
?
I remember it was interesting to write the driver for pcmcia-cs. This
was because the mpc8xx socket hardware did not implement per-window
offsets, and pcmcia-cs required that. So a wild guess is that this
static/notstatic thing is related to that.
/ magnus
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Andrey Volkov @ 2005-09-01 12:15 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <20050831204627.EAF8C35258E@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Andrey,
>
> in message <4315D1DC.1000607@varma-el.com> you wrote:
>
>>Wolfgang, first question to you:
>>May be you are know where I could find (if it exist)
>>BestComm (SmartComm) API for mystic MGT5100?
>
>
> We did not test the current code on the Icecube with the 5100, but
> previous versions used to run fine (well, within the limitations of
> the 5100, that is). So if the current code on our CVS server does not
> run, just check out an oder version. You can search the history of
> changes for example here:
> http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git
> like that:
> http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git&a=search&s=bestcomm
No, Wolfgang, I'm sorry, but you are don't understand me.
I seek bestcomm u-code for MGT5100 (and only for 5100) exceptionally for
subj. Since in 5100 was implemented EU#1, hence bestcomm u-code
for it have a little differences (in DRD2xx, if be more precesily).
This u-code is partially presented in U-boot (eth RX/TX tasks),
but it is not enough for me.
--
Regards
Andrey Volkov
^ permalink raw reply
* Error while accessing physical address
From: Garcia Jérémie @ 2005-09-01 13:44 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody.
As a kernel newbie, I still encounter basic problems. I read a lot of =
things on the memory management,
but obviously I didn't understand some things.
I have some kernel source code that only write data to our card =
registers:
>>>>>>>
void bhWriteCardRegister(unsigned short * address, unsigned short data)
{
unsigned short * regHdwAddress;
printk("Writing data: %x at address:%x\n",data,address);
/* Get the virtual address for the physical one */
regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
printk("ioremap returned : %x\n",regHdwAddress);
=20
/* write hardware register data value */=20
*regHdwAddress =3D data;
=20
iounmap((void *)regHdwAddress);
}
<<<<<<<<
In a module init I call this function:
>>>>>>>>
#define CARD_PROCESSOR_CTRL_IN_SERVICE 0x8000
#define CARD_PROCESSOR_CTRL_REG_P 0x40000400
bhWriteCardRegister((unsigned short *)(CARD_PROCESSOR_CTRL_REG_P), =
(unsigned short)CARD_PROCESSOR_CTRL_IN_SERVICE);
<<<<<<<<
When I load this module on our powerPC 405EP based arch, the execution =
gives that:
>>>>>>>>
Writing data: 8000 at address:40000400
ioremap returned : c2090400
<<<<<<<<
The problem is that after this write operation, every shell cmd I try =
give a "segmentation fault".
What I did wrong ??
Please help me cause I have to go on fast... (tks boss...)
^ 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