2010年3月3日 星期三

802.1X raidus + EAP(TLS)

RADIUS protocol http://www.untruth.org/~josh/security/radius/radius-auth.html
PPP EAP TLS Authentication Protocol: http://www.ietf.org/rfc/rfc2716.txt


RADIUS (Remote Authentication Dial In User Service)
Support For Extensible Authentication Protocol (EAP)

http://www.ietf.org/rfc/rfc3579.txt

----------------------------------------------------------------------------------

Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP LCP Request-EAP
                           auth
   PPP LCP ACK-EAP
   auth ->
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS Start)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                            TLS certificate,
                    [TLS server_key_exchange,]
                    [TLS certificate_request,]
                        TLS server_hello_done)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
   [TLS certificate_verify,]
    TLS change_cipher_spec,
    TLS finished) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS change_cipher_spec,
                            TLS finished)
   PPP EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- PPP EAP-Success
   PPP Authentication
   Phase complete,
   NCP Phase starts
----------------
FreeRadius + EAP with 802.1X wireless WPA.
[peter@localhost certs]$ pwd
/pub/rootfs/etc/raddb/certs
[peter@localhost certs]$ ls
01.pem      ca.key      index.txt       random      server.cnf  server.p12
bootstrap*  ca.pem      index.txt.attr  README      server.crt  server.pem
ca.cnf      client.cnf  index.txt.old   serial      server.csr  xpextensions
ca.der      dh          Makefile        serial.old  server.key

1. install ca.pem and server.pem to windows.(rename as *.cer in windows).
    for more info of x509, see README for HOWTO EAP...
2. load ca.pem and server.pem. into windows.
3. start freeradius by #radius -X

freeradius是由radius 支援 各種module(包含eap)

[peter@localhost main]$ ls ../modules/
lib/               rlm_copy_packet/      rlm_exec/        rlm_logintime/      rlm_protocol_filter/  rlm_sql_log/
Makefile           rlm_counter/          rlm_expiration/  rlm_mschap/         rlm_python/           rlm_unix/
rlm_acctlog/       rlm_cram/             rlm_expr/        rlm_opendirectory/  rlm_radutmp/          rlm_wimax/
rlm_acct_unique/   rlm_dbm/              rlm_fastusers/   rlm_otp/            rlm_realm/            rules.mak
rlm_always/        rlm_detail/           rlm_files/       rlm_pam/            rlm_sim_files/        stable
rlm_attr_filter/   rlm_digest/           rlm_ippool/      rlm_pap/            rlm_smb/
rlm_attr_rewrite/  rlm_dynamic_clients/  rlm_jradius/     rlm_passwd/         rlm_sql/
rlm_caching/       rlm_eap/              rlm_krb5/        rlm_perl/           rlm_sqlcounter/
rlm_chap/          rlm_eap2/             rlm_ldap/        rlm_policy/         rlm_sqlhpwippool/
rlm_checkval/      rlm_example/          rlm_linelog/     rlm_preprocess/     rlm_sqlippool/


其中我要try的是eap+tls,也就是wifi的wpa enterprise
而eap也只是個protocol的frame,tls就是包在eap。


trace code:
freeradus是以module來plugin各種module。(eap也是個module)
例如: freeradius-server-2.1.1/src/modules/rlm_example/rlm_example.c


    218 module_t rlm_example = {
    219         RLM_MODULE_INIT,
    220         "example",
    221         RLM_TYPE_THREAD_SAFE,           /* type */
    222         example_instantiate,            /* instantiation */
    223         example_detach,                 /* detach */
    224         {
    225                 example_authenticate,   /* authentication */
    226                 example_authorize,      /* authorization */
    227                 example_preacct,        /* preaccounting */
    228                 example_accounting,     /* accounting */
    229                 example_checksimul,     /* checksimul */
    230                 NULL,                   /* pre-proxy */
    231                 NULL,                   /* post-proxy */
    232                 NULL                    /* post-auth */
    233         },
    234 };




整個架構是以一個status machine來design,所以trace起來還滿吃力的…


modules/rlm_eap/eap.c                  #EAP module from RADIUS.
modules/rlm_eap/rlm_eap.c          #






EAP module from RADIUS, loadable module.

modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c     #TLS module plug by EAP module.
modules/rlm_eap/libeap/eap_tls.c   #library TLS for TLS, TTLS, PEAP ...


討厭的是,TLS module for EAP也只是frame,它完全只是由openssl來implementation。
所以radius的eap+tls要由openssl的support.


先了解openssl的架構,openssl library是由ssl protocol和cipher組成
而SSL_xxx是protocol的部分,它包含了BIO_xxx,BIO_xxx是用來hook protocol的I/O stream。
BIO_read/BIO_write是我tracecode的重點。


我在

modules/rlm_eap/libeap/tls.c找到了



BIO_read在 

int tls_handshake_recv(tls_session_t *ssn)和



       int tls_handshake_send(tls_session_t *ssn)


BIO_write 在int tls_handshake_recv(tls_session_t *ssn)和
  [


modules/rlm_eap/libeap/eap_tls.c ] eaptls_status_t eaptls_process(EAP_HANDLER *handler)






再來要看這些functions是如何cowork的


2009年12月1日 星期二

memory leak trace utility

最近在trace directfb有memory leak的的issue
所以找了一些方法來驗證
1. 真的有memory leak的問題嗎?
2. 如何去找到未被free掉的memory
3. 是library實作的"小問題"還是directfb本身的問題…

後來發現有個valgrind的utility還真好用
且libc也有提供trace的interface

http://mail.gnome.org/archives/gtk-list/2008-May/msg00008.html


$ cat test1.c
#include
#include

int main()
{
mtrace();

GHashTable* hash_table;

hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);

return 1;
}


$ gcc test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ export MALLOC_TRACE=0.mtrace.log
$ ./test1; mtrace ./test1 $MALLOC_TRACE

Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x7f0 at 0x3fea834002
0x0000000000602400 0x3f0 at 0x3fea8423e1
0x0000000000602800 0x3f0 at 0x3fea8423e1

Now, when the G_ macros are defined, less memory is reported as leaked.

$ export G_DEBUG=gc-friendly
$ export G_SLICE=always-malloc
$ ./test1; mtrace ./test1 $MALLOC_TRACE

Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002

Simple cases such as:

malloc(20);
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);

can be easily caught by adding the -g option when compiling:

$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE

Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x14 at /home/user/devel/linux/glib/test1.c:13 <-------- obviously, your code does not free allocated memory
0x0000000000601480 0x1f8 at 0x3fea834002
0x0000000000601680 0xfc at 0x3fea834002
0x0000000000601790 0x1f8 at 0x3fea834002

But when leaks are related to not using glib properly, such as not calling unref, things are more difficult to diagnose:

GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);

$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE

Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x38 at 0x3fea83407b
0x00000000006019b0 0x58 at 0x3fea834002 <----------- Is there an memory allocation error? If yes, where and why?

With valgrind, the diagnostics is much better though (note the --leak-check=full option for valgrind and the -g option for gcc):

$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full ./test1
--- some lines cut out
==4071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==4071== malloc/free: in use at exit: 2,484 bytes in 7 blocks.
==4071== malloc/free: 7 allocs, 0 frees, 2,484 bytes allocated.
==4071== For counts of detected errors, rerun with: -v
==4071== searching for pointers to 7 not-freed blocks.
==4071== checked 74,704 bytes.
==4071==
==4071== 144 (56 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5
==4071== at 0x4A05996: malloc (vg_replace_malloc.c:149)
==4071== by 0x3FEA83407A: g_malloc (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x3FEA820CF2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x4005E3: main (test1.c:13) <----------------------------------------------------------- AHA! there's the culprit
--- some lines cut out

And when the leak is fixed (add an unref call to the code above), the valgrind output looks better:

==4105== LEAK SUMMARY:
==4105== definitely lost: 0 bytes in 0 blocks.
==4105== possibly lost: 0 bytes in 0 blocks.
==4105== still reachable: 2,340 bytes in 5 blocks.
==4105== suppressed: 0 bytes in 0 blocks.

2009年10月22日 星期四

x11 frambuffer

在configure directfb時沒辦法找到truetype的fonts library …header file: "X11/X.h"

1) 為了libxorg-x11-devel-6.7.0-3mdk.i586.rpm我加的rpm有…
[peter@localhost x]$ ls
fontconfig-2.2.1-7mdk.i586.rpm
fontconfig-2.2.96-7mdk.i586.rpm
index.html
index.html.1
libexpat0-1.95.6-4mdk.i586.rpm
libexpat0-devel-1.95.6-4mdk.i586.rpm
libfontconfig1-2.2.1-7mdk.i586.rpm
libfontconfig1-devel-2.2.1-7mdk.i586.rpm
libjpeg62-devel-6b-33mdk.i586.rpm
libjpeg62-static-devel-6b-33mdk.i586.rpm
libpng3-devel-1.2.6-2mdk.i586.rpm
libpng3-static-devel-1.2.6-2mdk.i586.rpm
libxorg-x11-devel-6.7.0-3mdk.i586.rpm
libxpm4-3.4k-27mdk.i586.rpm
libxpm4-devel-3.4k-27mdk.i586.rpm
[peter@localhost x]$


2)

ftp://ftp.isu.edu.tw/pub/Linux/Mandriva/official/10.0/i586/Mandrake/RPMS/


I add ftp to urpmi below...
urpmi.addmedia rpmftp ftp://ftp.isu.edu.tw/pub/Linux/Mandriva/official/10.0/i586/Mandrake/RPMS/
but seems still can not work.

[root@localhost rpms]# rpm -ivh libxorg-x11-devel-6.7.0-3mdk.i586.rpm
error: Failed dependencies:
fontconfig-devel >= 2.1-4mdk is needed by libxorg-x11-devel-6.7.0-3mdk
devel(libXpm) is needed by libxorg-x11-devel-6.7.0-3mdk
devel(libexpat) is needed by libxorg-x11-devel-6.7.0-3mdk
devel(libfontconfig) is needed by libxorg-x11-devel-6.7.0-3mdk
1) in
./configure --enable-x11 --with-gfxdrivers=none --prefix=/pub/rootfs --enable-vnc --enable-freetype --enable-x11


Build options:
Version 1.4.2
Linux powered yes
Install prefix /pub/rootfs
Config files in /pub/rootfs/etc
Build shared libs yes
Build static libs no
Module directory ${exec_prefix}/lib/directfb-1.4-0
CPPFLAGS -D_REENTRANT
CFLAGS -O3 -ffast-math -pipe -D_GNU_SOURCE -Werror-implicit-function-declaration
LDFLAGS
LIBS -ldl -lpthread
DYNLIB -ldl
THREADFLAGS -D_REENTRANT
THREADLIBS

Misc options:
Multi Application Core no
Fusion Kernel Device N/A
Fusion message size 1024
Voodoo (network support) no
Debug supported yes
Debug enabled no
Trace support no
MMX support yes
SSE support yes
Network support yes
Include all strings yes
Software Rendering yes
Smooth SW Scaling no
16bit Dithering none
zlib compression no -lz
sysfs support no

Building Tests no
Building Tools yes

Building System Modules:
Linux FBDev support yes
Generic /dev/mem support yes
X11 support yes -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lXext
OSX support no
SDL support no
VNC support no

Building Window Manager Modules:
Default yes
UniQuE no

Building Image Provider Modules:
GIF yes
JPEG no
PNG no

Building Video Provider Modules:
GIF yes
Video4Linux yes (v2: no)

Building Font Modules:
FreeType2 yes -I/usr/include/freetype2 -lfreetype -lz
Default font yes

Building Graphics Drivers:
3Dfx Voodoo no
ATI Mach64 no
ATI Rage 128 no
ATI Radeon no
Cirrus EP9X no
Intel i810 no
Intel i830 no
Matrox no
NeoMagic no
NSC Geode no
nVidia no
PXA 3xx no
Renesas SH7722/SH7723 no
S3 Savage no
SiS 315 no
TI Davinci no
TI OMAP no
TVIA CyberPro no
VIA CLE266 no
VIA UniChrome no
VMWare no
--
OpenGL no (GLX: no)

Building Input Drivers:
DBox2 Remote no
DreamBox Remote no
Dynapro Touchscreen no
ELO Touchscreen no
Gunze Touchscreen no
H3600 Touchscreen no
Joystick yes
Keyboard yes
Linux Input yes
LiRC yes
MuTouch touchscreen yes
Zytronic touchscreen yes
PS/2 Mouse yes
Serial Mouse yes
SonyPI Jogdial yes
tslib no
ucb1x00 Touchscreen no
WM97xx Touchscreen yes

PNG support is missing - many applications won't work correctly!
JPEG support is missing - many applications won't work correctly!

2009年6月23日 星期二

VMA vs LMA 的文章

http://www.embeddedrelated.com/usenet/embedded/show/77071-1.php

Hi!

What is the difference between VMA (Virtual Memory Address) and LMA
(Load Memory Address)?

The Gnu ld documentation has the following explanation:
"Every loadable or allocatable output section has two addresses. The
first is the VMA, or virtual memory address. This is the address the
section will have when the output file is run. The second is the LMA,
or load memory address. This is the address at which the section will
be loaded. In most cases the two addresses will be the same. An
example of when they might be different is when a data section is
loaded into ROM, and then copied into RAM when the program starts up
(this technique is often used to initialize global variables in a ROM
based system). In this case the ROM address would be the LMA, and the
RAM address would be the VMA. "

In the above, "who" copies the data section from ROM to RAM? Isn't
this the same as when a program that is started from a shell is copied
from the harddrive to RAM by a loader, i.e. normal procedure?

As far as I have understood things the loader loads the executable
into RAM (from secondary storage) and then execution starts. So to me
the address of a section when it is run (VMA) is the same as the
address to where the section is loaded (LMA)?

If a section can be loaded to one address and then moved to another
section when run, who then moves the section from the load address
(LMA) to the run address (VMA)?

When is the LMA referenced (and by who) and when is the VMA referenced
(and by who)?

BRs!




Re: VMA vs LMA? - David Brown - 2007-08-29 07:19:00

dspfun wrote:
> Hi!
>
> What is the difference between VMA (Virtual Memory Address) and LMA
> (Load Memory Address)?
>

Your quotation from the ld documentation explains that pretty well, I
thought.

> The Gnu ld documentation has the following explanation:
> "Every loadable or allocatable output section has two addresses. The
> first is the VMA, or virtual memory address. This is the address the
> section will have when the output file is run. The second is the LMA,
> or load memory address. This is the address at which the section will
> be loaded. In most cases the two addresses will be the same. An
> example of when they might be different is when a data section is
> loaded into ROM, and then copied into RAM when the program starts up
> (this technique is often used to initialize global variables in a ROM
> based system). In this case the ROM address would be the LMA, and the
> RAM address would be the VMA. "
>
> In the above, "who" copies the data section from ROM to RAM? Isn't
> this the same as when a program that is started from a shell is copied
> from the harddrive to RAM by a loader, i.e. normal procedure?
>

No, these are different situations. When an OS loads code from a file,
the OS does the copying. Usually the VMA and LMA are the same, so that
the OS loads the initialised data section directly into place. With a
ROM'ed program, where the program is run directly from the ROM rather
than being first copied into RAM (in which case you have the same
situation as an OS and a file), the code at the beginning of the program
copies the data across and also clears the bss - this is part of the
crt0 startup code.

> As far as I have understood things the loader loads the executable
> into RAM (from secondary storage) and then execution starts. So to me
> the address of a section when it is run (VMA) is the same as the
> address to where the section is loaded (LMA)?
>

That is the case *if* the program is copied into RAM before running.

> If a section can be loaded to one address and then moved to another
> section when run, who then moves the section from the load address
> (LMA) to the run address (VMA)?
>
> When is the LMA referenced (and by who) and when is the VMA referenced
> (and by who)?
>

See above.


> BRs!
>

Re: VMA vs LMA? - larwe - 2007-08-29 08:55:00

On Aug 29, 7:19 am, David Brown 
wrote:

> ROM'ed program, where the program is run directly from the ROM rather
> than being first copied into RAM (in which case you have the same
> situation as an OS and a file), the code at the beginning of the program
> copies the data across and also clears the bss - this is part of the

The other place where it's common to see VMA != LMA (and code that
cares about the difference) is when initializing the MMU. You may have
code that's physically contiguous across a block of LMAs, but the
first few bytes set up the MMU and execution then passes to a new VMA.


Re: VMA vs LMA? - dspfun - 2007-08-29 10:23:00

Thanks for your response!

So, the program is always linked with the VMA addresses, and never
linked with LMA addresses? Or how are references to LMA/VMA sections
resolved?

When writing a program where one wants different LMA and VMA sections
the programmer himself/hersel has to make sure he/she writes the code
that copies the LMA section/data to its appropriate VMA address?


> No, these are different situations. When an OS loads code from a file,
> the OS does the copying. Usually the VMA and LMA are the same, so that
> the OS loads the initialised data section directly into place. With a
> ROM'ed program, where the program is run directly from the ROM rather
> than being first copied into RAM (in which case you have the same
> situation as an OS and a file), the code at the beginning of the program
> copies the data across and also clears the bss - this is part of the
> crt0 startup code.

Why does crt0 (C runtime 0) have code that copies data from LMA to
VMA? Is it there so the C programmer doesn't have to write his own
"LMA data to VMA data copy code"? If so, how would one make use of the
crt0 "LMA data to VMA data copy code"?



Re: VMA vs LMA? - David Brown - 2007-08-30 03:04:00

dspfun wrote:
> Thanks for your response!
>
> So, the program is always linked with the VMA addresses, and never
> linked with LMA addresses? Or how are references to LMA/VMA sections
> resolved?
>

They are not resolved. Consider the different possible cases:

LMA/VMA are the same, because you are running entirely from RAM.
There's no problem, and nothing more to think about.

LMA/VMA are different because you are using a processor with an MMU on a
big system (such as a PC). Let the native tools handle the linking and
let the OS handle the loading, and forget the details.

LMA/VMA are different because you are using a small system with an MMU
but no OS (or only a limited OS). Forget it until you understand a bit
more about what you are doing.

LMA/VMA are different because you have a program in flash, initialised
data in flash, and variables in ram. This is extremely common in
embedded systems - I'll assume this is the situation you are talking
about here from now on.

For the code section, the LMA and the VMA are the same - the program
runs directly from the flash it resides in. Similarly, the LMA and VMA
for bss data (i.e., uninitialised data that is cleared at startup) is
the same, although the LMA doesn't really matter as nothing is ever
loaded. The only complication is the initialised data section, which
can be thought of as two parts - a RAM block containing the variables
(this is at the VMA), and a flash block containing their initial values
(at the LMA). Startup code copies the initial values into the ram.

The linking process "resolves" accesses to symbols (code or data), using
only VMA addresses - it is only interested in how the memory looks once
the program has started. The only exception is that the startup code
also refers to the LMA of the data section, so that it can do the
initial copy.

> When writing a program where one wants different LMA and VMA sections
> the programmer himself/hersel has to make sure he/she writes the code
> that copies the LMA section/data to its appropriate VMA address?
>

No, it's part of the crt0 code - the code generated by your compiler,
library and linker in collusion, which runs before the start of main().
Sometimes it's useful to write this sort of stuff yourself, but that
is considered relatively advanced and you don't want to go there until
you understand the process better.

>
>> No, these are different situations. When an OS loads code from a file,
>> the OS does the copying. Usually the VMA and LMA are the same, so that
>> the OS loads the initialised data section directly into place. With a
>> ROM'ed program, where the program is run directly from the ROM rather
>> than being first copied into RAM (in which case you have the same
>> situation as an OS and a file), the code at the beginning of the program
>> copies the data across and also clears the bss - this is part of the
>> crt0 startup code.
>
> Why does crt0 (C runtime 0) have code that copies data from LMA to
> VMA? Is it there so the C programmer doesn't have to write his own
> "LMA data to VMA data copy code"? If so, how would one make use of the
> crt0 "LMA data to VMA data copy code"?
>

If you follow your compiler's documentation and examples, you'll see
this initial copying happening "magically" - standard linker scripts
will ensure the code is linked in. You did not say which processor you
were using, but many gcc setups come with sets of linker scripts
including "ram" and "rom" versions - the "rom" versions will do this
initial copying.

Write yourself a tiny program with initialised data, generate the object
files, and examine the result by reading the disassembly or by using a
debugger to single-step at the assembly level through the startup code.
That will make it clear what is happening.

Re: VMA vs LMA? - Mike_big - 2008-02-25 10:41:00

Hi,

I still cannot understand the difference between both since I'm a
beginner yet.

In my case, I have a ldscript which will be linked by the linker to
form an image.

But when I look into the ldscipt, something puzzles me a lot. It sets
the memory as below:

MEMORY{
flash (rx) : ORIGIN = 0x80000000, LENGTH = 0x00200000
ram (!rx) : ORIGIN = 0x82000000, LENGTH = 0x00200000
loadregion : ORIGIN = 0xA2000000, LENGTH = 0x00200000
}

And the SECTION part
SECTIONS{
.text : { _stext = .; _ftext = . ; *(.text) *(.text.*) ...; } >flash
AT>loadregion =0 _etext = .; PROVIDE (etext = .);
...
.data : { . = ALIGN(0x40); _fdata = . ; *(.data) *(.data.*) . =
ALIGN (8); } >ram AT>loadregion
...
}

What confused me most is the fact that the real flash address is start
from 0xA0000000 and the real memory address is start from 0xA2000000.

According to you, the LMA now becomes RAM address, but the VMA becomes
Flash address?
Since the codes will run in Flash, how and what the LMA functions?

But if I change the LMA, say modifying the loadregion part to a
different address like 0xc8000000, the image will not even run. Why?

I have read the ld document for details but get nothing helpful.
Does anyone give me some comments?

Thanks!

Mike






Re: VMA vs LMA? - faraz_naqvi - 2009-02-10 16:40:00

>Hi,
>
> I still cannot understand the difference between both since I'm a
>beginner yet.
>
> In my case, I have a ldscript which will be linked by the linker to
>form an image.
>
> But when I look into the ldscipt, something puzzles me a lot. It
sets
>the memory as below:
>
> MEMORY{
> flash (rx) : ORIGIN = 0x80000000, LENGTH = 0x00200000
> ram (!rx) : ORIGIN = 0x82000000, LENGTH = 0x00200000
> loadregion : ORIGIN = 0xA2000000, LENGTH = 0x00200000
> }
>
> And the SECTION part
> SECTIONS{
> .text : { _stext = .; _ftext = . ; *(.text) *(.text.*) ...; }
>flash
>AT>loadregion =0 _etext = .; PROVIDE (etext = .);
> ...
> .data : { . = ALIGN(0x40); _fdata = . ; *(.data) *(.data.*) . =
>ALIGN (8); } >ram AT>loadregion
> ...
> }
>
> What confused me most is the fact that the real flash address is
start
>from 0xA0000000 and the real memory address is start from 0xA2000000.
>
> According to you, the LMA now becomes RAM address, but the VMA
becomes
>Flash address?
> Since the codes will run in Flash, how and what the LMA functions?
>
> But if I change the LMA, say modifying the loadregion part to a
>different address like 0xc8000000, the image will not even run. Why?
>
> I have read the ld document for details but get nothing helpful.
> Does anyone give me some comments?
>
>Thanks!
>
> Mike
>
>
>
>
>


hi, in my application , my data is too big and when load into target i
got not enough memory message , so i decided to put my data into ROM using
VMA and then load it when i need using LMA. simple.

but i dont know how to tell compiler about VMA and LMA.
any link or example is very helpful.

Thanks

Re: VMA vs LMA? - rickman - 2009-02-11 20:36:00

On Feb 10, 4:40=A0pm, "faraz_naqvi"  wrote:
> >Hi,
>
> > =A0 =A0I still cannot understand the difference between both since I'm =
a
> >beginner yet.
>
> > =A0 =A0In my case, I have a ldscript which will be linked by the linker=
to
> >form an image.
>
> > =A0 =A0But when I look into the ldscipt, something puzzles me a lot. It
> sets
> >the memory as below:
>
> > =A0 =A0 MEMORY{
> > =A0 =A0 =A0 =A0 flash (rx) : ORIGIN =3D 0x80000000, =A0 LENGTH =3D 0x00=
200000
> > =A0 =A0 =A0 =A0 ram =A0(!rx) : ORIGIN =3D 0x82000000, =A0 LENGTH =3D 0x=
00200000
> > =A0 =A0 =A0 =A0 loadregion : ORIGIN =3D 0xA2000000, =A0 LENGTH =3D 0x00=
200000
> > =A0 =A0 }
>
> > =A0 =A0 And the SECTION part
> > =A0 =A0 SECTIONS{
> > =A0 =A0 .text : { _stext =3D .; _ftext =3D . ; *(.text) *(.text.*) ...;=
}
> >flash
> >AT>loadregion =3D0 _etext =3D .; PROVIDE (etext =3D .);
> > =A0 =A0 ...
> > =A0 =A0 .data : =A0{ . =3D ALIGN(0x40); =A0_fdata =3D . ; *(.data) *(.d=
ata.*) . =3D
> >ALIGN (8); } >ram AT>loadregion
> > =A0 =A0 ...
> > =A0 =A0 }
>
> > =A0 =A0What confused me most is the fact that the real flash address is
> start
> >from 0xA0000000 and the real memory address is start from 0xA2000000.
>
> > =A0 =A0According to you, the LMA now becomes RAM address, but the VMA
> becomes
> >Flash address?
> > =A0 =A0Since the codes will run in Flash, how and what the LMA function=
s?
>
> > =A0 =A0But if I change the LMA, say modifying the loadregion part to a
> >different address like 0xc8000000, the image will not even run. Why?
>
> > =A0 =A0I have read the ld document for details but get nothing helpful.
> > =A0 =A0Does anyone give me some comments?
>
> >Thanks!
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
Mike
>
> hi, in my application , my data is too big and when =A0load into target i
> got not enough memory message , so i decided to put my data into ROM usin=
g
> VMA and then load it when i need using LMA. simple.
>
> but i dont =A0know how to =A0tell compiler about VMA and LMA.
> any link or example is very helpful.
>
> Thanks

I don't understand. How will using VMA/LMA make your application
fit? Are you planning to break it into smaller pieces?

Rick

2009年5月19日 星期二

socket struct header

#include  or 

struct ifreq
{
#define IFHWADDRLEN 6
union
{
char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */
} ifr_ifrn;

union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
void __user * ifru_data;
struct if_settings ifru_settings;
} ifr_ifru;
};

#define ifr_name ifr_ifrn.ifrn_name /* interface name */
#define ifr_hwaddr ifr_ifru.ifru_hwaddr /* MAC address */
#define ifr_addr ifr_ifru.ifru_addr /* address */
#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-p lnk */
#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
#define ifr_netmask ifr_ifru.ifru_netmask /* interface net mask */
#define ifr_flags ifr_ifru.ifru_flags /* flags */
#define ifr_metric ifr_ifru.ifru_ivalue /* metric */
#define ifr_mtu ifr_ifru.ifru_mtu /* mtu */
#define ifr_map ifr_ifru.ifru_map /* device map */
#define ifr_slave ifr_ifru.ifru_slave /* slave device */
#define ifr_data ifr_ifru.ifru_data /* for use by interface */
#define ifr_ifindex ifr_ifru.ifru_ivalue /* interface index */
#define ifr_bandwidth ifr_ifru.ifru_ivalue /* link bandwidth */
#define ifr_qlen ifr_ifru.ifru_ivalue /* Queue length */
#define ifr_newname ifr_ifru.ifru_newname /* New name */
#define ifr_settings ifr_ifru.ifru_settings /* Device/proto settings*/


----------------------------------------------------------------------------

linux/socket.h
struct
sockaddr {
sa_family_t sa_family; /* address family, AF_xxx */
char sa_data[14]; /* 14 bytes of protocol address */
};


An IPv4 socket address strcuture

#include inux/in.h

struct in_addr{

in_addr_t s_addr;

};

#include inux/in.h

struct sockaddr_in{

uint8_t sin_len;

sa_family_t sin_family;

in_port_t sin_port;

struct in_addr sin_addr;

char sin_zero[8];

};

An IPv6 socket address structure

struct in6_addr{

uint8_t s6_addr[16];

};

#define SIN6_LEN

struct sockaddr_in6{

uint8_t sin6_len;

sa_family_t sin6_family;

in_port_t sin6_port;

uint32_t sin6_flowinfo;

struct in6_addr sin6_addr;

uint32_t sin6_scope_id;

};

2009年5月18日 星期一

mips make modules in 2.4 unresoved symbol _gp_disp

KERNELDIR=/share/released/src/linux/linux CROSS_COMPILE=mipsel-linux- make

mipsel-linux-gcc -D__KERNEL__ -I/share/released/DIR-330_A1/DIR-330/src/linux/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/share/released/DIR-330_A1/DIR-330/src/linux/linux/../../include -DBCMDRIVER -I /share/released/DIR-330_A1/DIR-330/src/linux/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -DMODULE -mlong-calls -fno-common -I.. -O -I/share/released/DIR-330_A1/DIR-330/src/include -c -o skull_init.o skull_init.c

in ../Rule.make
CFLAGS += -D__KERNEL__ -I/share/released/DIR-330_A1/DIR-330/src/linux/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/share/released/DIR-330_A1/DIR-330/src/linux/linux/../../include -DBCMDRIVER -I /share/released/DIR-330_A1/DIR-330/src/linux/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -DMODULE -mlong-calls -fno-common

2009年2月10日 星期二

screen how-to

screen
C^a : scrollback mode