Advice needed.

Advice needed.

[W.P.]

Hello,
currently i am "fighting" with Edimax BR-6024Wg, (Realtek-8186 based,
lexra-mips). I need an advice from a system developer/programmer:

1). When using original firmware (EDIMAX-developed Linux-mips), task of
upgrading firmware is done by web server binary: webs, which is GoAhead
2.1.1, BUT Edimax didn't published "applets" -> C functions, that
implement real functionality.

2). In /dev directory there is a block node with mtd name. I have cat'ed
it's contents to /web, and downloaded to PC. File seems to be raw
contents of Flash memory: 2048*1024bytes long. If I drop first 64kB and
truncate file to same length that Edimax-supplied firmware, files show
to be the same (using cmp). The first 64kB looks to contain among
others, variables used in BR system. There is originally an utility
"flash" to get/set variables.

Now the question:
When I will have a new firmware (image) will it be safe(!?) to do such
thing: (instead of using webs binary):
cat /dev/mtd > some.file
dd first 64k of some.file to other.file,
then download image (from PC) to a third.file
cat other.file third.file > /dev/mtd back.??????

W.Piotrzkowski

Re: Advice needed.

[David Daney]

W.P. wrote:
> Hello,
> currently i am "fighting" with Edimax BR-6024Wg, (Realtek-8186 based,
> lexra-mips). I need an advice from a system developer/programmer:
> 
> 1). When using original firmware (EDIMAX-developed Linux-mips), task of
> upgrading firmware is done by web server binary: webs, which is GoAhead
> 2.1.1, BUT Edimax didn't published "applets" -> C functions, that
> implement real functionality.
> 
> 2). In /dev directory there is a block node with mtd name. I have cat'ed
> it's contents to /web, and downloaded to PC. File seems to be raw
> contents of Flash memory: 2048*1024bytes long. If I drop first 64kB and
> truncate file to same length that Edimax-supplied firmware, files show
> to be the same (using cmp). The first 64kB looks to contain among
> others, variables used in BR system. There is originally an utility
> "flash" to get/set variables.
> 
> Now the question:
> When I will have a new firmware (image) will it be safe(!?) to do such
> thing: (instead of using webs binary):
> cat /dev/mtd > some.file
> dd first 64k of some.file to other.file,
> then download image (from PC) to a third.file
> cat other.file third.file > /dev/mtd back.??????

Using cat or dd to write to /dev/mtd? probably will not work.  If there 
is a /dev/mtdblock? perhaps.  Otherwise use the mtd utilities (flashcp 
or nandwrite depending on the type of flash memory) to write to /dev/mtd?.

Take a look at this site for more information:

http://www.linux-mtd.infradead.org/

David Daney

Re: Advice needed.

[W.P.]

<cut>

> If there is a /dev/mtdblock? perhaps.

There is only one node related to mtd:

brw-rw-rw-    1 0        0         31,   0 Aug 29  2006 mtd

Kernel modules supposed by me to be related: mtdlink.o or mtdlink_gw.o
(different size), probably supplied by Realtek or Edimax -> there are
some closed source modules/tools in this toolchain. Kernel is 2.4.18,
gcc 3.3.3, uClibc.

/proc/mtd shows:

mtd0: 00200000 00010000 "DiskOnChip Millennium"

> http://www.linux-mtd.infradead.org/ 

I will, thanks.

I'm looking for the simpliest reliable method of not using webs-included
procedures for programming flash.
What i want, is to be able to reprogram flash with image generated on
PC, that i may download to BR system.

If more information is needed please tell.

W.P.

Re: Advice needed.

[W.P.]

Użytkownik Brett Neumeier napisał:

>On Wed, 2007-01-31 at 19:16 +0100, W.P. wrote:
>  
>
>>I'm looking for the simpliest reliable method of not using webs-included
>>procedures for programming flash.
>>What i want, is to be able to reprogram flash with image generated on
>>PC, that i may download to BR system.
>>    
>>
>
>Suppose that you create a new image on your computer, and program it
>into the flash, and the new image does not boot.
>
>Do you have any way of recovering from that situation?  (This might
>involve something like a JTAG cable.)
>
>  
>
No, I don't have JTAG cable nor software ;(


>If not, I'm not sure how you can really do anything "safely"....
>
>  
>
Now i am changing firmware using supplied tool inside webs program. I am
able to generate working image on a PC.
The problem for now, is how to program it into Flash NOT USING webs
program. Problem i am asking here for help is in
programming flash, not in generating image. If I generate image that
will not boot, i'll have a problem.
Could you help?

W.P.

Re: Advice needed.

[Sergio Aguayo]

Hello

I think you should check my webpage, www.amilda.org. It's a distro for
other Edimax routers, based on the (also MIPS) ADM5120. While the kernel
may not be what you need, the rest is quite the same. It may still be
useful for you.

Regards,

Sergio Aguayo

> Hello,
> currently i am "fighting" with Edimax BR-6024Wg, (Realtek-8186 based,
> lexra-mips). I need an advice from a system developer/programmer:
>
> 1). When using original firmware (EDIMAX-developed Linux-mips), task of
> upgrading firmware is done by web server binary: webs, which is GoAhead
> 2.1.1, BUT Edimax didn't published "applets" -> C functions, that
> implement real functionality.
>
> 2). In /dev directory there is a block node with mtd name. I have cat'ed
> it's contents to /web, and downloaded to PC. File seems to be raw
> contents of Flash memory: 2048*1024bytes long. If I drop first 64kB and
> truncate file to same length that Edimax-supplied firmware, files show
> to be the same (using cmp). The first 64kB looks to contain among
> others, variables used in BR system. There is originally an utility
> "flash" to get/set variables.
>
> Now the question:
> When I will have a new firmware (image) will it be safe(!?) to do such
> thing: (instead of using webs binary):
> cat /dev/mtd > some.file
> dd first 64k of some.file to other.file,
> then download image (from PC) to a third.file
> cat other.file third.file > /dev/mtd back.??????
>
> W.Piotrzkowski
>
>

Re: Advice needed.

[Florian Fainelli]

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

Hello

Le mercredi 31 janvier 2007, Sergio Aguayo a écrit :
> Hello
>
> I think you should check my webpage, www.amilda.org. It's a distro for
> other Edimax routers, based on the (also MIPS) ADM5120. While the kernel
> may not be what you need, the rest is quite the same. It may still be
> useful for you.

The board he is talking about is based on a rtl8186 which has few things in 
common with admtek 5120?

>
> Regards,
>
> Sergio Aguayo
>
> > Hello,
> > currently i am "fighting" with Edimax BR-6024Wg, (Realtek-8186 based,
> > lexra-mips). I need an advice from a system developer/programmer:
> >
> > 1). When using original firmware (EDIMAX-developed Linux-mips), task of
> > upgrading firmware is done by web server binary: webs, which is GoAhead
> > 2.1.1, BUT Edimax didn't published "applets" -> C functions, that
> > implement real functionality.

This might be under particular licensing so that it has not been published. By 
analysing the web uploadable image, you should be able to discover how the 
web image format works. Probably : header, crc check, kernel, rootfs ...

> >
> > 2). In /dev directory there is a block node with mtd name. I have cat'ed
> > it's contents to /web, and downloaded to PC. File seems to be raw
> > contents of Flash memory: 2048*1024bytes long. If I drop first 64kB and
> > truncate file to same length that Edimax-supplied firmware, files show
> > to be the same (using cmp). The first 64kB looks to contain among
> > others, variables used in BR system. There is originally an utility
> > "flash" to get/set variables.

There is probably some kind of nvram on this flash, to store settings. The 
flash utility is probably checking crc on key+variable for instance.

> >
> > Now the question:
> > When I will have a new firmware (image) will it be safe(!?) to do such
> > thing: (instead of using webs binary):
> > cat /dev/mtd > some.file
> > dd first 64k of some.file to other.file,
> > then download image (from PC) to a third.file
> > cat other.file third.file > /dev/mtd back.??????

I think you had better using dd rather than cat, because /dev/mtdblock are 
block devices, and should be treated like that. If your image has a valid 
format, i.e : the bootloader accepts it, unless you made important 
modifications to the system code, it should at least be booting.

> >
> > W.Piotrzkowski



-- 
Cordialement, Florian Fainelli
---------------------------------------------
5, rue Charles Fourier
Chambre 1202
91011 Evry
http://www.alphacore.net
(+33) 01 60 76 64 21
(+33) 06 09 02 64 95
---------------------------------------------
Association MiNET
http://www.minet.net
---------------------------------------------
Institut National des Télécommunication
http://www.int-evry.fr/telecomint
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Advice needed.

[W.P.]

<cut>

>The board he is talking about is based on a rtl8186 which has few things in 
>common with admtek 5120?
>  
>
As i realize, it is a MIPS too, and he's talking about utilities, not
the kernel. (I'll download sources tomorrow, i have only GPRS internet
connection, so i will take several hours, and the i'll examine it). At
least some idea ;)

<cut>

>I think you had better using dd rather than cat, because /dev/mtdblock are 
>block devices, and should be treated like that. If your image has a valid 
>format, i.e : the bootloader accepts it, unless you made important 
>modifications to the system code, it should at least be booting.
>  
>

Using dd also suggests padding resulting file to 2048*1024 bytes, am i
right? And using block size of 64k?
As of image, i remarked, that file resulting from reading /dev/mtd look
like: boot&variables(64k) + original image I have uploaded using Edimax
program(approx 1.9M) + zeros to the end of 2M boundary.

So you think it may work? (dd ?) Image generation and upload using
Edimax-supplied tools works.

W.P.

Re: Advice needed.

[Sergio Aguayo]

> <cut>
>
>>The board he is talking about is based on a rtl8186 which has few things
>> in
>>common with admtek 5120?
>>
>>
> As i realize, it is a MIPS too, and he's talking about utilities, not
> the kernel. (I'll download sources tomorrow, i have only GPRS internet
> connection, so i will take several hours, and the i'll examine it). At
> least some idea ;)
>

The realtek chipset by itself doesn't have many things in common with the
ADM5120. But the board used (in this case by Edimax), is very similar for
both chipsets. Almost the only thing needed to make the software of the
one work in the other is placing some platform-dependent code in the
kernel. The user-space should be quite the same (except the wireless
driver, which is different).

> <cut>
>
>>I think you had better using dd rather than cat, because /dev/mtdblock
>> are
>>block devices, and should be treated like that. If your image has a valid
>>format, i.e : the bootloader accepts it, unless you made important
>>modifications to the system code, it should at least be booting.
>>
>>
>
> Using dd also suggests padding resulting file to 2048*1024 bytes, am i
> right? And using block size of 64k?
> As of image, i remarked, that file resulting from reading /dev/mtd look
> like: boot&variables(64k) + original image I have uploaded using Edimax
> program(approx 1.9M) + zeros to the end of 2M boundary.
>

The structure (of the flash memory) is something like this:

32KB             Boot loader
32KB             Config stuff
rest             Kernel+BZIP2 RAMDISK

The exact size of the kernel and the ramdisk varies greatly between
firmware versions. YOu can find the start of the ramdisk by searching for
the bzip2 signature (in this case 'BZh'). The kernel+ramdisk doesn't have
to occupy the rest of the flash memory: the part not occupied by it is
just undefined and its contents may be whatever.


> So you think it may work? (dd ?) Image generation and upload using
> Edimax-supplied tools works.
>

dd would certainly work. I would suggest you to check the way AMiLDA
generates the firmware image. It's a lot more practical than a dd :D

Regards,

Sergio

> W.P.
>
>
>

Re: Advice needed.

[W.P.]

<cut>

>dd would certainly work. I would suggest you to check the way AMiLDA
>generates the firmware image. It's a lot more practical than a dd :D
>  
>
Thanks, i'll look at this (just finished downloading source). But my
question was NOT concerning GENERATING image (that part
of toolchain works, so let it be), but FLasing it. Normally done by webs
app. And as i see in Amilda, it uses the same scheme -> webs-buried C
function. And I would have an alternative, because of: first -> have no
source for webs-buried functions supplied by Edimax, so I have only
choice of using built binary no chance to simply add some functionality,
second -> webs is quite heavyweight, approx 450kb -> it is a lot on
system with 2M Flash expanded to 5M Ramdisk.

BTW maybe someone reading this knows what Edimax devices have 4M flash?

W.P.

Re: Advice needed.

[Sergio Aguayo]

> Thanks, i'll look at this (just finished downloading source). But my
> question was NOT concerning GENERATING image (that part
> of toolchain works, so let it be), but FLasing it. Normally done by webs
> app. And as i see in Amilda, it uses the same scheme -> webs-buried C
> function. And I would have an alternative, because of: first -> have no
> source for webs-buried functions supplied by Edimax, so I have only
> choice of using built binary no chance to simply add some functionality,
> second -> webs is quite heavyweight, approx 450kb -> it is a lot on
> system with 2M Flash expanded to 5M Ramdisk.
>

The flash memory is represented under Linux as a block device driven by
the mtd driver. Therefore it behaves as a normal block device that can be
read or written to. Basically, webs does a write to that block device.
Earlier versions of the source code released by Edimax included the webs
functions. I think the source download is getting more and more useless on
every revision.

Remember that the whole ramdisk (which has data of less than 3MB) is BZIP2
compressed, and it is concatenated with the kernel and then compressed in
GZIP. That makes 450KB not-so-big in 2MB.


> BTW maybe someone reading this knows what Edimax devices have 4M flash?
>

check this: http://www.linux-mips.org/wiki/Adm5120

Sergio

Re: Advice needed.

[Sergio Aguayo]

> <cut>
>
>>check this: http://www.linux-mips.org/wiki/Adm5120
>>
>>
>>
> Nice ;)
>
> Sergio,
> 1). I am trying now to port the flash utility to BR-6204Wg (different
> data structure), as of now i have succeded to read part of
> hardware-related settings -> nic0, nic1, wlan-mac. As I finish I'll send
> you a copy of related changes needed.

Are you talking about the configuration structure? If so, it varies
between model to model. AMiLDA itself uses a totally different
configuration which may very from version to version.


> 2). I have compiled webs server as-is from Amilda, it compiles, but when
> started just returns with no output. I will investigate this.
>

That means that webs encountered an error starting up. Usually it is due
to another webs instance already running or another process that has port
80 opened.

Sergio

Re: Advice needed.

[Sergio Aguayo]

> <cut>
>
>>Are you talking about the configuration structure? If so, it varies
>>between model to model. AMiLDA itself uses a totally different
>>configuration which may very from version to version.
>>
>>
>>
> Yes.

The configuration structure is difficult to understand (even if you have
the C header containing the struct) because of many conditional compiling
macros (if this model, and not that one or this but not the other, etc).
Just use the "flash" program.

>
>>That means that webs encountered an error starting up. Usually it is due
>>to another webs instance already running or another process that has port
>>80 opened.
>>
>>
> That is not the case, sure.
>

When webs does that, it means that it encountered an error during startup.
If i remember correctly, webs does the following during startup:

- Allocate some memory for its own use.
- Figure out the document root.
- Register asp and cgi functions.
- Bind to port 80 (or whatever it is told to use)

If any of these fail, then you will experience that simpton.

Sergio

Re: Advice needed.

[W.P.]

<cut>

>The configuration structure is difficult to understand (even if you have
>the C header containing the struct)
>  
>
I don't have any header files for flash. Do you? In tarballs for BR,
there is no source for utilities like flash.
I'm trying to "decode" this structure, variable-by-variable. I have used
your flash utility source

>Just use the "flash" program.
>  
>
The one, that comes with original firmware? But what about webs, as i
looked into, this needs too some knowledge of flash datastructures.?


About webs -> will try to add some printf for debugging, and see.

BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will
upload photo i think tomorrow. I have checked this with ohmometer and
pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have
published schema of JTAG cable, but what software shall anyone use?

W.Piotrzkowski.

Re: Advice needed.

[Sergio Aguayo]

> <cut>
>
>>The configuration structure is difficult to understand (even if you have
>>the C header containing the struct)
>>
>>
> I don't have any header files for flash. Do you? In tarballs for BR,
> there is no source for utilities like flash.
> I'm trying to "decode" this structure, variable-by-variable. I have used
> your flash utility source
>

When Edimax was forced to release the sources, they released a different
source archive than the one currently available. That one contained some
more files than the current one does. I'll upload it today for you to
download it.

>>Just use the "flash" program.
>>
>>
> The one, that comes with original firmware? But what about webs, as i
> looked into, this needs too some knowledge of flash datastructures.?
>

webs and the flash program share some sources. Originally, flash's sources
are contained in the LINUX directory of webs.


>
> About webs -> will try to add some printf for debugging, and see.
>

Ok, let me know what your results are.


> BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will
> upload photo i think tomorrow. I have checked this with ohmometer and
> pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have
> published schema of JTAG cable, but what software shall anyone use?
>

That's a JTAG. But AFAIK no software can drive it yet (except maybe some
commercial software?). See forum.amilda.org, forum MODs for some
information that may be useful for you to experiment with jtag.


Sergio

Re: Advice needed.

[Sergio Aguayo]

> <cut>
>
>>The configuration structure is difficult to understand (even if you have
>>the C header containing the struct)
>>
>>
> I don't have any header files for flash. Do you? In tarballs for BR,
> there is no source for utilities like flash.
> I'm trying to "decode" this structure, variable-by-variable. I have used
> your flash utility source
>

When Edimax was forced to release the sources, they released a different
source archive than the one currently available. That one contained some
more files than the current one does. I'll upload it today for you to
download it.

>>Just use the "flash" program.
>>
>>
> The one, that comes with original firmware? But what about webs, as i
> looked into, this needs too some knowledge of flash datastructures.?
>

webs and the flash program share some sources. Originally, flash's sources
are contained in the LINUX directory of webs.


>
> About webs -> will try to add some printf for debugging, and see.
>

Ok, let me know what your results are.


> BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will
> upload photo i think tomorrow. I have checked this with ohmometer and
> pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have
> published schema of JTAG cable, but what software shall anyone use?
>

That's a JTAG. But AFAIK no software can drive it yet (except maybe some
commercial software?). See forum.amilda.org, forum MODs for some
information that may be useful for you to experiment with jtag.


Sergio

Re: Advice needed.

[W.P.]

Użytkownik Sergio Aguayo napisał:

>><cut>
>>When Edimax was forced to release the sources, they released a different
>>source archive than the one currently available. That one contained some
>>more files than the current one does. I'll upload it today for you to
>>download it.
>>    
>>
OK, i'll wait for it. Please notify me.

<cut>

>webs and the flash program share some sources. Originally, flash's sources
>are contained in the LINUX directory of webs.
>
>  
>
This is why i am "disassembling" data structure. Looks like using a lot
of space -> 0x7FFA if the 2 bytes after signature are the length. If i
have found correctly, config data is 0x8000->0xFFFA in mdt, a bit
earlier are hardware parameters: 0x6000, and there is something (maybe
default config) at 0x6400.

>> About webs -> will try to add some printf for debugging, and see.

At this moment, have located, that problem is in flash parameters
loading (before socket binding etc), so i'll finish "dissasembling" and
return to webs.

<cut>

>That's a JTAG. But AFAIK no software can drive it yet (except maybe some
>commercial software?). See forum.amilda.org, forum MODs for some
>information that may be useful for you to experiment with jtag.
>  
>
Will look on the net, it's hard to believe, that no one developed JTAG
open source software.

W.Piotrzkowski.

Re: zImage.elf loads but does not start

[Mirek23]

Hi Andrei,

     Thank you very much for your suggestion. 
I am very grateful for all of your hints. They were always very valuable to
me.

I have set as you mentioned:
#define XPAR_DDR_0_SIZE                 0x2000000

And now all works fine!!!!

The root file system is mounted and I can execute whatever I like from the
rootfile system.
It was just my mistake that I did not noticed the memory size was wrong :(

After all of that I would like to use the GPIO driver to talk to the FPGA
part of the board.
Do you have some experience with that. 

in my xparameters_ml403.h I have two devices defined: LEDs and SWITCHES as
listed below

/* Definitions for peripheral LEDS_8BIT */
#define XPAR_LEDS_8BIT_BASEADDR 0x40000000
#define XPAR_LEDS_8BIT_HIGHADDR 0x4000FFFF
#define XPAR_LEDS_8BIT_DEVICE_ID 0
#define XPAR_LEDS_8BIT_INTERRUPT_PRESENT 0
#define XPAR_LEDS_8BIT_IS_DUAL 0


/* Definitions for peripheral DIP_SWITCHES_8BIT */
#define XPAR_DIP_SWITCHES_8BIT_BASEADDR 0x40020000
#define XPAR_DIP_SWITCHES_8BIT_HIGHADDR 0x4002FFFF
#define XPAR_DIP_SWITCHES_8BIT_DEVICE_ID 1
#define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 0
#define XPAR_DIP_SWITCHES_8BIT_IS_DUAL 0

#define XPAR_GPIO_0_BASEADDR XPAR_LEDS_8BIT_BASEADDR
#define XPAR_GPIO_0_HIGHADDR XPAR_LEDS_8BIT_HIGHADDR
#define XPAR_GPIO_0_IS_DUAL XPAR_LEDS_8BIT_IS_DUAL
#define XPAR_GPIO_0_DEVICE_ID XPAR_LEDS_8BIT_DEVICE_ID
#define XPAR_GPIO_1_BASEADDR XPAR_DIP_SWITCHES_8BIT_BASEADDR
#define XPAR_GPIO_1_HIGHADDR XPAR_DIP_SWITCHES_8BIT_HIGHADDR
#define XPAR_GPIO_1_IS_DUAL XPAR_DIP_SWITCHES_8BIT_IS_DUAL
#define XPAR_GPIO_1_DEVICE_ID XPAR_DIP_SWITCHES_8BIT_DEVICE_ID

but I do not know how exactly to talk to them by means of the xgpio driver.



Best Regards and many many thanks for your support

Mirek




Andrei Konovalov wrote:
> 
> Mirek,
> 
> Miroslaw Dach wrote:
>> I do not know however if the stack is properly configured since I did not 
>> see any parameter in kernel which refers to the stack or heap. 
>> 
>> My bsp i.e xparameteres_ml403.h contains two macros:
>> #define XPAR_DDR_SDRAM_1_MEM0_BASEADDR 0x00000000
>> #define XPAR_DDR_SDRAM_1_MEM0_HIGHADDR 0x01FFFFFF
>> 
>> I have the feeling that they are ignored because I did not find anywhere 
>> in the kernel source those names. 
>> 
>> When kernel boots it prints at the beginning:
>> loaded at:     00400000 004F9138 
>> board data at: 004F7120 004F7138 
>> relocated to:  00404064 0040407C 
>> zimage at:     00404DF1 004F6BBB 
>> avail ram:     004FA000 04000000 
> 
> Have you fixed this?
> 
> For 32 MBytes of DRAM you should have
>    #define XPAR_DDR_0_SIZE                 0x2000000
> in your xparameters_ml403.h file.
> I can't recall the whole story, but EDK 8.2 doesn't
> add this #define when generating the xparameters file,
> so I had to add this line by hand for EDK 8.2 generated
> files. Probably earlier EDK versions did that automatically.
> 
> But your kernel (the bootwrapper to be precise) wouldn't compile
> if XPAR_DDR_0_SIZE were not defined...
> Do you use uboot?
> 
> Thanks,
> Andrei
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10805157
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Advice needed

[Charles Krinke]

I'm having a little trouble with memory mapped registers in both a NAND
chip and a CPLD on an 8541 design where the kernel is based on
linux-2.6.17.11 and mpc85xx_cds_common.

The NAND and CPLD are obviously not part of the memory map of the
mpc85xx_cds_common, and in our case are at local memory addresses
NAND=3D0xFF008000, 32K and CPLD=3D0xFF000000, 32K. Both need to be =
mapped
into memory in Linux.

I am looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c around
platform_init.

I wonder if a Freescale person could give me an opinion of where the
appropriate place is to call settlbcam to allow access to these two 32K
memory regions?

Charles Krinke

advice needed

[Babarovic Ivica]

Hi!

I have a working setup with a vxworks machine sending
data over GPRS modem. It sets up a modem and establish
a ppp link with provider.

Now I have to send some additional data(pictures) which hardware
that vxworks runs on cannot provide. That's why I included a small
industrial board with framegraber an put linux on it. Basically I inserted
this linux box between vxworks box and a GPRS modem connecting
them with serial lines.

Since I need to keep vxworks setup and programs untouched  (it needs to
work as
plug in linux box, plug out linux box) I've come with a following idea.

I made a program that connects serial ports on linux board so vxworks
box can
freely access modem across linux box and initialize it. I'm catching the
"CONNECT" string here  and after that, I break the serial port
connection/exit
program. I start ppp link on serial side towards vxworks and that makes
it happy.

Now the problem comes when I want to attach to a connected stream towards
modem on linux. Remember this stream was created by vxworks box.
I thought I want be having any problems but pppd refuses to connect or
refuses to attach itself to this stream and start ppp negotiation.
I thought pppd will behave similar as when manually dialing to a provider.
Scenario: Minicom, dial, connect, exit minicom, start pppd, ppp link
comes up.

But for some reason pppd refuses this for the stream vxworks box created.

All I get in log is: pppd 2.4.3 started by root, uid 0
no further lines.

Let me add that if I kill this stream somehow(enter minicom and exit)
I can easily establish my own link from scratch. But of course this needs
to be automated. So what do you think is causing pppd not to establish
ppp link with the stream vxworks creates?


I hope I was clear enough since my English is a bit basic. If not please ask
for whatever info you need. I'll provide.


TIA,
I.B.

Re: advice needed

[Bill Unruh]

On Wed, 18 Jan 2006, Babarovic Ivica wrote:

> Hi!
>
> I have a working setup with a vxworks machine sending
> data over GPRS modem. It sets up a modem and establish
> a ppp link with provider.
>
> Now I have to send some additional data(pictures) which hardware
> that vxworks runs on cannot provide. That's why I included a small
> industrial board with framegraber an put linux on it. Basically I inserted
> this linux box between vxworks box and a GPRS modem connecting
> them with serial lines.
>
> Since I need to keep vxworks setup and programs untouched  (it needs to
> work as
> plug in linux box, plug out linux box) I've come with a following idea.
>
> I made a program that connects serial ports on linux board so vxworks
> box can
> freely access modem across linux box and initialize it. I'm catching the
> "CONNECT" string here  and after that, I break the serial port
> connection/exit
> program. I start ppp link on serial side towards vxworks and that makes
> it happy.
>
> Now the problem comes when I want to attach to a connected stream towards
> modem on linux. Remember this stream was created by vxworks box.
> I thought I want be having any problems but pppd refuses to connect or
> refuses to attach itself to this stream and start ppp negotiation.
> I thought pppd will behave similar as when manually dialing to a provider.
> Scenario: Minicom, dial, connect, exit minicom, start pppd, ppp link
> comes up.
>
> But for some reason pppd refuses this for the stream vxworks box created.
>
> All I get in log is: pppd 2.4.3 started by root, uid 0
> no further lines.
>
> Let me add that if I kill this stream somehow(enter minicom and exit)
> I can easily establish my own link from scratch. But of course this needs
> to be automated. So what do you think is causing pppd not to establish
> ppp link with the stream vxworks creates?

Because it is already a ppp link. YOu cannot negotiate another ppp link on
top of a ppp link.

And you now have horrendous timing problems. How do you make sure your
linux box does not send data interleaved with the data from the vxbox?


Can your vsworks box support ethernet? If it can just make an ethernet
connection from Linux to the vxworks. (I have no idea what a vxworks box is
so can make no suggestions)

Why not have the linux box do everything the vxbox does.

>
>
> I hope I was clear enough since my English is a bit basic. If not please ask
> for whatever info you need. I'll provide.
>
>

Re: advice needed

[James Carlson]

Babarovic Ivica writes:
> Since I need to keep vxworks setup and programs untouched  (it needs to
> work as
> plug in linux box, plug out linux box) I've come with a following idea.
> 
> I made a program that connects serial ports on linux board so vxworks
> box can
> freely access modem across linux box and initialize it. I'm catching the
> "CONNECT" string here  and after that, I break the serial port
> connection/exit
> program. I start ppp link on serial side towards vxworks and that makes
> it happy.

PPP itself (irrespective of the hardware or OS in use) generally can't
work that way because it's a network protocol that involves shared
state between the peers.  The local problems of having this somehow
"work" on Linux pale in comparison to the high-level problems.

I can think of two ways to make the overall model work, and perhaps a
few variations on them.  The first (and certainly easiest) method
would be to have two _separate_ PPP links, like this:

	VxWorks <---PPP1---> Linux <---PPP2---> GPRS

In this scenario, the Linux box would see two network interfaces --
probably named "ppp0" and "ppp1."  To get packets from VxWorks out to
the GPRS system, any of the following variations would work:

  - Run NAT on the Linux box so that both VxWorks and the Linux
    applications are behind the same IP address, as far as the GPRS
    device can tell.  If you have inbound connections over GPRS, this
    may be harder to use.

  - Route (forward) between these interfaces.  The VxWorks system and
    the Linux system will need separate IP addresses, and the GPRS
    system will need to know to treat your Linux box as the next hop
    router for the VxWorks system.  If you have cooperation of the
    GPRS provider (unlikely, I'd imagine), this solution would be
    simple.

  - Run application layer proxies on the Linux box.  The VxWorks
    system would connect to SOCKS proxies or other (perhaps custom)
    applications that in turn open connections over the second PPP
    link to the rest of the world.

The other solution, which is much closer to what I think you're
suggesting, but is also much closer to being science fiction, would be
to have the Linux box behave as a custom L2 bridge for PPP traffic.
You'd have to modify the kernel so that it knows how to forward
particular IP packets to the intended receiver, and the pppd daemon so
that it knows how to forward PPP negotiation parameters (IPCP
addresses and the like) between two separate links.  The result would
be something like:

	VxWorks <---PPP1a---> Linux <---PPP1b---> GPRS

Doable, perhaps, but quite an involved project, and something that
would likely require the help of people who know both the Linux kernel
and pppd code _very_ well.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: advice needed

[Babarovic Ivica]

Bill Unruh wrote:

> On Wed, 18 Jan 2006, Babarovic Ivica wrote:
>
>> Hi!
>>
>> I have a working setup with a vxworks machine sending
>> data over GPRS modem. It sets up a modem and establish
>> a ppp link with provider.
>>
>> Now I have to send some additional data(pictures) which hardware
>> that vxworks runs on cannot provide. That's why I included a small
>> industrial board with framegraber an put linux on it. Basically I
>> inserted
>> this linux box between vxworks box and a GPRS modem connecting
>> them with serial lines.
>>
>> Since I need to keep vxworks setup and programs untouched  (it needs to
>> work as
>> plug in linux box, plug out linux box) I've come with a following idea.
>>
>> I made a program that connects serial ports on linux board so vxworks
>> box can
>> freely access modem across linux box and initialize it. I'm catching the
>> "CONNECT" string here  and after that, I break the serial port
>> connection/exit
>> program. I start ppp link on serial side towards vxworks and that makes
>> it happy.
>>
>> Now the problem comes when I want to attach to a connected stream
>> towards
>> modem on linux. Remember this stream was created by vxworks box.
>> I thought I want be having any problems but pppd refuses to connect or
>> refuses to attach itself to this stream and start ppp negotiation.
>> I thought pppd will behave similar as when manually dialing to a
>> provider.
>> Scenario: Minicom, dial, connect, exit minicom, start pppd, ppp link
>> comes up.
>>
>> But for some reason pppd refuses this for the stream vxworks box
>> created.
>>
>> All I get in log is: pppd 2.4.3 started by root, uid 0
>> no further lines.
>>
>> Let me add that if I kill this stream somehow(enter minicom and exit)
>> I can easily establish my own link from scratch. But of course this
>> needs
>> to be automated. So what do you think is causing pppd not to establish
>> ppp link with the stream vxworks creates?
>
>
> Because it is already a ppp link. YOu cannot negotiate another ppp
> link on
> top of a ppp link.

Ppp link is not yet established by vxworks box since I disconnect the serial
line between vxworks box and modem immediately after I catch CONNECT string.
So when this happens:
CONNECT
~ÿ}#.!}!}#} }9}"}&} }*} } }'}"}(}"}%}&..qq}#}%.#}%.};~~ÿ}#.!}!}#} }9}"}&}

I break the serial line connection right after CONNECT string and unplug
the vxworks
side. Then I establish pppd over serial line with vxworks box without
problems with:
#!/bin/sh
exec /usr/sbin/pppd /dev/ttyS0 19200 novj novjccomp crtscts lock
proxyarp  192.168.254.150:192.168.254.151 debug


At the same time I try to connect linux pppd to the upper stream.:
~ÿ}#.!}!}#} }9}"}&} }*} } }'}"}(}"}%}&..qq}#}%.#}%.};~~ÿ}#.!}!}#} }9}"}&}
I guess, I naively expected this to work. When I tried same thing
manually with minicom
I saw things aren't working as I expected. I thought this was possible
since this was
my experience from the past and I read it in ppp howto. Maybe PPP over GPRS
is different.
I think I will just kill this stream and start a brand new GPRS ppp
connection from
linux side. Problem is that vxwoks side isn't happy until it gets
CONNECT string.
It constantly retry to init modem and dial out until CONNECT. As I mentioned
I can't mess with vxworks since it would require upgrading SW on a lot
of boxes.

BTW: How do I kill/clear the serial lines so I can start new connection?
Will +++ in chat script suffice?


> Can your vsworks box support ethernet? If it can just make an ethernet
> connection from Linux to the vxworks. (I have no idea what a vxworks
> box is
> so can make no suggestions)

Unfortunately there is no Ethernet on vxworks box. Things would be much
simpler that way. :)

>
>
> Why not have the linux box do everything the vxbox does.

Because software on vxworks box is configured that way. If I don't
give him what it wants at certain times it does all sort of
things(powers off modem, restarts itself, ...). I cannot change it. I
can but it would involve changing a lot of vxworks boxes and I wasn't to
keep them as they are. Programs on vxworks boxes expects certain things
on its serial ports at certain times and I have to make them happy with
a proper setup a linux box. :)

In short ... vxworks box must not notice there's anything between it and
modem.

regards,
i.B.

Re: advice needed

[Babarovic Ivica]

James Carlson wrote:

>Babarovic Ivica writes:
>  
>
>>Since I need to keep vxworks setup and programs untouched  (it needs to
>>work as
>>plug in linux box, plug out linux box) I've come with a following idea.
>>
>>I made a program that connects serial ports on linux board so vxworks
>>box can
>>freely access modem across linux box and initialize it. I'm catching the
>>"CONNECT" string here  and after that, I break the serial port
>>connection/exit
>>program. I start ppp link on serial side towards vxworks and that makes
>>it happy.
>>    
>>
>
>PPP itself (irrespective of the hardware or OS in use) generally can't
>work that way because it's a network protocol that involves shared
>state between the peers.  The local problems of having this somehow
>"work" on Linux pale in comparison to the high-level problems.
>
>I can think of two ways to make the overall model work, and perhaps a
>few variations on them.  The first (and certainly easiest) method
>would be to have two _separate_ PPP links, like this:
>
>	VxWorks <---PPP1---> Linux <---PPP2---> GPRS
>
>In this scenario, the Linux box would see two network interfaces --
>probably named "ppp0" and "ppp1."  To get packets from VxWorks out to
>the GPRS system, any of the following variations would work:
>
>  - Run NAT on the Linux box so that both VxWorks and the Linux
>    applications are behind the same IP address, as far as the GPRS
>    device can tell.  If you have inbound connections over GPRS, this
>    may be harder to use.
>  
>
This is exactly my setup and since I don't have inbound connections
things are simple.
I manage to get things working last night. I'm having minor problems
with establishing
a new GPRS ppp from linux box after I break the connection stream that
vxworks box
created. I need to break that stream with some commands to chat. I'm working
on it now.


>  - Route (forward) between these interfaces.  The VxWorks system and
>    the Linux system will need separate IP addresses, and the GPRS
>    system will need to know to treat your Linux box as the next hop
>    router for the VxWorks system.  If you have cooperation of the
>    GPRS provider (unlikely, I'd imagine), this solution would be
>    simple.
>
>  - Run application layer proxies on the Linux box.  The VxWorks
>    system would connect to SOCKS proxies or other (perhaps custom)
>    applications that in turn open connections over the second PPP
>    link to the rest of the world.
>
>The other solution, which is much closer to what I think you're
>suggesting, but is also much closer to being science fiction, would be
>to have the Linux box behave as a custom L2 bridge for PPP traffic.
>You'd have to modify the kernel so that it knows how to forward
>particular IP packets to the intended receiver, and the pppd daemon so
>that it knows how to forward PPP negotiation parameters (IPCP
>addresses and the like) between two separate links.  The result would
>be something like:
>
>	VxWorks <---PPP1a---> Linux <---PPP1b---> GPRS
>
>Doable, perhaps, but quite an involved project, and something that
>would likely require the help of people who know both the Linux kernel
>and pppd code _very_ well.
>
>  
>
Very interesting ideas indeed. I think I don't have enough time and
knowledge yet to
implement them. It is an interesting solution to the problem though.

Best regards,
I.B.

Re: advice needed

[Bill Unruh]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5398 bytes --]

On Thu, 19 Jan 2006, Babarovic Ivica wrote:

> Bill Unruh wrote:
>
>> On Wed, 18 Jan 2006, Babarovic Ivica wrote:
>>
>>> Hi!
>>>
>>> I have a working setup with a vxworks machine sending
>>> data over GPRS modem. It sets up a modem and establish
>>> a ppp link with provider.
>>>
>>> Now I have to send some additional data(pictures) which hardware
>>> that vxworks runs on cannot provide. That's why I included a small
>>> industrial board with framegraber an put linux on it. Basically I
>>> inserted
>>> this linux box between vxworks box and a GPRS modem connecting
>>> them with serial lines.
>>>
>>> Since I need to keep vxworks setup and programs untouched  (it needs to
>>> work as
>>> plug in linux box, plug out linux box) I've come with a following idea.
>>>
>>> I made a program that connects serial ports on linux board so vxworks
>>> box can
>>> freely access modem across linux box and initialize it. I'm catching the
>>> "CONNECT" string here  and after that, I break the serial port
>>> connection/exit
>>> program. I start ppp link on serial side towards vxworks and that makes
>>> it happy.
>>>
>>> Now the problem comes when I want to attach to a connected stream
>>> towards
>>> modem on linux. Remember this stream was created by vxworks box.
>>> I thought I want be having any problems but pppd refuses to connect or
>>> refuses to attach itself to this stream and start ppp negotiation.
>>> I thought pppd will behave similar as when manually dialing to a
>>> provider.
>>> Scenario: Minicom, dial, connect, exit minicom, start pppd, ppp link
>>> comes up.
>>>
>>> But for some reason pppd refuses this for the stream vxworks box
>>> created.
>>>
>>> All I get in log is: pppd 2.4.3 started by root, uid 0
>>> no further lines.
>>>
>>> Let me add that if I kill this stream somehow(enter minicom and exit)
>>> I can easily establish my own link from scratch. But of course this
>>> needs
>>> to be automated. So what do you think is causing pppd not to establish
>>> ppp link with the stream vxworks creates?
>>
>>
>> Because it is already a ppp link. YOu cannot negotiate another ppp
>> link on
>> top of a ppp link.
>
> Ppp link is not yet established by vxworks box since I disconnect the serial
> line between vxworks box and modem immediately after I catch CONNECT string.
> So when this happens:
> CONNECT
> ~ÿ}#.!}!}#} }9}"}&} }*} } }'}"}(}"}%}&..qq}#}%.#}%.};~~ÿ}#.!}!}#} }9}"}&}
>
> I break the serial line connection right after CONNECT string and unplug
> the vxworks
> side. Then I establish pppd over serial line with vxworks box without
> problems with:
> #!/bin/sh
> exec /usr/sbin/pppd /dev/ttyS0 19200 novj novjccomp crtscts lock
> proxyarp  192.168.254.150:192.168.254.151 debug
>
>
> At the same time I try to connect linux pppd to the upper stream.:
> ~ÿ}#.!}!}#} }9}"}&} }*} } }'}"}(}"}%}&..qq}#}%.#}%.};~~ÿ}#.!}!}#} }9}"}&}
> I guess, I naively expected this to work. When I tried same thing
> manually with minicom
> I saw things aren't working as I expected. I thought this was possible
> since this was
> my experience from the past and I read it in ppp howto. Maybe PPP over GPRS
> is different.
> I think I will just kill this stream and start a brand new GPRS ppp
> connection from
> linux side. Problem is that vxwoks side isn't happy until it gets
> CONNECT string.
> It constantly retry to init modem and dial out until CONNECT. As I mentioned
> I can't mess with vxworks since it would require upgrading SW on a lot
> of boxes.
>
> BTW: How do I kill/clear the serial lines so I can start new connection?
> Will +++ in chat script suffice?
>
>
>> Can your vsworks box support ethernet? If it can just make an ethernet
>> connection from Linux to the vxworks. (I have no idea what a vxworks
>> box is
>> so can make no suggestions)
>
> Unfortunately there is no Ethernet on vxworks box. Things would be much
> simpler that way. :)
>
>>
>>
>> Why not have the linux box do everything the vxbox does.
>
> Because software on vxworks box is configured that way. If I don't
> give him what it wants at certain times it does all sort of
> things(powers off modem, restarts itself, ...). I cannot change it. I
> can but it would involve changing a lot of vxworks boxes and I wasn't to
> keep them as they are. Programs on vxworks boxes expects certain things
> on its serial ports at certain times and I have to make them happy with
> a proper setup a linux box. :)
>
> In short ... vxworks box must not notice there's anything between it and
> modem.
>
I guess what you could do is to make the Linux box pretend it is a modem.
Ie, set up a ppp connection between the Linux box and the vxworks box, and
then set up a separate ppp connection between the Linux box and modem.
So the linux box listens on the serial line from the vxbox. When it gets
the AT message it responds with "CONNECT" and then starts up a ppp
negotiation. The VXbox then is happy with a connection to the linux box.
The linux box simultaneously dials out to the GPRS modem. and opens a ppp
connection to there, and routes all the vxworks box stuff out through that
connection. Ie, it is acting as a router between itself and the vxbox.
Tehre are two separate ppp connections-- from the vxbox to the linux box
and from the linux box to the GPRS modem.