Mounting PRAMFS support

linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed

* Mounting PRAMFS support
@ 2008-08-12 10:02 Pieter
  2008-08-12 18:11 ` Wolfgang Denk
  0 siblings, 1 reply; 6+ messages in thread
From: Pieter @ 2008-08-12 10:02 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

Hi,

Im using a ppc85xx processor with Denx ELDK (4.1) The board  has 512MB
DDR2 and the board config reserves 64M for pram. during bootup the
mem=$mem argument is passed to the linux kernel command line and linux
boots successfully.

I am unable to mount the PRAMFS - all documentation leads me to use

mount -t pramfs -o physaddr=0x1c000000,init=0x4000000 none /mnt

witch fails with the message:
mounting none on /mtd failed: no such devise 

I have tried mounting using busybox v1.3  that comes with ELDK4.2 and
with busybox v1.10 and have not had success.
Can anyone help

-- 
Pieter Henning
VASTech

Tel: +27 (0)21 850 5921
Fax: +27 (0)86 503 8941
e-mail: phenning@vastech.co.za

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Mounting PRAMFS support
  2008-08-12 10:02 Mounting PRAMFS support Pieter
@ 2008-08-12 18:11 ` Wolfgang Denk
  2008-08-13  9:30   ` Pieter
  0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2008-08-12 18:11 UTC (permalink / raw)
  To: Pieter; +Cc: linuxppc-embedded

Dear Pieter,

In message <48A15FC3.3060008@vastech.co.za> you wrote:
> 
> Im using a ppc85xx processor with Denx ELDK (4.1) The board  has 512MB
> DDR2 and the board config reserves 64M for pram. during bootup the
> mem=$mem argument is passed to the linux kernel command line and linux
> boots successfully.

So what are the exact boot messages of your kernel?

> I am unable to mount the PRAMFS - all documentation leads me to use
> 
> mount -t pramfs -o physaddr=0x1c000000,init=0x4000000 none /mnt
-------------------------------------------------------------^^^^
> witch fails with the message:
> mounting none on /mtd failed: no such devise 
-------------------^^^^

/mnt != /mtd

There is something worng, probably your description. It would be
better if you showed the precise commands and outpout from your
target system.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Open the pod bay doors, HAL."                    - Dave Bowman, 2001

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Mounting PRAMFS support
  2008-08-12 18:11 ` Wolfgang Denk
@ 2008-08-13  9:30   ` Pieter
  2008-10-23  7:59     ` Ucode/BD conflict on PowerPC 860 Gray, Steve - UK
  0 siblings, 1 reply; 6+ messages in thread
From: Pieter @ 2008-08-13  9:30 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-embedded


[-- Attachment #1.1: Type: text/plain, Size: 8213 bytes --]

Hi Wolfgang

thanks for your quick reply. Below i have placed the boot message,
Another question I have that might help is that in DULG  section 5.10
where the environmental variable "pram" is defined,  the documentation
states "If the "Protected RAM" feature is enabled in your board's
configuration" 
Is the PRAMFS support  built in and available when CONFIG_PRAM and the
"pram" environmental variable is defined in the board config or are
there other elements to be configured or activated on the linux side
aswell?.  (mpc8548 board using  ELDK 4.1 ppc_85xx)

The boot message:

U-Boot 1.2.0 (Aug 12 2008 - 16:21:15)

CPU:   8548_E, Version: 1.1, (0x80390011)
Core:  E500, Version: 1.0, (0x80210010)
Clock Configuration:
       CPU: 990 MHz, CCB: 396 MHz,
       DDR: 198 MHz, LBC:  49 MHz
L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled
Board: Equus MPC8548
    PCI1: 64 bit, 66 MHz, sync
I2C:   ready
DRAM:  Initializing
    DDR: 512 MB
FLASH: 128 MB
L2 cache 512KB: enabled
*** Warning - bad CRC, using default environment

BIE:
  serial number = EQ_0002
  build level   = EQUUS-1.1
  set ethaddr  to 00:50:C2:52:50:FC
  set eth1addr to 00:50:C2:52:50:FD
  set eth2addr to 00:50:C2:52:50:FE
  set bootsrc  to factory
Running boot diagnostics
In:    serial
Out:   serial
Err:   serial
Net:   eTSEC0, eTSEC1, eTSEC2
boot count loaded 1
boot count stored 2
Hit any key to stop autoboot:  0
### CRAMFS loading '/boot/uImage' to 0x200000
### CRAMFS load complete: 1067930 bytes loaded to 0x200000
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.19.2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1067866 Bytes =  1 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=64Mb, CAM2=64Mb residual: 64Mb
Linux version 2.6.19.2 (root@sdh-ts2) (gcc version 4.0.0 (DENX ELDK 4.1
4.0.0)) #1 Tue Aug 12 15:56:47 SAST 2008
Zone PFN ranges:
  DMA             0 ->    98304
  Normal      98304 ->    98304
early_node_map[1] active PFN ranges
    0:        0 ->    98304
Built 1 zonelists.  Total pages: 97536
Kernel command line: root=/dev/mtdblock0 ro console=ttyS0,115200 mem=458752k
OpenPIC Version 1.2 (1 CPUs and 60 IRQ sources) at fcfbb000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 387328k available (1712k kernel code, 500k data, 136k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 1 of device 0000:00:00.0
PCI: Failed to allocate mem resource #1:80000000@0 for 0000:00:00.0
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 26) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 26) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2(MW), 00:50:c2:52:50:fc
eth0: Running with NAPI enabled
eth0: 256/1024 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2(MW), 00:50:c2:52:50:fd
eth1: Running with NAPI enabled
eth1: 256/1024 RX/TX BD ring size
eth2: Gianfar Ethernet Controller Version 1.2(MW), 00:50:c2:52:50:fe
eth2: Running with NAPI enabled
eth2: 256/1024 RX/TX BD ring size
Cicada Cis8204: Registered new driver
Cicada Cis8201: Registered new driver
0: Found 2 x16 devices at 0x0 in 32-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Equus flash bank 0: Using static image bank1 partition definition
Creating 9 MTD partitions on "0":
0x00000000-0x01000000 : "factory-image"
mtd: Giving out device 0 to factory-image
0x01000000-0x02000000 : "app-image-1"
mtd: Giving out device 1 to app-image-1
0x02000000-0x03000000 : "app-image-2"
mtd: Giving out device 2 to app-image-2
0x03000000-0x04000000 : "jffs2"
mtd: Giving out device 3 to jffs2
0x04000000-0x05000000 : "testing"
mtd: Giving out device 4 to testing
0x05000000-0x07f40000 : "reserved"
mtd: Giving out device 5 to reserved
0x07f40000-0x07f80000 : "u-boot-env"
mtd: Giving out device 6 to u-boot-env
0x07f80000-0x08000000 : "u-boot-app"
mtd: Giving out device 7 to u-boot-app
0x00000000-0x08000000 : "all"
mtd: Giving out device 8 to all
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 136k init
INIT: version 2.85 booting
$Mounting /dev/mtdblock2 to /usr/config
jffs2 Mount Sucsesfull. Checking config files
cron.daily file missing - Copy from defaults
cron.hourly file missing - Copy from defaults
cron.weekly file missing - Copy from defaults
ifcfg-eth0 file exist - Skipping
ifcfg-eth1 file exist - Skipping
ifcfg-eth2 file exist - Skipping
logrotate.conf file exist - Skipping
ntp.conf file exist - Skipping
resolv.conf file exist - Skipping
syslog.conf file exist - Skipping
$               Welcome to $DENX Embedded$ Linux Environment
$               VAStech SDH Gateway
$               Press 'I' to enter interactive startup.
$ done[  $OK  ]
$Setting clock : Thu Jan  1 00:00:01 UTC 1970 [  $OK  ]
$Setting hostname sdh-gateway:  [  $OK  ]
$Mounting local filesystems:  [  $OK  ]
INIT: Entering runlevel: 3
current directory/etc/sysconfig/network-scripts
$Bringing up loopback interface:  Hardware Address
[  $OK  ]
$Bringing up interface eth0:  Hardware Address
[  $OK  ]
$Bringing up interface eth1:  Hardware Address
[  $OK  ]
$Bringing up interface eth2:  Hardware Address
[  $OK  ]
$Starting system logger: [  $OK  ]
$Starting kernel logger: [  $OK  ]
$Starting xinetd: [  $OK  ]
$Starting ntpd: [  $OK  ]
$Starting periodic command scheduler : [  $OK  ]

DENX ELDK version 4.0 build 2006-01-12
Linux 2.6.19.2 on a ppc


When i then try to mount  the PRAMFS i get the following:

sh\$ mount -t pramfs -o physaddr=0x1c000000,init=0x4000000 none /tmp/test/
mount: mounting none on /tmp/test/ failed: No such device
sh\$

I might be missing something simple. There are no recent documentation
regarding PRAMFS  is it still suported or has it been abandoned?

thanks for your time Pieter

Wolfgang Denk wrote:
> Dear Pieter,
>
> In message <48A15FC3.3060008@vastech.co.za> you wrote:
>   
>> Im using a ppc85xx processor with Denx ELDK (4.1) The board  has 512MB
>> DDR2 and the board config reserves 64M for pram. during bootup the
>> mem=$mem argument is passed to the linux kernel command line and linux
>> boots successfully.
>>     
>
> So what are the exact boot messages of your kernel?
>
>   
>> I am unable to mount the PRAMFS - all documentation leads me to use
>>
>> mount -t pramfs -o physaddr=0x1c000000,init=0x4000000 none /mnt
>>     
> -------------------------------------------------------------^^^^
>   
>> witch fails with the message:
>> mounting none on /mtd failed: no such devise 
>>     
> -------------------^^^^
>
> /mnt != /mtd
>   
--------------^^^^
This was a typo
> There is something worng, probably your description. It would be
> better if you showed the precise commands and outpout from your
> target system.
>
> Best regards,
>
> Wolfgang Denk
>
>   

-- 
Pieter Henning
VASTech

Tel: +27 (0)21 850 5921
Fax: +27 (0)86 503 8941
e-mail: phenning@vastech.co.za


[-- Attachment #1.2: Type: text/html, Size: 10831 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Ucode/BD conflict on PowerPC 860
  2008-08-13  9:30   ` Pieter
@ 2008-10-23  7:59     ` Gray, Steve - UK
  2008-10-23 15:31       ` Scott Wood
  0 siblings, 1 reply; 6+ messages in thread
From: Gray, Steve - UK @ 2008-10-23  7:59 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]

Hi all

I am using U-Boot 1.3.4 and an ELDK linux Kernel snapshot from the Denx
Git dated 14th October 2008-10-23

My custom architecture is based around a Power PC 860 processor.

I have written a Flattened Device Tree for the architecture.

 

I am having some trouble with the allocation of the Buffer Descriptors
when microcode is loaded.

My IMMR address is 0xfa200000 and the DPRAM is located at 0xfa202000.

 

The buffer descriptors are trying to be located at 0xfa202040, which is
all 0xFFs, as indicated by the cp_rccr = 0x3

I am debugging this with a BDI3000

 

My SMC console works fine IF I set rccr back to 0x0 during console_init
and the buffers are then allocated at 0xfa202040.

 

U-boot.1.3.4 is configured to use install micro code,
CFG_I2C_UCODE_PATCH. 

 

Rightly or wrongly I have based my DTS file on the mpc866ads.dts file.

The relevant section of the DTS to setup the DPRAM space is,

 

                                    muram {

                                                #address-cells = <1>;

                                                #size-cells = <1>;

                                                ranges = <0x0 0x2000
0x2000>;

 

                                                data@0 {

                                                            compatible =
"fsl,cpm-muram-data";

                                                            reg = <0x0
0x1c00>;

                                                };

                                    };

 

                                    console: serial@a90 {

                                                device_type = "serial";

                                                compatible =
"fsl,mpc860-smc-uart",

 
"fsl,cpm1-smc-uart";

                                                reg = <0xa90 0x10 0x3f80
0x40>;

                                                interrupts = <3>;

                                                interrupt-parent =
<&CPM_PIC>;

                                                fsl,cpm-brg = <2>;

                                                fsl,cpm-command =
<0xd0>;

                                                current-speed = <9600>;


                                    };

            chosen {

                        linux,stdout-path = &console;

            }

 

I have tried a few things, including setting the range of muram to
ranges = <0x0 0x3000 0x1000>; 

Am I correct to assume this will push the muram above the microcode??

 

I think it is an obvious fix but at the moment I can't seem to locate
the problem.

Can someone please explain to me where I am going wrong? 

or how I can correctly locate the Buffer descriptors so they do not
conflict with the locked address of the micro code??

 

 

Here is the output that I am getting at the moment

 

U-Boot 1.3.4 (Oct 22 2008 - 15:53:20)

CPU:   XPC86xxxZPnnD4 at 48 MHz: 4 kB I-Cache 4 kB D-Cache FEC present

I2C:   ready

DRAM:  16 MB

FLASH: 16 MB

Using default environment

 

In:    serial

Out:   serial

Err:   serial

Net:   SCC ETHERNET

Autobooting in 0 second, type "peek" to stop

## Booting kernel from Legacy Image at fe042000 ...

   Image Name:   Linux-2.6.27-dev20081014

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    1373155 Bytes =  1.3 MB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

## Flattened Device Tree blob at fe040000

   Booting using the fdt blob at 0xfe040000

   Loading Device Tree to 007fc000, end 007ffc6b ... OK

 

 

Thanks in Advance

Regards

Steve Gray


[-- Attachment #2: Type: text/html, Size: 23496 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ucode/BD conflict on PowerPC 860
  2008-10-23  7:59     ` Ucode/BD conflict on PowerPC 860 Gray, Steve - UK
@ 2008-10-23 15:31       ` Scott Wood
  2008-10-24 13:03         ` Gray, Steve - UK
  0 siblings, 1 reply; 6+ messages in thread
From: Scott Wood @ 2008-10-23 15:31 UTC (permalink / raw)
  To: Gray, Steve - UK; +Cc: linuxppc-embedded

Gray, Steve - UK wrote:
> I have tried a few things, including setting the range of muram to 
> ranges = <0x0 0x3000 0x1000>;
> 
> Am I correct to assume this will push the muram above the microcode??

No, that will confuse the kernel into thinking that muram starts at IMMR 
offset 0x3000.  You need to change the reg property of the data subnode 
to <0x1000 0xc00>, so that you restrict the allocation range without 
affecting the offset that is subtracted from the physical address to 
obtain the value given to the CPM.

-Scott

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Ucode/BD conflict on PowerPC 860
  2008-10-23 15:31       ` Scott Wood
@ 2008-10-24 13:03         ` Gray, Steve - UK
  0 siblings, 0 replies; 6+ messages in thread
From: Gray, Steve - UK @ 2008-10-24 13:03 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-embedded

Hi Scott
Thanks for the notes on modifying the data subnode.=20
I am pleased to say this has fixed the problem and the console is
working now.

Kind Regards

Stve

-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]=20
Sent: 23 October 2008 16:32
To: Gray, Steve - UK
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Ucode/BD conflict on PowerPC 860

Gray, Steve - UK wrote:
> I have tried a few things, including setting the range of muram to=20
> ranges =3D <0x0 0x3000 0x1000>;
>=20
> Am I correct to assume this will push the muram above the microcode??

No, that will confuse the kernel into thinking that muram starts at IMMR

offset 0x3000.  You need to change the reg property of the data subnode=20
to <0x1000 0xc00>, so that you restrict the allocation range without=20
affecting the offset that is subtracted from the physical address to=20
obtain the value given to the CPM.

-Scott

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-10-24 13:05 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-12 10:02 Mounting PRAMFS support Pieter
2008-08-12 18:11 ` Wolfgang Denk
2008-08-13  9:30   ` Pieter
2008-10-23  7:59     ` Ucode/BD conflict on PowerPC 860 Gray, Steve - UK
2008-10-23 15:31       ` Scott Wood
2008-10-24 13:03         ` Gray, Steve - UK

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).