uClinux development discussion

Re: mcf5307, i2c rtc

Hi all,

i found an error in my resources struct, and i finally have the driver set loaded,

Still seems i cannot get valid bytes from RTC ds1338. I probably have some HW issue.

i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=7
rtc-ds1307 0-0068: read: 00 00 00 00 00 00 00
rtc-ds1307 0-0068: read secs=0, mins=0, hours=0, mday=0, mon=-1, year=100, wday=-1
rtc-ds1307 0-0068: hctosys: unable to read the hardware clock

many thanks to Steven for the driver, and many thanks to all for the help until now,

regards,
angelo

On 25/08/2011 18:37, Viet Nguyen wrote:
> On Wed, Aug 24, 2011 at 11:24 PM, angelo <angelo70 <at> gmail.com
> <mailto:angelo70 <at> gmail.com>> wrote:
> 
> 
>     1- The device rtc0 must be created from genromfs ? I see some boards
>     that have CONFIG_RTC_HCTOSYS_DEVICE="rtc0" but create a "rtc"
>     instade, with any number.
> 
>     2 - Do i hae to add some static structure in my board.c to enable
>     rtc ds1307 driver ? Do you have a sample ?
> 
>

(Continue reading)

headers

Brent Weatherall | 1 Sep 01:55

Cross compiling uClinux 2.4.x for arm-nommu arch

Hello. I am trying to cross-compile uClinux kernel 2.4.x for the Atmel AT91 board. I AM able to compile uClinux 2.6.x successfully for the Atmel board; however, I need 2.4.x to compile.

Compiling 2.6.x I simply set CROSS_COMPILE in the menuconfig and went about my way.

It appears less straightforward in the 2.4.x build. To override the hard-coded "CROSS_COMPILE" and "KERNEL_CROSS_COMPILE" I modified uClinux-dist/vendors/config/armnommu.arch so I could override the cross compilation variables.

Then I ran:

CROSS_COMPILE=/usr/local/arm-uclinux-gcc-3.4.3/bin/arm-uclinux-elf- KERNEL_CROSS_COMPILE=/usr/local/arm-uclinux-gcc-3.4.3/bin/arm-uclinux-elf- make linux

Where:

ls /usr/local/arm-uclinux-gcc-3.4.3/bin/

arm-elf-addr2line arm-elf-flthdr arm-elf-objcopy arm-uclinux-elf-addr2line arm-uclinux-elf-flthdr arm-uclinux-elf-ld arm-uclinux-elf-run

arm-elf-ar arm-elf-g++ arm-elf-objdump arm-uclinux-elf-ar arm-uclinux-elf-g++ arm-uclinux-elf-ld.real arm-uclinux-elf-size

arm-elf-as arm-elf-gcc arm-elf-ranlib arm-uclinux-elf-as arm-uclinux-elf-gcc arm-uclinux-elf-nm arm-uclinux-elf-strings

arm-elf-c++ arm-elf-gcov arm-elf-readelf arm-uclinux-elf-c++ arm-uclinux-elf-gcc-3.4.3 arm-uclinux-elf-objcopy arm-uclinux-elf-strip

arm-elf-c++filt arm-elf-ld arm-elf-size arm-uclinux-elf-c++filt arm-uclinux-elf-gccbug arm-uclinux-elf-objdump genromfs

arm-elf-cpp arm-elf-ld.real arm-elf-strings arm-uclinux-elf-cpp arm-uclinux-elf-gcov arm-uclinux-elf-ranlib

arm-elf-elf2flt arm-elf-nm arm-elf-strip arm-uclinux-elf-elf2flt arm-uclinux-elf-gdb arm-uclinux-elf-readelf

Am I using the wrong toolchain version? So far I haven't found anything for sure specifying a specific version of the gnu arm-uclinux compiler toolset for uClinux kernel 2.4.x. I may just be missing it.

The error I see appears to start with the compilation of assembly units:

/usr/local/arm-uclinux-gcc-3.4.3//bin/arm-uclinux-elf-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/Virtual_Machines/linux_kernels/uClinux-dist/linux-2.4.x/include -DNO_MM -mapcs-32 -march=armv4 -msoft-float -c -o entry-armv.o entry-armv.S

entry-armv.S: Assembler messages:

entry-armv.S:1495: Warning: destination register same as write-back base

entry-armv.S:1721: Error: undefined symbol TSS_FPESAVE used as an immediate value

The above text is the first error. There are many more assembly errors. Any help would be appreciated.

_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Greg Ungerer | 1 Sep 03:00

Re: Cross compiling uClinux 2.4.x for arm-nommu arch

Hi Brent,

On 01/09/11 09:55, Brent Weatherall wrote:
> Hello.  I am trying to cross-compile uClinux kernel 2.4.x for the Atmel AT91 board.  I AM able to compile
uClinux 2.6.x successfully for the Atmel board; however, I need 2.4.x to compile.

What code base are you working from?
Which version of uClinux-dist?

Regards
Greg

> Compiling 2.6.x I simply set CROSS_COMPILE in the menuconfig and went about my way.
>
> It appears less straightforward in the 2.4.x build.  To override the hard-coded "CROSS_COMPILE" and
"KERNEL_CROSS_COMPILE" I modified uClinux-dist/vendors/config/armnommu.arch so I could override
the cross compilation variables.
>
> Then I ran:
>
> CROSS_COMPILE=/usr/local/arm-uclinux-gcc-3.4.3/bin/arm-uclinux-elf-
KERNEL_CROSS_COMPILE=/usr/local/arm-uclinux-gcc-3.4.3/bin/arm-uclinux-elf- make linux
>
> Where:
>
> ls /usr/local/arm-uclinux-gcc-3.4.3/bin/
> arm-elf-addr2line  arm-elf-flthdr   arm-elf-objcopy  arm-uclinux-elf-addr2line 
arm-uclinux-elf-flthdr     arm-uclinux-elf-ld       arm-uclinux-elf-run
> arm-elf-ar         arm-elf-g++      arm-elf-objdump  arm-uclinux-elf-ar         arm-uclinux-elf-g++       
arm-uclinux-elf-ld.real  arm-uclinux-elf-size
> arm-elf-as         arm-elf-gcc      arm-elf-ranlib   arm-uclinux-elf-as         arm-uclinux-elf-gcc       
arm-uclinux-elf-nm       arm-uclinux-elf-strings
> arm-elf-c++        arm-elf-gcov     arm-elf-readelf  arm-uclinux-elf-c++        arm-uclinux-elf-gcc-3.4.3 
arm-uclinux-elf-objcopy  arm-uclinux-elf-strip
> arm-elf-c++filt    arm-elf-ld       arm-elf-size     arm-uclinux-elf-c++filt    arm-uclinux-elf-gccbug    
arm-uclinux-elf-objdump  genromfs
> arm-elf-cpp        arm-elf-ld.real  arm-elf-strings  arm-uclinux-elf-cpp        arm-uclinux-elf-gcov       arm-uclinux-elf-ranlib
> arm-elf-elf2flt    arm-elf-nm       arm-elf-strip    arm-uclinux-elf-elf2flt    arm-uclinux-elf-gdb        arm-uclinux-elf-readelf
>
> Am I using the wrong toolchain version?  So far I haven't found anything for sure specifying a specific
version of the gnu arm-uclinux compiler toolset for uClinux kernel 2.4.x.  I may just be missing it.
>
> The error I see appears to start with the compilation of assembly units:
>
> /usr/local/arm-uclinux-gcc-3.4.3//bin/arm-uclinux-elf-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/home/Virtual_Machines/linux_kernels/uClinux-dist/linux-2.4.x/include  -DNO_MM -mapcs-32
-march=armv4 -msoft-float   -c -o entry-armv.o entry-armv.S
> entry-armv.S: Assembler messages:
> entry-armv.S:1495: Warning: destination register same as write-back base
> entry-armv.S:1721: Error: undefined symbol TSS_FPESAVE used as an immediate value
>
> The above text is the first error.  There are many more assembly errors.  Any help would be appreciated.
>
>

--

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg <at> snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Siegfried Müller - MB Connect Line GmbH | 1 Sep 12:56

dont get jffs2 formated on snapgear4.0.7 - fixed

I found some differences between the 2.6.26-uc0 from snapgear to 2.6.26-ti in /drivers/mtd/chips.
I patched the 2.6.26-uc0 with 2.6.26-ti and everything is ok now. There are few changes for timing and
waiting sequences when writing to flash. And I think that this was the point, because the flash was in
status mode.
Thanks for help.
cheers
Siegfried

On 03/08/11 00:16, Siegfried Müller - MB Connect Line GmbH wrote:
> Hi everyone,
>
> any ideas?

I haven't got any other ideas here.

I can only suggest that you will need to dig into the jffs2 code and look closely at what is going on in that
mount step.

Regards
Greg

>> Hi Greg,
>
>> Hi Siegfried,
>>
>> On 07/09/2011 01:58 AM, Siegfried MÂ³ller - MB Connect Line GmbH wrote:
>>> Hi Greg,
>>> 	
>>>> Hi Siegfried,
>>>
>>>> On 05/07/11 15:28, Siegfried Mâ"¬â"'ller - MB Connect Line GmbH wrote:
>>>>> Hi Greg,
>>>>>
>>>>>> Hi Siegfried,
>>>>>
>>>>>> On 24/06/11 21:36, Siegfried MÃ""Â¼Ã""'ller - MB Connect Line GmbH wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>> I'm trying to get jffs2 running on snapgear4.0.7. I have an IXP430 with Intel Strataflash. The
configuration is very similar to the montajade board and IXPDG425, but with IXP430. I fixed now to run the
snapgear4.0.7 with this hardware, but the only thing is the jffs filesystem. I have:
>>>>>>>
>>>>>>> # cat /proc/mtd
>>>>>>> dev:    size   erasesize  name
>>>>>>> mtd0: 00080000 00020000 "RedBoot"
>>>>>>> mtd1: 00c80000 00020000 "Image"
>>>>>>> mtd2: 00300000 00020000 "zImage"
>>>>>>> mtd3: 00980000 00020000 "ramdisk"
>>>>>>> mtd4: 002c0000 00020000 "s600"
>>>>>>> mtd5: 00001000 00020000 "RedBoot config"
>>>>>>> mtd6: 00020000 00020000 "FIS directory"
>>>>>>>
>>>>>>> "s600" is my config fs, which I want to mount on /etc/config with jffs2..
>>>>>>>
>>>>>>> I do:
>>>>>>>
>>>>>>> # eraseall /dev/flash/config
>>>>>>> Erased 2816 Kibyte @ 0 -- 100% complete.
>>>>>>>
>>>>>>> # mount -t jffs2 /dev/flash/configblock /etc/config
>>>>>>>
>>>>>>> I get this messages...
>>>>>>> --snipp
>>>>>>> Further such events for this erase block will not be printed
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0000:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0004:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0008:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c000c:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0010:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0014:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0018:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c001c:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0020:
>>>>>>> 0x0080 id
>>>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0024:
>>>>>>> 0x0080 id --snipp
>>>>>>>
>>>>>>> I already goggled a lot of this issue, but don't solved it.
>>>>>>> What I can say, it that I also have a image with snapgear3.4 and this IXP430 and there I get everything
running. But I cant>this version, because there are also a few other things in SG3.4 what are not ready for
this IXP430..
>>>>>>> But in anycase, if I first start the image with SG3.4 on this hardware, I'm able to mount the
/etc/config and read/write. When I then start the image with SG4.0.7 I can also read/write. So I guess it
couldn't be the hardware, it must be something in the changes of jffs2 from SG3.4 to SG4.0.7..
>>>>>>>
>>>>>>> Does anyone has an idea?
>>>>>>
>>>>>> That is going from a 2.6.17 kernel to a 2.6.26. And a diff of the
>>>>>> fs/jffs2 in each is kinda large.
>>>>>>
>>>>>> What type of flash is this board using?  From the erase sizes I am guessing some type of intel strata
flash?  Is it a J3 or P30 type?
>>>>>
>>>>> I use the Intel Strata Flash JS28F128 J3F75.
>>>>
>>>> Ok, you don't have to deal with the power up locked segments then.
>>>>
>>>> The "0x0080" read value sure looks like the read status result of the flash, and not the contents of that
addressed location.
>>>>
>>>> If you dump the contents of the flash what does it look like after the erase. Something like with:
>>>>
>>>>     hexdump /dev/flash/config
>>>>
>>> Here is the result after "eraseall"
>>>
>>> # hexdump /dev/flash/config
>>> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
>>> *
>>> 02c0000
>>> #
>>
>> That certainly looks good. It sure does look like the flash is properly erased.
>>
>>
>>> Could that be a timing problem on expansion bus? Well I use the same adjustments as in 2.6.17.
>>
>> Perhaps. But it sure looks like the underlying MTD driver has the flash in the wring mode when trying to
read the data values (it looks to be in status mode).
>
> But if it is a general problem of the underlying MTD driver I don't understand, why it is ok when the flash is
formatted with my image from 2.6.17 and the I start the 2.6.26 and everything could be read and from/to
flash. The only thing I cannot do is formatting. Do you have an idea how to more detail the problem?
>
> kind regards
> Siegfried
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev <at> uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev <at> uclinux.org To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev <at> uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev <at> uclinux.org To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
>
>

--

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg <at> snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Brent Weatherall | 2 Sep 20:17

At91 and skyeye config files

Hello again. I have just built the uClinux 2.4.x kernel for the Atmel AT91 (using Snapgear toolchain arm-linux-tools-20061213). I want to run this kernel with skyeye. I can successfully run the skye-testsuite AT91 (uclinux_cs8900a) with wonderful results. Warm fuzzy feeling and all that. The reason I am trying to rebuild the kernel is that the current testsuite example (uclinux_cs8900a) only has about 1.5MB RAM and my tests need around 13 MB RAM. When I switch to the kernel I just built, the memory address alignment no longer matches the config file values. I tried matching some values from skyeye.conf (below) to values in the 'make menuconfig' options for DRAM offset and size etc..., but I am not easily seeing the mapping between these values and what is present in the config file:

mem_bank: map=M, type=RW, addr=0x00000000, size=0x00004000

mem_bank: map=M, type=RW, addr=0x01000000, size=0x00400000

mem_bank: map=M, type=R, addr=0x01400000, size=0x00400000, file=./romfs.img

mem_bank: map=M, type=RW, addr=0x02000000, size=0x00400000

mem_bank: map=M, type=RW, addr=0x02400000, size=0x00008000

mem_bank: map=M, type=RW, addr=0x04000000, size=0x00400000

mem_bank: map=I, type=RW, addr=0xf0000000, size=0x10000000

I am currently looking through the skyeye source (skyeye-1.3.2_rc1) for how the config file is parsed and what the mappings are, but this is looking to be an arduous task atm. If anyone has any good high level pointers on how to map kernel settings to match up with config file values or more directly how to increase the RAM avail to the skyeye VM it would greatly help out. I am a bit new to skyeye so there may something glaringly obvious I am as yet not aware of. Thanks in advance if anyone can provide some tips or documentation which clears this up.

Looking around the web it appears there are multiple suggestions on toolchain and uclinux-dist versions from various sites, blogs and forums. I will probably try these out as well.

Regards,

Brent Weatherall

_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Angelo Dureghello | 4 Sep 21:53

Coldfire GPIO question

Dear all,

i am running uClinux but with a main line kernel 2.6.36.2 and trying to get 13 GPIO lines of my MCF5307, to do
some tests driving an LCD display, as below:

static struct gpio ks0108_gpios[] = {
{  0, GPIOF_OUT_INIT_LOW, "D0" },
{  1, GPIOF_OUT_INIT_LOW, "D1" },
{  2, GPIOF_OUT_INIT_LOW, "D2" },
{  3, GPIOF_OUT_INIT_LOW, "D3" },
{  4, GPIOF_OUT_INIT_LOW, "D4" },
{  5, GPIOF_OUT_INIT_LOW, "D5" },Linux version 
{  6, GPIOF_OUT_INIT_LOW, "D6" },
{  7, GPIOF_OUT_INIT_LOW, "D7" },
{ 10, GPIOF_OUT_INIT_LOW, "CS1" },
{ 11, GPIOF_OUT_INIT_LOW, "CS2" },
{ 12, GPIOF_OUT_INIT_LOW, "R_W" },
{ 13, GPIOF_OUT_INIT_LOW, "D_I" },
{ 14, GPIOF_OUT_INIT_LOW, "E" },
};

gpio_request_array(ks0108_gpios, 13);

The gpio_request_array() return without any error, but seems i can set correctly levels only lines PP0 to
PP3, not 4to7, 10,11,12,13,14.

Am i doing something wrong ?

Thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Steven King | 4 Sep 22:21

Re: Coldfire GPIO question

On Sunday 04 September 2011 12:53:01 Angelo Dureghello wrote:
> Dear all,
>
> i am running uClinux but with a main line kernel 2.6.36.2 and trying to get
> 13 GPIO lines of my MCF5307, to do some tests driving an LCD display, as
> below:
>
> static struct gpio ks0108_gpios[] = {
> {  0, GPIOF_OUT_INIT_LOW, "D0" },
> {  1, GPIOF_OUT_INIT_LOW, "D1" },
> {  2, GPIOF_OUT_INIT_LOW, "D2" },
> {  3, GPIOF_OUT_INIT_LOW, "D3" },
> {  4, GPIOF_OUT_INIT_LOW, "D4" },
> {  5, GPIOF_OUT_INIT_LOW, "D5" },Linux version
> {  6, GPIOF_OUT_INIT_LOW, "D6" },
> {  7, GPIOF_OUT_INIT_LOW, "D7" },
> { 10, GPIOF_OUT_INIT_LOW, "CS1" },
> { 11, GPIOF_OUT_INIT_LOW, "CS2" },
> { 12, GPIOF_OUT_INIT_LOW, "R_W" },
> { 13, GPIOF_OUT_INIT_LOW, "D_I" },
> { 14, GPIOF_OUT_INIT_LOW, "E" },
> };
>
> gpio_request_array(ks0108_gpios, 13);
>
> The gpio_request_array() return without any error, but seems i can set
> correctly levels only lines PP0 to PP3, not 4to7, 10,11,12,13,14.
>
> Am i doing something wrong ?

Did you configure the pin assignment register?  If D4/addr_config is asserted 
when reset is negated, those signals will default to their primary (non GPIO) 
functions.
_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

dhlm83 | 5 Sep 17:01

telnetd: All network ports in use

Hello.

I am using kernel 2.4.34.5-uco, uclinux distro 20110603.

I build successful an Image to NetBurner MOD5272.

But i cont run the telnetd.

I have it in inetd.conf:
         telnet  stream tcp nowait root /bin/telnetd
in start-up telnetd don't start...

If I try start manually i have the following error message:
...
# telnetd
telnetd: getpeername: Socket operation on non-socket
telnetd: All network ports in use.
...

Someone had this problem or similar?

Thanks.
Domingos Goncalves
_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

dhlm83 | 6 Sep 10:53

Re: telnetd: All network ports in use


Hello

I find the solution..
In this case, it is just a Configuration problem:

I select the option: CONFIG_USER_TELNETD_DOES_NOT_USE_OPENPTY = y
In Kernel configuration...

In Startup the telnetd dont start, it only start if an telnet  
connection is requested

Thanks

> Hello.
>
> I am using kernel 2.4.34.5-uco, uclinux distro 20110603.
>
> I build successful an Image to NetBurner MOD5272.
>
> But i cont run the telnetd.
>
> I have it in inetd.conf:
>         telnet  stream tcp nowait root /bin/telnetd
> in start-up telnetd don't start...
>
> If I try start manually i have the following error message:
> ...
> # telnetd
> telnetd: getpeername: Socket operation on non-socket
> telnetd: All network ports in use.
> ...
>
> Someone had this problem or similar?
>
> Thanks.
> Domingos Goncalves
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev <at> uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev <at> uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>

_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

headers

Quiliro Ordóñez | 6 Sep 21:12

Kyocera 7135 and 100% libre software

Hi.

I found this distro and would like to thank the developers.

I would like to use it to install only the free (as in freedom) parts to 
a Kyocera 7135 smart phone. It has a Motorola 68VZ328 processor that 
works without MMU. I understand that uCLinux works with this hardware.

Will you please give me guidance about how to connect to this device? I 
suspect I should connect with minicom through the USB or serial 
interface supplied by the phone. Is this correct? Is there a howto about 
that?

If you can give me some pointers about the nonfree parts that you know 
exist in uCLinux it would help me free the OS also.

Thank you very much for your help and keep trucking! 
-- 
Quiliro Ordóñez
09 821 8696
02 340 1517

"No se puede sacrificar la libertad por ningún bien, por ninguna promesa 
de pan o de paz o de justicia, porque ese pan tendría amargura de 
veneno, esa paz sería de muerte, y esa justicia no sería justicia humana 
ni tendría sentido." Alfredo Pérez Guerrero

"Não se pode sacrificar a liberdade por nenhum bem, por nenhuma promessa 
de pan ou de paz ou de justiça, porque esse pan teria amargura de 
veneno, essa paz seria de morte, e essa justiça não seria justiça humana 
nem faria sentido." Alfredo Pérez Guerrero
_______________________________________________
uClinux-dev mailing list
uClinux-dev <at> uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev <at> uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

68	May 2012
28	April 2012
15	September 2011
78	August 2011
18	July 2011
22	June 2011
23	May 2011
33	April 2011
45	March 2011
51	February 2011
30	January 2011
33	December 2010
62	November 2010
67	October 2010
49	September 2010
56	August 2010
34	July 2010
106	June 2010
100	May 2010
149	April 2010
135	March 2010
76	February 2010
129	January 2010
142	December 2009
124	November 2009
87	October 2009
95	September 2009
215	August 2009
129	July 2009
117	June 2009
187	May 2009
86	April 2009
508	March 2009
244	February 2009
235	January 2009
130	December 2008
180	November 2008
192	October 2008
192	September 2008
85	August 2008
130	July 2008
176	June 2008
213	May 2008
501	April 2008
245	March 2008
416	February 2008
205	January 2008
287	December 2007
286	November 2007
281	October 2007
254	September 2007
278	August 2007
274	July 2007
257	June 2007
348	May 2007
287	April 2007
287	March 2007
354	February 2007
373	January 2007
301	December 2006
387	November 2006
298	October 2006
414	September 2006
407	August 2006
431	July 2006
515	June 2006
532	May 2006
370	April 2006
589	March 2006
553	February 2006
473	January 2006
399	December 2005
537	November 2005
376	October 2005
320	September 2005
18	August 2005
1	July 2005
15	June 2005
49	May 2005
5	April 2005
6	March 2005
7	February 2005
4	January 2005
23	December 2004
132	November 2004
14	October 2004
12	September 2004
4	August 2004
3	July 2004
10	June 2004
4	May 2004
1	April 2004
18	March 2004
15	February 2004
5	January 2004
17	December 2003
9	November 2003
11	October 2003
17	September 2003
49	August 2003
66	July 2003
22	June 2003
3	May 2003
5	April 2003
11	March 2003
9	February 2003
8	January 2003
5	December 2002
2	November 2002
313	October 2002
765	September 2002
656	August 2002
588	July 2002
1	January 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30