Re: [uClinux-dev] (no subject)

[Steve deRosier]

Hi Joshua,

On Thu, Jun 30, 2016 at 4:52 AM, Joshua Stokes  wrote:
>
> I am basically trying to compile a uclinux distribution that is installed on 
> STBs, specifically the Fetch TV uclinux. The firmware version is 2.01278 and 
> the required files are located at http://www.fetchtv.com.au/opensource
>
> Can someone please shed some light on this situation
>

Yes, I'll try.  You'll have to go ask Fetch TV for instructions.  It's
unlikely that anyone here would even know what processor that device
runs.

You see, a cross-compiler is to build code for a different instruction
set architecture than what you're running it on.  Most likely,  you're
doing the compilation on an x86-64 machine. And the Fetch TV hardware
could be anything - m68k, ARM, MIPS to name but a few.  Google is a
good start for basic research. So is this:
https://en.wikipedia.org/wiki/Cross_compiler

Just because a company uses an open source software package doesn't
mean that the community is responsible for supporting that product. In
most cases we don't even know the software was used, how or whatever.

It's clear from the manufacturer's web-page that they're making a
minimal attempt at complying with the letter of the licenses, but they
don't actually have any interest in people working with the software.
More than likely, once you have the software working, you're going to
be stymied by the lack of a host of closed-source software you don't
have access to.

If you have an actual question about uclinux, people here are happy to
help you. If you have questions about Fetch TV or their use of
uclinux, no one here can help you and likely won't want to anyway.  If
you have questions about general embedded development or other general
subjects, if you get an answer, it's going to be RTFM.  So far what
you've asked is a cross between general knowledge and FetchTV specific
info. No one here can help with that much.

In short - before embarking on whatever it is you're doing, you might
want to do a little research.

Good luck,

- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] g++, strange behavior issues

[Steve deRosier]

Also there's macros in Linux that return/test for errors via setting
pointers to values  4096.  Because these addresses are NEVER valid.
;) Not sure how uCLinux deals with this, other than people avoiding
putting valid memory address near 0.

Just another challenge with micros.

On Thu, Feb 13, 2014 at 12:37 AM, Angelo Dureghello angel...@gmail.com wrote:
 That was exactly my case, a null pointer, and ram starts from 0x0 in the map
 :).
 I will keep in mind this thing for the future.

 Still thanks.

 Regards
 Angelo


 On 13/02/2014 03:29, Gavin Lambert wrote:

 Quoth Larry Baker:

 Yes, this is indeed what can happen on a system like uClinux that does
 not have an MMU (memory management unit).  The tiny controller chips
 that uClinux targets do not protect any part of the memory from being
 accidentally corrupted.  As long as the memory being accessed exists,
 there is no hardware fence between a user program and the rest of memory.

 It's especially fun when address 0 is valid memory (which is not
 uncommon).
 Then you don't get crashes from null pointer accesses, which most
 developers
 expect (and some can be lazy about protecting against, thinking that
 they'll
 find it during debugging).

 I always try to configure the target device's memory map such that
 addresses
 near 0 remain invalid, whenever possible -- but some targets don't support
 that.



 ___
 uClinux-dev mailing list
 uClinux-dev@uclinux.org
 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
 This message was resent by uclinux-dev@uclinux.org
 To unsubscribe see:
 http://mailman.uclinux.org/mailman/options/uclinux-dev
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Steve deRosier]

I think it was already suggested: you need to enable flow-control.  Either
hardware if you've got the pins setup right on that port or software
(xon/xoff) if you don't.


On Tue, Nov 12, 2013 at 4:11 AM, Raju B raju3...@gmail.com wrote:

 Hi Michael,

 I have tried with baudrate = 9600 and 19200, then it is working fine(i.e
 getting data, no overruns). but i want to use high speed(115200). can u
 please give any suggestion to over come this.

 Thanks r Regards,
 Raju


 On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant mdurr...@uclinux.orgwrote:

  Raju,

 I would expect data overruns causing lost characters if your CPU
 utilization is high and your kernel
 driver can't get back to servicing the UART IRQ fast enough.  Your
 MCF523x part appears to have
 only a small FIFO buffer (a shift register and 3 receiver registers).
 So if the data rate is faster than
 the kernel can remove the data hardware FIFO it is likely you will miss
 data due to overruns.   So
 in your case the 10th character was lost (overwritten) by the next
 character.  Sounds like you need
 DMA support for the UART you are using or perhaps slow down the incoming
 data or perhaps
 turn hardware flow control on.

 Michael

 On 11/06/2013 04:40 AM, Raju B wrote:

   Hi Michael,

  The ColdFire is 523x and using UART serial interface.

  Thanks  regards,
  Raju B


  On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant 
 mdurr...@uclinux.orgwrote:


 Raj,

 Which ColdFire are you using?
 Which serial interface are you seeing this with (UART/SPI/I2C/..)?

 Michael


 On 11/05/2013 07:40 AM, Raju B wrote:

   whenever i am trying to receive data from serial communication
 continuously in uClinux, I am getting every 10th byte is overwrite by 11
 byte and so on

   Iam using freescale coldfire processor. Could you any body  please
 help me to resolve this issue.

  Thanks  Regards,
  Raj


 On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen 
 lsore...@csclub.uwaterloo.ca wrote:

 On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
  I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
 BSP) and am working to make it run on the 2.6.38 kernel released in the
 ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
 first attempt to run on the 38 kernel appears to be using 2^n memory
 allocation vs. allocation that sizes just 1-page over the application.
 
  1) Can anyone tell me the exact kernel config name that needs to be
 adjusted for the 38 kernel to set the default memory allocation?
- Older posts indicate modules like page_alloc2 or Kmalloc2
 control this so I'm going to investigate these in more detail
- RTFMing indicate that this might be the area but I don't see
 it in the 38 version (LTIB or make menucionfig):
menuconfig - kernel settings - general settings, try
 enabling either the Permit large allocations setting, or the
 non-power-of-2
 
  2) Historically, we use LTIB to create the kernel.  Does LTIB expose
 most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
 make menuconfig uClinus kernel?

  Maybe this changed the behaviour you see:

 commit fc4d5c292b68ef02514d2072dcbf82d090c34875
 Author: David Howells dhowe...@redhat.com
 Date:   Wed May 6 16:03:05 2009 -0700

 nommu: make the initial mmap allocation excess behaviour Kconfig
 configurable

 NOMMU mmap() has an option controlled by a sysctl variable that
 determines
 whether the allocations made by do_mmap_private() should have the
 excess
 space trimmed off and returned to the allocator.  Make the initial
 setting
 of this variable a Kconfig configuration option.

 The reason there can be excess space is that the allocator only
 allocates
 in power-of-2 size chunks, but mmap()'s can be made in sizes that
 aren't a
 power of 2.

 There are two alternatives:

  (1) Keep the excess as dead space.  The dead space then remains
 unused for the
  lifetime of the mapping.  Mappings of shared objects such as
 libc, ld.so
  or busybox's text segment may retain their dead space forever.

  (2) Return the excess to the allocator.  This means that the dead
 space is
  limited to less than a page per mapping, but it means that for
 a transient
  process, there's more chance of fragmentation as the excess
 space may be
  reused fairly quickly.

 During the boot process, a lot of transient processes are created,
 and
 this can cause a lot of fragmentation as the pagecache and various
 slabs
 grow greatly during this time.

 By turning off the trimming of excess space during boot and
 disabling
 batching of frees, Coldfire can manage to boot.

 A better way of doing things might be to have /sbin/init turn this
 option
 off.  By that point libc, ld.so and init - which are all
 long-duration
 processes - have all been loaded and trimmed.

 Reported-by: Lanttor Guo 

Re: [uClinux-dev] fix malloc whole page for small allocations?

[Steve deRosier]

On Fri, Apr 12, 2013 at 9:27 AM, Anthony Best
anthonyb...@bestanthony.com wrote:
 On Apr 12, 2013, at 9:00 AM, Lennart Sorensen lsore...@csclub.uwaterloo.ca 
 wrote:

 On Fri, Apr 12, 2013 at 07:34:19AM -0700, Steve deRosier wrote:
 Hi all,

 Every time our application mallocs any small number of bytes (8k),
 the device seems to malloc an entire page (8k). Does anyone know  why
 this happens, and how I can fix it?

 Imagine the amount of fragmentation you would get if different
 applications could all be given allocations from one page.  That would
 be a mess.  Now the libc could be smart and maintain a heap for you that
 it does small allocations from and doesn't give back when you do a free.
 I think glibc does that, but I have never checked how uClibc does it,
 given I have never done such allocationsin uClinux code.

 Certainly looking at the code, there is malloc_from_heap used by malloc,
 so it sure looks like uClibc does the sensible thing.  In that case small
 allocations shouldn't be a problem, unless you allocate a bunch, keep
 a few and free the rest, repeat a lot, causing enourmous fragmentation
 of the heap.  If that is the case, perhaps your algorithm needs a major
 rethink.

 Full details:

 This same application ran fine on a Linux 2.4.x (uClinux) platform,
 but due to various reasons we've had to upgrade the platform to 3.3.0
 (still uClinux). Coldfire mcf5235, 4 MB flash, 32 MB RAM. We're using
 uClibc.

 At the time we start the application, there is ~20 MB free, it runs
 for 30+ seconds and then the OOM killer kills it. On the 2.4.x
 platform, it has a high-water-mark of about 2 MB, and runs in the
 steady-state at about 1.5 MB.

 After much investigation (eventually culminating in a debug version of
 malloc printing each allocation request, then sleeping for 2 seconds,
 where I cat /proc/meminfo), we finally noticed that each allocation,
 typically 10-40 bytes, reduces meminfos's MemFree by 8k.

 Other than the underlying kernel and wholesale upgrade of the uClinux
 base, nothing has really changed on the system. We're still selecting
 the same packages and configuration as near as possible.

 So it used to work and now it doesn't?

 Might be worth listing the version of uClibc and other bits you are using,
 in addition to the kernel version.

 The version of uClinux we are currently running is from the tar ball 
 uClinux-dist-20070130.tar.gz

 Linux version 2.4.32-uc0
 Using power of 2 allocator

 Previously we were using a 2003 distribution of uClinux on the M5282 with the 
 same code.


Hi guys.  Looks like we figured out what was going on.

uClibc has two different malloc implementations for our platform. The
simple malloc, the default, which we were using, simply goes out and
grabs a chunk of ram via a mmap operation when you malloc anything.
The standard malloc, manages the heap and only mmaps new ram when it
runs out.

Seems the old 2.4.3x version of Linux we were using managed mmap
allocations via power-of-two buckets, giving the smallest bucket for
each request. I don't know if that was standard back then for our
platform or if that was something that they added for the product.
The upgraded Linux 3.3 allocator simply gives an 8k page on each mmap
request.

So, combining the change to the 8k page allocation with using the
simple malloc from uClibc and no matter the size of ram we requested,
we would allocate the full 8k page for it.  So a 16-byte request
resulted in an 8192 byte allocation.  Hence, OOM in about 3 seconds.

The fix was to change uClibc to using the full version of malloc.  Now
it allocated properly and only consumed new 8k pages when it needed
them.  I don't know why I had trouble getting that to build, after a
few config file tweaks and some make cleans, I got it to build.

Easy to figure how how to solve the problem once I discovered the
actual underlying behavior, but the inital problem had me scratching
my head for a week or so before I could understand where the problem
even was.

Thanks for your help.  I thought the list would appreciate the fix
info incase someone else searched for an answer.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] fix malloc whole page for small allocations?

[Steve deRosier]

Hi all,

Every time our application mallocs any small number of bytes (8k),
the device seems to malloc an entire page (8k). Does anyone know  why
this happens, and how I can fix it?

Full details:

This same application ran fine on a Linux 2.4.x (uClinux) platform,
but due to various reasons we've had to upgrade the platform to 3.3.0
(still uClinux). Coldfire mcf5235, 4 MB flash, 32 MB RAM. We're using
uClibc.

At the time we start the application, there is ~20 MB free, it runs
for 30+ seconds and then the OOM killer kills it. On the 2.4.x
platform, it has a high-water-mark of about 2 MB, and runs in the
steady-state at about 1.5 MB.

After much investigation (eventually culminating in a debug version of
malloc printing each allocation request, then sleeping for 2 seconds,
where I cat /proc/meminfo), we finally noticed that each allocation,
typically 10-40 bytes, reduces meminfos's MemFree by 8k.

Other than the underlying kernel and wholesale upgrade of the uClinux
base, nothing has really changed on the system. We're still selecting
the same packages and configuration as near as possible.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] fix malloc whole page for small allocations?

[Steve deRosier]

On Fri, Apr 12, 2013 at 8:00 AM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
 On Fri, Apr 12, 2013 at 07:34:19AM -0700, Steve deRosier wrote:
 Hi all,

 Every time our application mallocs any small number of bytes (8k),
 the device seems to malloc an entire page (8k). Does anyone know  why
 this happens, and how I can fix it?

 Imagine the amount of fragmentation you would get if different
 applications could all be given allocations from one page.  That would
 be a mess.  Now the libc could be smart and maintain a heap for you that

Well, yes, I do actually understand memory allocation in general and I
do get that it would be an issue for the kernel to give different
applications allocations from a single page.  That's not what I'm
concerned about.

It's that every single allocation, no matter how many bytes results in
a full page being allocated by the kernel. By my way of thinking, the
C library should be managing the heap and only getting a new page when
it needs one, not a single page each time.

Very importantly, it all worked as expected on the earlier uClinux
platform but isn't working correctly now.


 so it sure looks like uClibc does the sensible thing.  In that case small
 allocations shouldn't be a problem, unless you allocate a bunch, keep
 a few and free the rest, repeat a lot, causing enourmous fragmentation
 of the heap.  If that is the case, perhaps your algorithm needs a major
 rethink.

No, there shouldn't be lots of fragmentation in the way the algo
works. It does a bunch of allocations near the beginning of the
program to load up various working data sets. It does do some frees,
but in generally the allocations and frees related to those are in
chunks and ordered correctly to avoid fragmentation  Profiling it on a
normal desktop linux shows pretty good behavior with less than 1% heap
fragmentation  I happen to agree that the program in question needs a
major rethink, but that's neither germane to the question nor within
the scope of my contract with the client.



 Full details:

 This same application ran fine on a Linux 2.4.x (uClinux) platform,
 but due to various reasons we've had to upgrade the platform to 3.3.0
 (still uClinux). Coldfire mcf5235, 4 MB flash, 32 MB RAM. We're using
 uClibc.

 So it used to work and now it doesn't?


Yup.

 Might be worth listing the version of uClibc and other bits you are using,
 in addition to the kernel version.

Linux 3.3.0 on a Coldfire 5235 platform.  uClinux was from the
20120401 distribution. From digging into the uClibc directory, the
Changelog states: 0.9.27  12 January 2005. Which matches the old
version. So, either there's been and upgrade of uClibc and the
changelog is abandoned, or uClinux hasn't updated that package in a
little while. Since I can't confirm that our uClibc config is the same
between the old and new platforms, I'll assume our config of uClibc is
different.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] mount cramfs on loopback?

[Steve deRosier]

On Tue, Feb 19, 2013 at 11:59 AM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
 On Tue, Feb 19, 2013 at 10:04:41AM -0800, Steve deRosier wrote:

 Is your busybox built with BB_FEATURE_MOUNT_LOOP enabled?


No, it wasn't, but since I was manually doing the losetup command,
that wouldn't matter.  However, I've enabled the config and can now do
a loopback mount in one-shot which is nice. Thanks for the suggestion.


 Is your mountpoint in a location that permits mounts (apparently you can

Yes.

Update: I've managed to get it working, kind-of. Since I had a problem
with cramfs, but ext2 worked, I decided to try squashfs. This worked
for me on the first try. I had to install the tools for squashfs on my
dev machine manually, but my client is just going to have another tool
requirement. squashfs also gives me better compression, so thats a
positive.

I don't know what's up with cramfs. If I had to suspect, there's
something with the PAGE_SIZE thing. Coldfire uses an 8k page size, and
I found a note in cramfs's README that it only works on targets with
4k page sizes. But as I saw that you can manually change the block
size via a parameter to mkfs.cramfs, I was hoping that was an old
limitation. Seems odd to me that they'd limit a filesystem to be so
dependent on certain processors. And if that's the case, the kernel
shouldn't let me enable cramfs if it can't be used on my platform. But
since I've got squashfs working, it's not my problem anymore.

Time to finish up and move on to my next stumbling block.

Thanks for helping,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] [PATCH] MC68328 platform code fix

[Steve deRosier]

Hey Luis,

Maybe I'm confused, but in addition to the real changes, I'm seeing
quite a few things that I think are white space changes:

   */
 -#define IMR_MSPIM  (1  SPIM _IRQ_NUM)/* Mask SPI Master interrupt 
 */
 +#define IMR_MSPIM  (1  SPIM_IRQ_NUM) /* Mask SPI Master interrupt 
 */
  #defineIMR_MTMR2   (1  TMR2_IRQ_NUM) /* Mask Timer 2 
 interrupt */

I'm guessing that people will ask you to filter those out of your
functional commit before allowing the patches.

- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] mount cramfs on loopback?

[Steve deRosier]

Hi Lennart,

On Tue, Feb 19, 2013 at 8:40 AM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:

 The syntax from what I recall is:

 mount -t cramfs -o loop /path/imagefile /mountpoint



Yes, but that results in a Block device required error with
uClinux's Busybox mount command.


 Not really.  I haven't used cramfs for years.  I use cpio archives these
 days with initramfs's tmpfs.  Not quite the same thing though in terms
 of memory usage though.


Unfortunately, not the same thing at all.  And of course I'm not doing
this for the initial root filesystem. I'm trying to mount a filesystem
from a file after boot. Footprint on flash is important.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] mount cramfs on loopback?

[Steve deRosier]

OK, this is driving me crazy, I can't figure out how to get a cramfs
file to mount via loopback on my Coldfire target. I'm sure I'm missing
something simple, but I'm not seeing it. Can anyone help?

* cramfs is enabled in my kernel
* loopback is enabled in my kernel
* using busybox's mount command
* busybox's losetup is enabled

I'm able to create an ext2 filesystem and mount that in my target via
loopback using (so seems loopback support works OK):
# losetup /dev/loop0 /tmp/mye2fs.img
# mount -t ext2 /dev/loop0 /mnt

Trying the same with cramfs:
# losetup /dev/loop0 /tmp/mycramfs.img
# mount -t cramfs /dev/loop0 /mnt
mount: mounting /dev/loop0 on /mnt failed: Invalid argument

Same result if I give `mount -t cramfs -o loop /dev/loop0 /mnt`. I get
Block device required if I don't use losetup and try:
# mount -t cramfs -o loop=/dev/loop0 mycramfs.img /mnt

I've built the cramfs with both big and little endian (just to try).
If I build it with little, I get the following message in dmesg:
cramfs: bad root offset 1048576

No messages what so ever if I build big endian.

If I try building the stand-alone mount, that fails with a missing
header gnu/types.h. By a few searches, looks like that mount is no
longer maintained?

Is there a problem where busyboxes mount doesn't support cramfs?

Ideas?

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] Help with relocation truncation problems on m5235 coldfire target

[Steve deRosier]

Hi Larry,

On Fri, Feb 8, 2013 at 4:11 PM, Larry Baker ba...@usgs.gov wrote:
 Steve,

 I found this at
 http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/M680x0-Options.html.  I don't
 know if gcc 4.3.2 has this option, but it's worth a try.  Maybe you only
 have to use this in certain routines?  Maybe not, if there is just one GOT
 for the entire program.  Other google hits for relocation truncated to fit:
 R_68K_GOT16O said to remove XIP options or shared library, like -msep-data.
 I'm not sure that is possible on a ColdFire.  I noticed you are using -O1.
 Did you try -Os?  My ColdFire distribution uses -Os.

Yes, my research came up with the -mxgot option also. Tried that and
came up with a problem where the elf2flt doesn't like the larger GOT
format. Aparently it's a problem my client has been fighting with for
a long time and I was able to define out a log statement and that
killed enough strings (5,000 log strings!) in the project to get it to
build. Basically I was told: Get it to build and we'll deal with the
problem over here.  Done.

-Os helped some also, but not with the GOT issue. But size-wise it
helped. Upgrading to Linux 3.2 from 2.4 (and the other apps) has
increased our total image size by nearly 50% and we're starting to
bump into size issues. I'm having to kill off some useful technician
and debugging utilities now.

Thanks for the help.

- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] Coldfire watchdog timer best-practices?

[Steve deRosier]

I'd like to know what is the best way to handle the watchdog timer in
Linux? I've reviewed the docs and the watchdog framework and it's not
really fitting my needs.

The system I'm upgrading turns on the WDT very early in the
boot-loader  There is code sprinkled through the boot-loader and then
sprinkled through various init calls in Linux 2.4 that kick the WDT
before it times out all through boot. Eventually when userspace comes
up, a user program opens the WDT device and takes control of kicking
it via an ioctl into a custom gpio driver. Of course there's still a
few spots in the kernel and drivers that seem to kick the WDT during
normal operation, so it's still a remote possibility that a reset
wouldn't occur even if the user-space program died.

As you might imagine, I don't like that the original coders simply,
via trial and error, sprinkled a WDT kick call randomly through all
the various kernel init calls in order to keep things going. I was
hoping that with a formal WDT framework in 3.x that the kernel had
some sort of hook to handle it in a clean and accepted manner.

The kernel driver framework seems to assume that the WDT will only be
handled by userspace and indeed doesn't start the WDT until the device
is opened. As near as I can tell, there's no provision to handle a WDT
that's started during or before kernel boot. True?

It's important to note that the WDT on the MCF5235, once started, can
not be disabled. And once it's time period is set, that can't be
changed either. It's set at a max interval of about 8 seconds.

I have thought of a few ways to proceed:

1. Implement a standard WDT that doesn't start till userspace opens
the device and convince the system designers that's OK.
2. Implement the existing strategy and just sprinkle the kicking code
through the kernel init and drivers, and add the standard WDT that
userspace can open and take over with.
3. Implement some kernel process that takes over automatic periodic
kicking until the real WDT driver is opened the first time by
userspace. Then that process gets disabled.

Anyway, any thoughts? How have other Coldfire projects handed the WDT in Linux?

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] Help with relocation truncation problems on m5235 coldfire target

[Steve deRosier]

I hope someone here can help.  I'm trying to port an older project
from ~5 year old version of uClinux to a current version.  I've
managed to get everthing done, until I went to actually port the
business logic app.  I'm getting the following types of errors when it
goes to link:
'relocation truncated to fit: R_68K_GOT16O'

Some searching and I roughly understand the problem, and the alleged
solution is to build some of the problem files with the -mxgot flag.
Fine.  Then the following error:
'/usr/local/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_uClinux/m68k-uclinux/bin/elf2flt:
error: reloc type R_68K_GOT32O is not supported'

@#$%^#@!

Compile command line:
ucfront-gcc m68k-uclinux-gcc -mcpu=5235 -DCONFIG_COLDFIRE -O1 -g -pipe
-fno-common -fno-builtin -Wall   -DEMBED -msep-data -Dlinux
-D__linux__ -Dunix -D__uClinux__ -Wall -Werror -Wno-unused
-Wpointer-arith  -MD
-I/home/derosier/inthinc/projects/mcm820kernel/lib/libhessian/include
-I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/src
-DCONFIG_5235 -DDIRECT_CALL -I./include -I/usr/include/libxml2
-I/home/derosier/inthinc/projects/mcm820kernel/staging/include
-I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/src/common
-I/home/derosier/inthinc/projects/mcm820kernel/user/iwi/modules/sbs_module/include
-I/home/derosier/inthinc/projects/mcm820kernel/lib/libhessian/include
-c -o src/controller/queue.o src/controller/queue.c

When I keep the intermediates, here's the header at the top of the .s file:
| GNU C (Sourcery CodeBench Lite 2011.09-23) version 4.6.1 (m68k-uclinux)
| compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.9
| GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
| options passed:  -fpreprocessed controller.i -mcpu=5235 -msep-data
| -auxbase-strip src/controller/controller.o -g -O1 -Wall -Werror
| -Wno-unused -Wpointer-arith -fno-common -fno-builtin -fverbose-asm
| options enabled:  -fPIC -fauto-inc-dec -fbranch-count-reg
| -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdefer-pop
| -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
| -feliminate-unused-debug-types -fforward-propagate -ffunction-cse
| -fgcse-lm -fguess-branch-probability -fident -fif-conversion
| -fif-conversion2 -finline -finline-functions-called-once -fipa-profile
| -fipa-pure-const -fipa-reference -fira-share-save-slots
| -fira-share-spill-slots -fivopts -fkeep-static-consts
| -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings
| -fmove-loop-invariants -fpeephole -fprefetch-loop-arrays
| -freg-struct-return -fsched-critical-path-heuristic
| -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
| -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
| -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column
| -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types
| -fstrict-volatile-bitfields -ftoplevel-reorder -ftrapping-math
| -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename
| -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
| -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
| -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pta
| -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize
| -ftree-sra -ftree-ter -ftree-vect-loop-version -funit-at-a-time
| -fvar-tracking -fvar-tracking-assignments -fverbose-asm
| -fzero-initialized-in-bss -mdiv -msep-data


Link:

ucfront-gcc m68k-uclinux-gcc -mcpu=5235 -DCONFIG_COLDFIRE -Wl,-elf2flt
-Wl,-move-rodata -msep-data -Wl,-elf2flt -Wl,-move-rodata -msep-data
-L/home/derosier/inthinc/projects/mcm820kernel/user/iwi/libhessian -o
controller {...lots of .o...} libhessian/libhessian.a -lz -lm  -lm

I suspect one of the fundamental problems is the code has some HUGE
functions (2500+ lines) with huge switch blocks, but I'm here mainly
to port not to muck with (ne refactor) the logic.

All help will be appreciated.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] Coldfire uClinux boot with u-boot

[Steve deRosier]

Belated update:

First thanks to everyone who helped.

Greg was right: I wasn't setting necessary chip selects up. I managed to
find that three of the drivers for our custom perhipherals were borking and
when I tried to figure out what they had in common it was a duh moment.
 It's so funny: when you build from the start you think of chipselects and
other basic setups, but going from a working system backwards it was less
obvious to look at that.

Turns out I also had a problem with my SDRAM settings.  This board has a
second SDRAM chip and thus needs both sets setup properly.  Found out the
hard way that I hadn't set the second one up and thus was essentially
shadowing 32MB over 16MB of chip.  Unfortunately, due to a bug in the .h
files of u-boot, it took me several days to fix. The SDRAMC_DARCn_BA()
macro was broken (patch has already been sent to the u-boot list).

In any case, thanks so much for all the help.

- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] Split kernel and romfs image into files on jffs2 using u-boot?

[Steve deRosier]

The subject sentence summarizes it pretty well.  I want to take my uClinux
image, split the kernel and romfs into two separate files, put it on jffs2
in my flash and get u-boot to load and boot the kernel properly.  Sounds
easy enough, but I'm clearly missing a bit of info, maybe someone here can
help me before I have to read both all of u-boot's source and the uClinux
MTD map driver.

Details:
1. Starting point - standard uClinux build with a combined kernel and
romfs (after .bss) image. Image ran through mkimage and then written
directly to flash. Start in u-boot via a 'bootm 0xffc2' command. Of
course this works exactly as expected.
2. First step - erased and changed my flash configuration to jffs2, wrote
the combined uImage.bin.gz.uboot file into that filesystem. U-boot commands
'fsload 0x01c0; bootm 0x01c0' allows it to boot as expected. This
works fine.
3. Next step - split romfs and kernel out, package them separate and load
them separately. I can get the kernel to boot, then panic on lack of init,
but I can't seem to figure out the magic sauce to get this to work.

Specifically, here's what I did to package the inividual parts:

$(ROOTDIR)/u-boot-2012.07/tools/mkimage -A m68k -O linux -T kernel -C gzip
-a 0x2 -e 0x2 -n kernel -d $(IMAGEDIR)/linux.bin.gz
/tftpboot/linux.bin.gz.uboot
$(ROOTDIR)/u-boot-2012.07/tools/mkimage -A m68k -O linux -T ramdisk -C gzip
-n RomFs -d $(ROMFSIMG).gz /tftpboot/romfs.bin.gz.uboot

Then I tried the obvious commands in u-boot (after getting them to the
filesystem), compleate with uboot's output:

5235IWI fsload 0x01b0 /linux.bin.gz.uboot
### JFFS2 loading '/linux.bin.gz.uboot' to 0x1b0
### JFFS2 load complete: 1368831 bytes loaded to 0x1b0
5235IWI ls
 -rw-r--r--   11 Mon Jan 28 23:17:54 2013 test.txt
 -rw-r--r--  1414220 Tue Jan 29 16:36:18 2013 romfs.img.gz.uboot
 -rw-r--r--  1368831 Tue Jan 29 16:32:04 2013 linux.bin.gz.uboot
5235IWI fsload 0x01d0 /romfs.img.gz.uboot
### JFFS2 loading '/romfs.img.gz.uboot' to 0x1d0
### JFFS2 load complete: 1414220 bytes loaded to 0x1d0
5235IWI bootm 0x01b0 0x01d0
## Booting kernel from Legacy Image at 01b0 ...
   Image Name:   IWI Kernel
   Image Type:   M68K Linux Kernel Image (gzip compressed)
   Data Size:1368767 Bytes = 1.3 MiB
   Load Address: 0002
   Entry Point:  0002
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01d0 ...
   Image Name:   IWI romfs
   Image Type:   M68K Linux RAMDisk Image (gzip compressed)
   Data Size:1414156 Bytes = 1.3 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 01dd8000, end 01f3140c ... OK

I totally don't understand how or why u-boot picks the load address it
does. I even forced specific load addresses into the image using -a with
mkimage, and it still loads it thusly.

For the kernel, I tried to change CONFIG_MTD_UCLINUX_EBSS and specify the
loading address (tried both where I was loading with fsload and where uboot
seemed to load it), but I get a hung kernel with those options.

Anyway, I'm sure it's fairly simple since it looks like all the general
parts exist, so if someone could point the way I'd really appreciate it.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] Coldfire uClinux boot with u-boot

[Steve deRosier]

Thanks to all that replied.

I'm still not 100% there, but finally got further.  Greg, I should've just
coded up the UART output like you suggested, but I had already started
using a GPIO pin I could easily access and hooked it up to my oscope.  I
did the same as you suggested, and popped it into head.S and confirmed that
u-boot was at least jumpping into the kernel.  Then I used code similar to:

*((volatile u8 *)0x401B) = (u8)(0x01);
mdelay(10);
*((volatile u8 *)0x401B) = (u8)(0x00);

and used that in the C startup code to trace through.  Eventually I figured
out it was getting stuck on my RTC driver (on my platform_driver_register()
call), commented that out, and it got far enough to put stuff out the
console.  Then it oopsed. This was durring the second mtd map operation
(I've got two flash chips on this thing):

.
.
.
Flash external probe(0xff40,4194304,2): 40 at ff40
bad frame format: 
Modules linked in:
PC: [00133650] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008  SP: 0183be58  a2: 0027a8f4
d0: 0002d1: ff40d2: d3: 0008
d4: f0f0d5: 0002a0: ff40a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=
Stack from 0183be94:
0183bf32 0001 0002 0001 0183bf32 0027a8f4 
00131c36
 0027a8f4 0183bf32 0024c92f 004c 0183bf32 0001
0002
0001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
  0183bf32 0024c92f 004c 6800 0027a8f4
01f6523a
01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
0027
 0002 0001    

Call Trace: [00131c36] cfi_probe_chip+0x3c/0xaee
 [0024c92f] packet_seq_ops+0x59fc9/0x65b86
 [0012b4cc] mtd_device_parse_register+0x0/0xc8
 [000f3acc] memset+0x0/0x7c
 [00131b2e] do_map_probe+0x0/0xb6
 [0013a9d2] mtd_do_chip_probe+0x8e/0x3d8
 [0024c92f] packet_seq_ops+0x59fc9/0x65b86
 [00131ab0] get_mtd_chip_driver+0x0/0x7e
 [0012b4cc] mtd_device_parse_register+0x0/0xc8
 [001d7a1c] printk+0x0/0x18
 [00131b2e] do_map_probe+0x0/0xb6
 [00131bf4] cfi_probe+0x10/0x16
 [00131b52] do_map_probe+0x24/0xb6
 [001d7a1c] printk+0x0/0x18
 [0028f9b4] m5235_mtd_init+0xb8/0x16e
 [0024c92f] packet_seq_ops+0x59fc9/0x65b86
 [0028f8fc] m5235_mtd_init+0x0/0x16e
 [000200c8] do_one_initcall+0x0/0x1d8
 [000201d8] do_one_initcall+0x110/0x1d8
 [000200c8] do_one_initcall+0x0/0x1d8
 [0028666a] kernel_init+0x82/0x106
 [0028f8fc] m5235_mtd_init+0x0/0x16e
 [002865e8] kernel_init+0x0/0x106
 [00020a3a] kernel_thread+0x2a/0x3c

Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 6000 f7f0 2204 2e05 e989
e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!


So, I'm out of the woods so to speak, but not quite there yet.  What I'm
totally flummoxed by is the fact that these drivers (indeed, the whole
kernel and the stuff in userspace) works just fine booted from the old
u-boot, but crap out from the new u-boot.  Clearly I've done something
wrong here, but I'm not sure what or how.  Based on behavior, I'm going to
be taking a very close look at the RAM allocations and stack space. Though
the stack pointer above is within my address space (32M, starting at 0, so
0x to 0x0200). Mayhaps I'm running over my stack, hence a bad
frame format: ?  Not 100% sure of that particular message, got to
look that up.

Anyway, this is as far as I got today, tomorrow I'm going to be examining
the oops in detail and figure out why/what's going on.

I can't immagine what the difference between the old u-boot and the new one
would be that could cause the kernel to work in former case but totally
crash in the latter. I'm open to suggestions.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] USB driver: when and how is the probe function called?

[Steve deRosier]

stl,

Perhaps the people on the USB list might be more helpful since that would
be about the USB subsystem. I can give you some general ideas though.

I'm assuming you're talking about a USB device driver, not a USB chipset
driver.

I'd guess the info you found was correct, as the actual usb docs state
(linux/Documentation/usb/callbacks.txt): @probe: Called to see if the
driver is willing to manage a particular interface on a device.

Basically what happens is thus: 1. user plugs in a device. 2. USB chipset
detects that, powers the device, standard USB comms start, and the device
id comes through. (And yes, somewhere in here the chipset's IRQ is
triggered.) 3. The Linux USB core uses that information and calls the
hotplug service (a program in userspace), which tells the kernel what
driver handles it, possibly loading the kernel module, sending firmware or
whatever is needed, etc.  4. The kernel uses that information and calls the
function that you registered as the function pointer for probe. Somewhere
there's a call along the lines of driver_struct-probe(...). 5. Your probe
function does what it does, but one major thing it has to do is return a
value that indicates that it is your device and you handled it, OR it's not
your device and you did nothing important.

You specifically asked about the IRQ. USB devices don't have IRQ lines, the
USB chipset does. Generally speaking, you don't care about the IRQ since
that will be handled in the USB chipset driver code and will trigger the
USB core, which then will call the device-specific callbacks if necessary.
 I have seen a few pathological designs that break the proper USB model and
(with on-board hardware), hard-wire an interrupt line from a device to the
uC, while still communicating through a USB chipset.  Despite huge
workarounds costing many tens of thousands of dolars in developer time,
these never seem to work well and at best limp along no better than a
properly done USB connection. Why? Because you have to wait for the USB
comms anyway, there's no provision for an out-of-band channel trigger.

There's extensive documentation in Documentation/usb/.  Also, there's no
substitute for reading a bit of code. I highly recommend you
become familiar with the use of cscope or a similar code delving tool.
Often times, good use of cscope won't help much in this particular case (it
doesn't ID field names as symbols), so do a text search or grep within the
usb sub-directory for the form '-probe(', which should show you where it's
called and you can then follow the chain from there.

I hope that helps some.
- Steve


On Fri, Jan 11, 2013 at 6:30 AM, stl st.lamber...@gmail.com wrote:

 Hello all,
 I am writing a USB driver for a new architecture support.
 I have define a usb_driver structure with a probe function as field.
 But I am wondering when and how this function is called?

 I have read on the book Linux Device Drivers 3rd edition (usb driver
 chapter)
 that this function is called by the USB core when it thinks it has a
 struct usb_interface
 that this driver can handle.

 So I suppose that when a usb device is attached, the corresponding IRQ is
 received
 from the hardware, and something in the ISR should tell the USB core that
 the probe
 function needs to be called.
 Could someone clarify the procedure please?

 Thanks in advance for your help.


 ___
 uClinux-dev mailing list
 uClinux-dev@uclinux.org
 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
 This message was resent by uclinux-dev@uclinux.org
 To unsubscribe see:
 http://mailman.uclinux.org/mailman/options/uclinux-dev

___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] Coldfire uClinux boot with u-boot

[Steve deRosier]

Hi all,

I'm stuck trying to get Linux to boot from U-Boot on a Coldfire system and
I'd love some ideas of what to try next.

I'm upgrading a uClinux system from a 2.4 kernel to 3.3. Additionally I'm
trying to upgrade the boot-loader from u-boot 1.1.6 to release 2012.07.
 The board is based on a MCF5235EVB. I did the Linux upgrade first, and
am successfully getting the existing system boot loader to boot my upgraded
Linux 3.3 images. Now I've moved on to upgrading u-boot.

I was able to get U-Boot to come up successfully and it recognizes my Linux
image and a bootm command starts just fine.  It does the checks,
uncompresses, and goes to boot.  I turned on the debug messages in U-Boot,
so I get the ## Transferring control to Linux (at address 0x2) ...
message, it goes and does the jump and then...nothing...

Note that the exact same Linux image boots fine from 1.1.6.  My 1.1.6 can
boot both the 2.4 legacy image as well as my new 3.3 image.

Unfortunately I've got minimal visibility into the system (My BDM interface
is being a PITA, I've got assembly-only stepping, using
CodeWarrior!!@#!@$!, in flash only.  Pretty much nothing else is
functioning right at the moment), so I've been relegated to
debug-via-printf, which isn't terribly useful at the interface between
u-boot and linux.

Through reading code, I see a huge discrepancy between how 1.1.6 and
2012.07 starts the kernel.

1.1.6 uses a line:
 theKernel (linux_argc, linux_argv, linux_env, 0);

2012.07:
/*
 * Linux Kernel Parameters (passing board info data):
 *   sp+00: Ignore, side effect of using jsr to jump to kernel
 *   sp+04: ptr to board info data
 *   sp+08: initrd_start or 0 if no initrd
 *   sp+12: initrd_end - unused if initrd_start is 0
 *   sp+16: Start of command line string
 *   sp+20: End   of command line string
 */
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);

Clearly different... I'd assume that U-Boot's Linux starting magic is in
sync with the current Linux kernel, but if that's the case, and these are
actually as different as they appear, then the OLD U-Boot should have a
problem starting the NEW kernel also.  For grins, I grafted on the old
sequence code into the new U-Boot, but that (as expected) failed also.

I looked at the Coldfire startup code and it looks like it corrosponds to
the same comment in U-Boot, and interestingly it seems to discard the bd_t
structure that's passed in first.

So far I think I've figured this out:
* The FDT isn't used on Coldfire targets.
* The Coldfire code discards the bd_t data passed in through u-boot.
* Something funky is going on keeping Linux from booting, and it happens
early enough that I can't see it in printk-land.

If it makes a difference, for some reason we load kernel at 0x2 and
jump to 0x2. This is a legacy of the existing project, I've tried to
change it to 0x0, but that didn't help either. I had suspected it had to do
with where the old bootloader placed itself in RAM, but it shouldn't be an
issue with the new bootloader.

For reference:
RAM: 0x, 32MB
SRAM: 0x2000
MBAR: 0x4000
Flash: 0xFFC0, 4mb (second flash module at 0xFF80, but U-Boot
doesn't know about that one). Image is stored at 0xFFC4 and uses an
initrd romfs immedately after the kernel

Basic setup and design is similar to the 5235EVB.

CONFIG_UBOOT, MTD_UCLINUX and MTD_UCLINUX_EBSS are all Y.

I've been bashing my head against this wall all week, so I'd love it if
anyone's got some ideas.

Thanks,
- Steve

5235IWI bootm 0xffc4
## Current stack ends at 0x01f2ca2c *  kernel: cmdline image address =
0xffc4
## Booting kernel from Legacy Image at ffc4 ...
   Image Name:   IWI 007
   Image Type:   M68K Linux Kernel Image (gzip compressed)
   Data Size:2270515 Bytes = 2.2 MiB
   Load Address: 0002
   Entry Point:  0002
   Verifying Checksum ... OK
   kernel data at 0xffc40040, len = 0x0022a533 (2270515)
## No init Ramdisk
   ramdisk start = 0x, ramdisk end = 0x
   Uncompressing Kernel Image ... OK
   kernel loaded at 0x0002, end = 0x00470404
## cmdline at 0x01f2c520 ... 0x01f2c520
## kernel board info at 0x01f2c4e0
memstart= 0x
memsize = 0x0200
flashstart  = 0xFFC0
flashsize   = 0x0040
flashoffset = 0x
sramstart   = 0x2000
sramsize= 0x0001
mbar= 0x4000
cpufreq =150 MHz
busfreq = 75 MHz
baudrate= 57600 bps
## initrd_high = 0x, copy_to_ram = 1
   ramdisk load start = 0x, ramdisk load end = 0x
## Transferring control to Linux (at address 0002) ...
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] Segmentation fault while running some applications!

[Steve deRosier]

On Tue, Dec 18, 2012 at 4:58 AM, Arshan Awais arshanc...@gmail.com wrote:
 Hi Greg,

 I recompiled my kernel and used None option instead of uClibc,
 uC-libc or glibc in menuconfig. (because i am also having issues in
 compilation when i select options other than 'None' while library
 selection)
 This time when i ran iptables -v, i got the following dump:

 iptables[377] killed because of sig - 11


You sort of need a C library for any C code you're working with. I
suppose if you're hand-writing assembly code, you wouldn't need it,
but, last I looked iptables is C code and should require to link
against a C library of some sort. If you're getting successful
compilation and link and not building any of the three supported C
libraries, then you've got pretty big problems. Depending on your
environment, I see one of the following possibilities:

1. You're actually not building a cross-compiled image for your
target. In other words: you're building using your host's compilers
targeting your host computer. Then you're moving the exe to a
different target processor and boom!
2. Your x-compiler is linking against some of it's preconfigured C
libraries, if static, that's probably OK, but if it's a shared link,
you'll need to push those into your filesystem image.
3. Your compiler is linking against some left-over objects, but those
aren't getting inserted into your image because you've turned off the
C libs.
4. All is well with your environment, and you've edited some code and
inserted a read/write to an invalid address (most likely null) and you
need to debug that.

I'm sure there's more possibilities, but 4 seems like enough for now.

If you're using a stock uClinux, and a stock target board, and a
proper environment, most things should pretty well work out of the
box. Do other programs function properly and iptables is the only
thing that's failing? If that's the case, it's possible there's a bug
in whatever version of iptables that you're working with. Or, you need
to enable some feature it depends on that's not turned on by default.

Just a few ideas, hope it helps.

- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] keep jffs2 from scanning uClinux ROMFs?

[Steve deRosier]

Erwin,

Thank you.  I knew I was missing something simple.  Your suggestion
fixed the problem.  Now on to the next issue...

Thanks,
- Steve

On Tue, Dec 11, 2012 at 12:27 AM, Erwin Authried ea...@softsys.co.at wrote:
 you should specify rootfstype=romfs on the kernel commandline.

 -Erwin

 Am Monday, den 10.12.2012, 21:08 -0800 schrieb Steve deRosier:
 Everything is going fine (I can boot, the system is all good, I can
 even see MTD partitions I've setup), until I enable jffs2 support.
 Then on boot, it seems to want to scan my root file system and treat
 it like jffs2, and I get:

 uclinux[mtd]: RAM probe address=0x2ae368 size=0x178000
 uclinux[mtd]: set ROMfs to be root filesystem
 Creating 1 MTD partitions on RAM:
 0x-0x00178000 : ROMfs
 Flash external probe(0xffc0,4194304,2): 40 at ffc0
 External_Flash: Found 1 x16 devices at 0x0 in 16-bit bank.
 Manufacturer ID 0x01 Chip ID 0x0022f9
 Amd/Fujitsu Extended Query Table at 0x0040
   Amd/Fujitsu Extended Query version 1.1.
 number of CFI chips: 1
 Creating 4 MTD partitions on External_Flash:
 0x-0x4000 : simpleboot
 0x4000-0x6000 : ubootenv
 0x6000-0x0004 : uboot
 mtd: partition uboot doesn't start on an erase block boundary --
 force read-only
 0x0004-0x0040 : image
 Flash external probe(0xff40,4194304,2): 40 at ff40
 External_Flash2: Found 1 x16 devices at 0x0 in 16-bit bank.
 Manufacturer ID 0x01 Chip ID 0x0022f9
 Amd/Fujitsu Extended Query Table at 0x0040
   Amd/Fujitsu Extended Query version 1.1.
 number of CFI chips: 1
 Creating 1 MTD partitions on External_Flash2:
 0x-0x0040 : rootfs
 ...
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x:
 0x2d72 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004:
 0x3166 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0008:
 0x0017 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c:
 0xad0c instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0010:
 0x524f instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0014:
 0x6973 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x002c:
 0xd1ff instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0030:
 0x2e00 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c:
 0xd1d1 instead
 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0050:
 0x2e2e instead
 Further such events for this erase block will not be printed
 JFFS2: Erase block at 0x is not formatted. It will be erased
 

 I'm using uClinux RAM/ROM filesystem is located at ebss
 (MTD_UCLINUX_EBSS), with a ROMfs.  It looks like jffs2's trying to
 scan my mtd0 device, even though that's a just fine mounted ROMfs
 that's loaded in RAM. AFAIK, I haven't done anything to tell the
 system to mount mtd0 as jffs2.

 Is there any way to tell jffs2 to not scan things I'm not specifically
 telling it are jffs2?  I'm working on a legacy system with mixed
 filesystem types, with one of the flash partitions having a jffs2 and
 the other 3 partitions set up differently.  And that's not to mention
 the fake MTD partition that the MTD_UCLINUX_EBSS configuration
 creates.

 Thanks in advance,
 - Steve
 ___
 uClinux-dev mailing list
 uClinux-dev@uclinux.org
 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
 This message was resent by uclinux-dev@uclinux.org
 To unsubscribe see:
 http://mailman.uclinux.org/mailman/options/uclinux-dev

 --
 Dipl.-Ing. Erwin Authried
 Softwareentwicklung und Systemdesign

 ___
 uClinux-dev mailing list
 uClinux-dev@uclinux.org
 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
 This message was resent by uclinux-dev@uclinux.org
 To unsubscribe see:
 http://mailman.uclinux.org/mailman/options/uclinux-dev
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] jffs to jffs2 filesystem

[Steve deRosier]

Is there anyway to upgrade an old jffs filesystem to jffs2?

After getting jffs2 and mtd working properly on my new kernel image, I
tried to mount the existing flash. Bad fail. Long story short, I
eventually noticed the existing flash is formatted with old v1 jffs,
not jffs2. Trying to mount it as jffs2 and it spews lots of messages
including:
Old JFFS2 bitmask found at 0x0009a1dc
You cannot use older JFFS2 filesystems with newer kernels
and eventually gives up with the message:
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes

OK, fair enough.  Research leads me to believe that modern Linux
doesn't retain the old v1 jffs system, nor is the jffs2 file system
willing to read or write it. I'm upgrading the kernel on this product
for very good reasons, and ideally we need to keep compatibility with
the existing data in the field.

Is there any way to upgrade an old jffs filesystem to jffs2 with
current versions of Linux? Alternately, is there a jffs implementation
that works with a 3.x Linux as per the modern uClinux distro? Or does
anyone have any other ideas?

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] keep jffs2 from scanning uClinux ROMFs?

[Steve deRosier]

Everything is going fine (I can boot, the system is all good, I can
even see MTD partitions I've setup), until I enable jffs2 support.
Then on boot, it seems to want to scan my root file system and treat
it like jffs2, and I get:

uclinux[mtd]: RAM probe address=0x2ae368 size=0x178000
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on RAM:
0x-0x00178000 : ROMfs
Flash external probe(0xffc0,4194304,2): 40 at ffc0
External_Flash: Found 1 x16 devices at 0x0 in 16-bit bank.
Manufacturer ID 0x01 Chip ID 0x0022f9
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.1.
number of CFI chips: 1
Creating 4 MTD partitions on External_Flash:
0x-0x4000 : simpleboot
0x4000-0x6000 : ubootenv
0x6000-0x0004 : uboot
mtd: partition uboot doesn't start on an erase block boundary --
force read-only
0x0004-0x0040 : image
Flash external probe(0xff40,4194304,2): 40 at ff40
External_Flash2: Found 1 x16 devices at 0x0 in 16-bit bank.
Manufacturer ID 0x01 Chip ID 0x0022f9
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.1.
number of CFI chips: 1
Creating 1 MTD partitions on External_Flash2:
0x-0x0040 : rootfs
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x:
0x2d72 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004:
0x3166 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0008:
0x0017 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c:
0xad0c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0010:
0x524f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0014:
0x6973 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x002c:
0xd1ff instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0030:
0x2e00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c:
0xd1d1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0050:
0x2e2e instead
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x is not formatted. It will be erased


I'm using uClinux RAM/ROM filesystem is located at ebss
(MTD_UCLINUX_EBSS), with a ROMfs.  It looks like jffs2's trying to
scan my mtd0 device, even though that's a just fine mounted ROMfs
that's loaded in RAM. AFAIK, I haven't done anything to tell the
system to mount mtd0 as jffs2.

Is there any way to tell jffs2 to not scan things I'm not specifically
telling it are jffs2?  I'm working on a legacy system with mixed
filesystem types, with one of the flash partitions having a jffs2 and
the other 3 partitions set up differently.  And that's not to mention
the fake MTD partition that the MTD_UCLINUX_EBSS configuration
creates.

Thanks in advance,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] How to enable USB_ARCH_HAS_HCD for embedded target?

[Steve deRosier]

Can anyone tell me the proper or accepted way to enable
CONFIG_USB_ARCH_HAS_HCD for my embedded uClinux project?

I have a bus-connected c67x00 USB chip on my mcf5235 system. To get it
running and make the chip-driver accessible, I hacked the
linux-3.x/drivers/usb/Kconfig:
 config USB_ARCH_HAS_HCD
  boolean
  default y if USB_ARCH_HAS_OHCI
  default y if USB_ARCH_HAS_EHCI
  default y if USB_ARCH_HAS_XHCI
  default y if PCMCIA  !M32R # sl811_cs
  default y if ARM # SL-811
  default y if NIOS2 # SL-811
  default y if BLACKFIN # SL-811
  default y if SUPERH # r8a66597-hcd
+ default y if M523x
  default PCI

I selected the right stuff, setup the platform device in my board-specific
.c files and have it running and tested.  Now I want to cleanup so I can
make my commits.

Obviously this is a board-specific thing, not a generic linux thing, so
what's the better way of doing this?

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] How to enable USB_ARCH_HAS_HCD for embedded target?

[Steve deRosier]

On Tue, Oct 2, 2012 at 4:29 PM, Gavin Lambert gav...@compacsort.com wrote:

 Quoth Steve deRosier:
  Can anyone tell me the proper or accepted way to enable
 CONFIG_USB_ARCH_HAS_HCD
  for my embedded uClinux project?
 [...]
  Obviously this is a board-specific thing, not a generic linux thing, so
 what's the
  better way of doing this?

 You should have a board-specific directory in the vendors tree, and have
 that selected as your current board via the top-level uClinux makefile
 (CAUTION: if you change the board selection it will replace your current
 .config files and do a clean rebuild, so make sure you've saved your
 current
 ones elsewhere if you need to change the selected board and have changes
 you
 wish to preserve).

 One of the options in the top-level makefile's config menu is to save your
 modified .config files to the vendors folder as the new defaults for that
 board.  (Or if you want to do it manually, look at the existing vendor
 folders.  The naming conventions for the default config files should
 hopefully be obvious.)


Thanks Gavin.  I had tried that.  The problem is, this particular flag is
not a user-selectable one, and even if I enable it by directly editing the
vendors/.../config.linux, it always gets undone when I actually go and
configure my kernel.  This option seems to be forcibly enforced by the
Kconfig.  There's got to be some way to keep it without hacking the Kconfig.

Thanks,
- Steve
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev