All of lore.kernel.org
 help / color / mirror / Atom feed
* relocatable modules' symbols
@ 2013-02-22 23:45 horseriver
  2013-02-24  9:00 ` Mulyadi Santosa
  0 siblings, 1 reply; 9+ messages in thread
From: horseriver @ 2013-02-22 23:45 UTC (permalink / raw)
  To: kernelnewbies

hi:

  I have built vmlinux at the top dir of kernel source ,then I use objdump to look into
  its section information.I find the statup_32 which is the start routine of kernel ,
  locats at 0xc0100000. I know the 0x100000 is the defined address for locating 
  protect-mode code .But which I can not understand is the 0xc prefix .where does it come from?

thanks!

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-02-24  9:00 ` Mulyadi Santosa
@ 2013-02-24  1:56   ` horseriver
  2013-02-25 15:30     ` Mulyadi Santosa
  2013-03-01  5:37     ` Arun KS
  0 siblings, 2 replies; 9+ messages in thread
From: horseriver @ 2013-02-24  1:56 UTC (permalink / raw)
  To: kernelnewbies

On Sun, Feb 24, 2013 at 04:00:37PM +0700, Mulyadi Santosa wrote:
> On Sat, Feb 23, 2013 at 6:45 AM, horseriver <horserivers@gmail.com> wrote:
> > hi:
> >
> >   I have built vmlinux at the top dir of kernel source ,then I use objdump to look into
> >   its section information.I find the statup_32 which is the start routine of kernel ,
> >   locats at 0xc0100000. I know the 0x100000 is the defined address for locating
> >   protect-mode code .But which I can not understand is the 0xc prefix .where does it come from?
> 
> If my guess is right, that's because kernel mode code start at
> 0xc000000 a.k.a a bit above 3 GiB on x86 32 bit machine

  I have find this answer .
  It is defined in lds script file . 

here is the code :
  SECTIONS
  {
  . = 0xC0000000 + 0x100000;
  /* read-only */
  _text = .;		/* Text and read-only data */
 
 
  why use 0xC0000000 as its start ? why not  just  use 0x100000 only ?
  if use 0xC0000000,every linked symbole will be prefixed by 0xc , what is the purpose ?

thanks!



-- 
> regards,
> 
> Mulyadi Santosa
> Freelance Linux trainer and consultant
> 
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-02-22 23:45 relocatable modules' symbols horseriver
@ 2013-02-24  9:00 ` Mulyadi Santosa
  2013-02-24  1:56   ` horseriver
  0 siblings, 1 reply; 9+ messages in thread
From: Mulyadi Santosa @ 2013-02-24  9:00 UTC (permalink / raw)
  To: kernelnewbies

On Sat, Feb 23, 2013 at 6:45 AM, horseriver <horserivers@gmail.com> wrote:
> hi:
>
>   I have built vmlinux at the top dir of kernel source ,then I use objdump to look into
>   its section information.I find the statup_32 which is the start routine of kernel ,
>   locats at 0xc0100000. I know the 0x100000 is the defined address for locating
>   protect-mode code .But which I can not understand is the 0xc prefix .where does it come from?

If my guess is right, that's because kernel mode code start at
0xc000000 a.k.a a bit above 3 GiB on x86 32 bit machine

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-02-24  1:56   ` horseriver
@ 2013-02-25 15:30     ` Mulyadi Santosa
  2013-03-01  5:37     ` Arun KS
  1 sibling, 0 replies; 9+ messages in thread
From: Mulyadi Santosa @ 2013-02-25 15:30 UTC (permalink / raw)
  To: kernelnewbies

Hi...

On Sun, Feb 24, 2013 at 8:56 AM, horseriver <horserivers@gmail.com> wrote:
>   I have find this answer .
>   It is defined in lds script file .
>
> here is the code :
>   SECTIONS
>   {
>   . = 0xC0000000 + 0x100000;
>   /* read-only */
>   _text = .;            /* Text and read-only data */
>
>
>   why use 0xC0000000 as its start ? why not  just  use 0x100000 only ?
>   if use 0xC0000000,every linked symbole will be prefixed by 0xc , what is the purpose ?


maybe because some symbols are object of relocation, so their address
don't need to be incremented with 0xc000 0000.

Different situation with startup_32. AFAIK it's doing many thing
during early protected mode initialization, so its address must be set
to certain number.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-02-24  1:56   ` horseriver
  2013-02-25 15:30     ` Mulyadi Santosa
@ 2013-03-01  5:37     ` Arun KS
  2013-03-01 10:56       ` Prabhu nath
  1 sibling, 1 reply; 9+ messages in thread
From: Arun KS @ 2013-03-01  5:37 UTC (permalink / raw)
  To: kernelnewbies

Hi Horseriver,

On Sun, Feb 24, 2013 at 7:26 AM, horseriver <horserivers@gmail.com> wrote:
> On Sun, Feb 24, 2013 at 04:00:37PM +0700, Mulyadi Santosa wrote:
>> On Sat, Feb 23, 2013 at 6:45 AM, horseriver <horserivers@gmail.com> wrote:
>> > hi:
>> >
>> >   I have built vmlinux at the top dir of kernel source ,then I use objdump to look into
>> >   its section information.I find the statup_32 which is the start routine of kernel ,
>> >   locats at 0xc0100000. I know the 0x100000 is the defined address for locating
>> >   protect-mode code .But which I can not understand is the 0xc prefix .where does it come from?
>>
>> If my guess is right, that's because kernel mode code start at
>> 0xc000000 a.k.a a bit above 3 GiB on x86 32 bit machine
>
>   I have find this answer .
>   It is defined in lds script file .
>
> here is the code :
>   SECTIONS
>   {
>   . = 0xC0000000 + 0x100000;
>   /* read-only */
>   _text = .;            /* Text and read-only data */
>
>
>   why use 0xC0000000 as its start ? why not  just  use 0x100000 only ?
>   if use 0xC0000000,every linked symbole will be prefixed by 0xc , what is the purpose ?

Usually, user kernel space split is 3G:1G.
ie 1G for kernel space. And this starts from 0xC000_0000 till 0xFFFF_FFFF

All the address below 0xC000_0000(ie 3G from 0x0 to 0xBFFF_FFFF) is
used for user space.

Thanks,
Arun
>
> thanks!
>
>
>
> --
>> regards,
>>
>> Mulyadi Santosa
>> Freelance Linux trainer and consultant
>>
>> blog: the-hydra.blogspot.com
>> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-03-01  5:37     ` Arun KS
@ 2013-03-01 10:56       ` Prabhu nath
  2013-03-01 12:50         ` John Smith
  0 siblings, 1 reply; 9+ messages in thread
From: Prabhu nath @ 2013-03-01 10:56 UTC (permalink / raw)
  To: kernelnewbies

In principle, the linker will associate the kernel code/data  to the Kernel
virtual address space i.e. between 0xC000_0000 to 0xFFFF_FFFF and
the same linker will associate the Application's code/data to the user
virtual address space i.e. between 0x0000_0000 to 0xBFFF_FFFF.

Linker itself cannot distinguish between the kernel code/data and user
code/data but it is the linker script that will guide the linker to
associate the code/data to the respective addresses.

What you are seeing is the linker script provided to the linker with -T
option when building the kernel.

To build the user application the linker uses its default linker script
which you get it by executing
$ ld --verbose.

To compare between the two just juxtapose the readelf output of both kernel
executable (vmlinux) and any user application executable (a.out)

$ readelf -a vmlinux
$ readelf -a a.out

Just inspect the section header and program header of both the outputs you
will get the difference.

Regards,
Prabhu



On Fri, Mar 1, 2013 at 11:07 AM, Arun KS <getarunks@gmail.com> wrote:

> Hi Horseriver,
>
> On Sun, Feb 24, 2013 at 7:26 AM, horseriver <horserivers@gmail.com> wrote:
> > On Sun, Feb 24, 2013 at 04:00:37PM +0700, Mulyadi Santosa wrote:
> >> On Sat, Feb 23, 2013 at 6:45 AM, horseriver <horserivers@gmail.com>
> wrote:
> >> > hi:
> >> >
> >> >   I have built vmlinux at the top dir of kernel source ,then I use
> objdump to look into
> >> >   its section information.I find the statup_32 which is the start
> routine of kernel ,
> >> >   locats at 0xc0100000. I know the 0x100000 is the defined address
> for locating
> >> >   protect-mode code .But which I can not understand is the 0xc prefix
> .where does it come from?
> >>
> >> If my guess is right, that's because kernel mode code start at
> >> 0xc000000 a.k.a a bit above 3 GiB on x86 32 bit machine
> >
> >   I have find this answer .
> >   It is defined in lds script file .
> >
> > here is the code :
> >   SECTIONS
> >   {
> >   . = 0xC0000000 + 0x100000;
> >   /* read-only */
> >   _text = .;            /* Text and read-only data */
> >
> >
> >   why use 0xC0000000 as its start ? why not  just  use 0x100000 only ?
> >   if use 0xC0000000,every linked symbole will be prefixed by 0xc , what
> is the purpose ?
>
> Usually, user kernel space split is 3G:1G.
> ie 1G for kernel space. And this starts from 0xC000_0000 till 0xFFFF_FFFF
>
> All the address below 0xC000_0000(ie 3G from 0x0 to 0xBFFF_FFFF) is
> used for user space.
>
> Thanks,
> Arun
> >
> > thanks!
> >
> >
> >
> > --
> >> regards,
> >>
> >> Mulyadi Santosa
> >> Freelance Linux trainer and consultant
> >>
> >> blog: the-hydra.blogspot.com
> >> training: mulyaditraining.blogspot.com
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/05a15318/attachment.html 

^ permalink raw reply	[flat|nested] 9+ messages in thread
* relocatable modules' symbols
  2013-03-01 10:56       ` Prabhu nath
@ 2013-03-01 12:50         ` John Smith
  2013-03-01 18:28           ` MTD NOR write issue for files greater than a few hundred bytes Holmes, Michael A (Mike)
  0 siblings, 1 reply; 9+ messages in thread
From: John Smith @ 2013-03-01 12:50 UTC (permalink / raw)
  To: kernelnewbies

 what linear address is the virtual address 0xc000 0000  respondable to ?
  the highest 10 bits 0x300 is pde , which means the 0x300th entry of
the page dir.
  As I know ,at boot stage , that pde has not been ever filles . then
how does the
  kernel code been addressed?

2013/3/1 Prabhu nath <gprabhunath@gmail.com>:
> In principle, the linker will associate the kernel code/data  to the Kernel
> virtual address space i.e. between 0xC000_0000 to 0xFFFF_FFFF and
> the same linker will associate the Application's code/data to the user
> virtual address space i.e. between 0x0000_0000 to 0xBFFF_FFFF.
>
> Linker itself cannot distinguish between the kernel code/data and user
> code/data but it is the linker script that will guide the linker to
> associate the code/data to the respective addresses.
>
> What you are seeing is the linker script provided to the linker with -T
> option when building the kernel.
>
> To build the user application the linker uses its default linker script
> which you get it by executing
> $ ld --verbose.
>
> To compare between the two just juxtapose the readelf output of both kernel
> executable (vmlinux) and any user application executable (a.out)
>
> $ readelf -a vmlinux
> $ readelf -a a.out
>
> Just inspect the section header and program header of both the outputs you
> will get the difference.
>
> Regards,
> Prabhu
>
>
>
> On Fri, Mar 1, 2013 at 11:07 AM, Arun KS <getarunks@gmail.com> wrote:
>>
>> Hi Horseriver,
>>
>> On Sun, Feb 24, 2013 at 7:26 AM, horseriver <horserivers@gmail.com> wrote:
>> > On Sun, Feb 24, 2013 at 04:00:37PM +0700, Mulyadi Santosa wrote:
>> >> On Sat, Feb 23, 2013 at 6:45 AM, horseriver <horserivers@gmail.com>
>> >> wrote:
>> >> > hi:
>> >> >
>> >> >   I have built vmlinux at the top dir of kernel source ,then I use
>> >> > objdump to look into
>> >> >   its section information.I find the statup_32 which is the start
>> >> > routine of kernel ,
>> >> >   locats at 0xc0100000. I know the 0x100000 is the defined address
>> >> > for locating
>> >> >   protect-mode code .But which I can not understand is the 0xc prefix
>> >> > .where does it come from?
>> >>
>> >> If my guess is right, that's because kernel mode code start at
>> >> 0xc000000 a.k.a a bit above 3 GiB on x86 32 bit machine
>> >
>> >   I have find this answer .
>> >   It is defined in lds script file .
>> >
>> > here is the code :
>> >   SECTIONS
>> >   {
>> >   . = 0xC0000000 + 0x100000;
>> >   /* read-only */
>> >   _text = .;            /* Text and read-only data */
>> >
>> >
>> >   why use 0xC0000000 as its start ? why not  just  use 0x100000 only ?
>> >   if use 0xC0000000,every linked symbole will be prefixed by 0xc , what
>> > is the purpose ?
>>
>> Usually, user kernel space split is 3G:1G.
>> ie 1G for kernel space. And this starts from 0xC000_0000 till 0xFFFF_FFFF
>>
>> All the address below 0xC000_0000(ie 3G from 0x0 to 0xBFFF_FFFF) is
>> used for user space.
>>
>> Thanks,
>> Arun
>> >
>> > thanks!
>> >
>> >
>> >
>> > --
>> >> regards,
>> >>
>> >> Mulyadi Santosa
>> >> Freelance Linux trainer and consultant
>> >>
>> >> blog: the-hydra.blogspot.com
>> >> training: mulyaditraining.blogspot.com
>> >
>> > _______________________________________________
>> > Kernelnewbies mailing list
>> > Kernelnewbies at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>

^ permalink raw reply	[flat|nested] 9+ messages in thread
* MTD NOR write issue for files greater than a few hundred bytes
  2013-03-01 12:50         ` John Smith
@ 2013-03-01 18:28           ` Holmes, Michael A (Mike)
  0 siblings, 0 replies; 9+ messages in thread
From: Holmes, Michael A (Mike) @ 2013-03-01 18:28 UTC (permalink / raw)
  To: kernelnewbies

All,

The issue I have is as follows.  
When writing to the MTD on NOR in Linux for a file of more than a few bytes, it fails with a MTD software timeout. 

Writing upto 100 bytes are fine, in this test when I jumped to 300 it failed.
I also proved that the small writes do get written; I wrote zeros over my mtd1 "u-boot-env" and had to repair it on reboot.

In Uboot there are no NOR or NAND read/write issues, erase appears to work fine etc. Under Linux MTD for the NAND remains flawless and MTD NOR read has no issues.

Any thoughts appreciated: some information and the tests output below.


LCPSH # flinfo

Bank # 1: CFI conformant FLASH (8 x 8)  Size: 64 MB in 512 Sectors
  AMD Standard command set, Manufacturer ID: 0x15, Device ID: 0x00
  Erase timeout: 4096 ms, write timeout: 25 ms
  Buffer write timeout: 50 ms, buffer size: 1024 bytes

  Sector Start Addresses:
  10000000   RO   10020000   RO   10040000   RO   10060000   RO   10080000
  100A0000        100C0000        100E0000        10100000        10120000
  10140000        10160000        10180000        101A0000        101C0000
  101E0000        10200000        10220000        10240000        10260000
  10280000        102A0000        102C0000        102E0000        10300000
  10320000        10340000        10360000        10380000        103A0000
  103C0000        103E0000        10400000        10420000        10440000
  10460000        10480000        104A0000        104C0000        104E0000
  10500000        10520000        10540000        10560000        10580000
  105A0000        105C0000        105E0000        10600000        10620000
....
....
...

root at lvs15:/# uname -a
Linux lvs15 2.6.35-lcp-arm1 #1 SMP Fri Mar 1 11:59:02 EST 2013 armv6l GNU/Linux

root at lvs15:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00020000 "u-boot"
mtd1: 00040000 00020000 "u-boot-env"
mtd2: 03f40000 00020000 "unused-nor"
mtd3: 01e00000 00020000 "nand-linuxImg1"
mtd4: 01e00000 00020000 "nand-linuxImg2"
mtd5: 3c400000 00020000 "nandfs"

root at lvs15:/# mtd_debug info /dev/mtd1
MTD_open
MTD_ioctl
MTD_ioctl
MTD_close= MTD_NORFLASH

mtd.flags = MTD_CAP_NORFLASH
mtd.size = 262144 (256K)
mtd.erasesize = 131072 (128K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0


mtd_debug read /dev/mtd1 0 1000 read.txt
Copied 1000 bytes from address 0x00000000 in flash to read.txt

root at lvs15:/# cat read.txt
??      ?bootdelay=5baudrate=115200loadaddr=0x05000000mtdids=nor0=physmap-flash.0,nand0=lcp_nandmtdparts=mtdparts=physmap-flash.0:512k(u-boot),256k(u-boot-env),-(unused-nor);lcp_nand:30M(nand-linuxImg1),30M(nand-linuxImg2),-(nandfs)verify=nlcpethmac0cpathchnl=0lcpethmac0ethforcerate=1000lcpethmac0ethforcefulldplx=Ylcpethmac1cpathchnl=0lcpethmac1ethforcerate=1000lcpethmac1ethforcefulldplx=Yethprime=LCP_ETH_MAC0ethrotate=no netretry=no autostart=yessetupbootargs=setenv bootargs earlyprintk=serial,ttyAMA0,$(baudrate) console=ttyAMA0,$(baudrate)n8 root=/dev/ram mtdids=$(mtdids) $(mtdparts)bootcmd=fpgasetup;run setupbootargs;tftp ad_value=0x1e1lcpethmac1bcastfltr=onlcpethmac1mcastfltr=onlcpethmac1pausepktfltr=onlcpethmac1runtpktfltr=onlcpethmac1ucastfltr=onlcpethmac0bcastfltr=onlcpethmac0mcastfltr=onlcpethmac0pausepktfltr=onlcpethmac0runtpktfltr=onlcpethmac0ucastfltr=onlcpethmac0ucastfltrda2=00:00:00:00:00:00lcpethmac0ucastfltrda3=00:00:00:00:00:00lcp<d /dev/mtd2 0 1000 read.txtmtd_debug write /dev/mtd1 0 1000 read.txt



I appreciate I do not do erases between writes but the data is the same and I have not had trouble with this, other than if you do write different data obviously all bets are off!


root at lvs15:/# mtd_debug write /dev/mtd1 0 10 read.txt
MTD_open
MTD_write
MTD do_write_buffer(): WRITE 0x00080000(0x000000c5)
Copied 10 bytes from read.txt to address 0x00000000 in flash

root at lvs15:/# mtd_debug write /dev/mtd1 0 100 read.txt
MTD_open
MTD_write
MTD do_write_buffer(): WRITE 0x00080000(0x000000c5)
Copied 100 bytes from read.txt to address 0x00000000 in flash

root@lvs15:/# mtd_debug write /dev/mtd1 0 300 read.txt
MTD_open
MTD_write
MTD do_write_buffer(): WRITE 0x00080000(0x000000c5)
MTD do_write_buffer(): software timeout
file_to_flash: write, size 0x12c, n 0x12c
write(): Input/output error

^ permalink raw reply	[flat|nested] 9+ messages in thread
* MTD NOR write issue for files greater than a few hundred bytes
@ 2013-03-04 15:42 Holmes, Michael A (Mike)
  0 siblings, 0 replies; 9+ messages in thread
From: Holmes, Michael A (Mike) @ 2013-03-04 15:42 UTC (permalink / raw)
  To: kernelnewbies

All - repost since this ended up on the end of another thread.,



The issue I have is as follows.

When writing to the MTD on NOR in Linux for a file of more than a few bytes, it fails with a MTD software timeout.



Writing upto 100 bytes are fine, in this test when I jumped to 300 it failed.

I also proved that the small writes do get written; I wrote zeros over my mtd1 "u-boot-env" and had to repair it on reboot.



In Uboot there are no NOR or NAND read/write issues, erase appears to work fine etc. Under Linux MTD for the NAND remains flawless and MTD NOR read has no issues.



Any thoughts appreciated: some information and the tests output below.





LCPSH # flinfo



Bank # 1: CFI conformant FLASH (8 x 8)  Size: 64 MB in 512 Sectors

  AMD Standard command set, Manufacturer ID: 0x15, Device ID: 0x00

  Erase timeout: 4096 ms, write timeout: 25 ms

  Buffer write timeout: 50 ms, buffer size: 1024 bytes



  Sector Start Addresses:

  10000000   RO   10020000   RO   10040000   RO   10060000   RO   10080000

  100A0000        100C0000        100E0000        10100000        10120000

  10140000        10160000        10180000        101A0000        101C0000

  101E0000        10200000        10220000        10240000        10260000

  10280000        102A0000        102C0000        102E0000        10300000

  10320000        10340000        10360000        10380000        103A0000

  103C0000        103E0000        10400000        10420000        10440000

  10460000        10480000        104A0000        104C0000        104E0000

  10500000        10520000        10540000        10560000        10580000

  105A0000        105C0000        105E0000        10600000        10620000

....

....

...



root at lvs15:/# uname -a

Linux lvs15 2.6.35-lcp-arm1 #1 SMP Fri Mar 1 11:59:02 EST 2013 armv6l GNU/Linux



root at lvs15:/# cat /proc/mtd

dev:    size   erasesize  name

mtd0: 00080000 00020000 "u-boot"

mtd1: 00040000 00020000 "u-boot-env"

mtd2: 03f40000 00020000 "unused-nor"

mtd3: 01e00000 00020000 "nand-linuxImg1"

mtd4: 01e00000 00020000 "nand-linuxImg2"

mtd5: 3c400000 00020000 "nandfs"



root at lvs15:/# mtd_debug info /dev/mtd1

MTD_open

MTD_ioctl

MTD_ioctl

MTD_close= MTD_NORFLASH



mtd.flags = MTD_CAP_NORFLASH

mtd.size = 262144 (256K)

mtd.erasesize = 131072 (128K)

mtd.writesize = 1

mtd.oobsize = 0

regions = 0





mtd_debug read /dev/mtd1 0 1000 read.txt Copied 1000 bytes from address 0x00000000 in flash to read.txt



root at lvs15:/# cat read.txt

??      ?bootdelay=5baudrate=115200loadaddr=0x05000000mtdids=nor0=physmap-flash.0,nand0=lcp_nandmtdparts=mtdparts=physmap-flash.0:512k(u-boot),256k(u-boot-env),-(unused-nor);lcp_nand:30M(nand-linuxImg1),30M(nand-linuxImg2),-(nandfs)verify=nlcpethmac0cpathchnl=0lcpethmac0ethforcerate=1000lcpethmac0ethforcefulldplx=Ylcpethmac1cpathchnl=0lcpethmac1ethforcerate=1000lcpethmac1ethforcefulldplx=Yethprime=LCP_ETH_MAC0ethrotate=no netretry=no autostart=yessetupbootargs=setenv bootargs earlyprintk=serial,ttyAMA0,$(baudrate) console=ttyAMA0,$(baudrate)n8 root=/dev/ram mtdids=$(mtdids) $(mtdparts)bootcmd=fpgasetup;run setupbootargs;tftp ad_value=0x1e1lcpethmac1bcastfltr=onlcpethmac1mcastfltr=onlcpethmac1pausepktfltr=onlcpethmac1runtpktfltr=onlcpethmac1ucastfltr=onlcpethmac0bcastfltr=onlcpethmac0mcastfltr=onlcpethmac0pausepktfltr=onlcpethmac0runtpktfltr=onlcpethmac0ucastfltr=onlcpethmac0ucastfltrda2=00:00:00:00:00:00lcpethmac0ucastfltrda3=00:00:00:00:00:00lcp<d /dev/mtd2 0 1000 read.txtmtd_debug write /dev/mtd1 0 1000 read.txt







I appreciate I do not do erases between writes but the data is the same and I have not had trouble with this, other than if you do write different data obviously all bets are off!





root at lvs15:/# mtd_debug write /dev/mtd1 0 10 read.txt MTD_open MTD_write MTD do_write_buffer(): WRITE 0x00080000(0x000000c5) Copied 10 bytes from read.txt to address 0x00000000 in flash



root at lvs15:/# mtd_debug write /dev/mtd1 0 100 read.txt MTD_open MTD_write MTD do_write_buffer(): WRITE 0x00080000(0x000000c5) Copied 100 bytes from read.txt to address 0x00000000 in flash



root@lvs15:/# mtd_debug write /dev/mtd1 0 300 read.txt MTD_open MTD_write MTD do_write_buffer(): WRITE 0x00080000(0x000000c5) MTD do_write_buffer(): software timeout

file_to_flash: write, size 0x12c, n 0x12c

write(): Input/output error


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130304/afb61bf6/attachment-0001.html 

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-04 15:42 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-22 23:45 relocatable modules' symbols horseriver
2013-02-24  9:00 ` Mulyadi Santosa
2013-02-24  1:56   ` horseriver
2013-02-25 15:30     ` Mulyadi Santosa
2013-03-01  5:37     ` Arun KS
2013-03-01 10:56       ` Prabhu nath
2013-03-01 12:50         ` John Smith
2013-03-01 18:28           ` MTD NOR write issue for files greater than a few hundred bytes Holmes, Michael A (Mike)
2013-03-04 15:42 Holmes, Michael A (Mike)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.