New mini2440 project (kernel, tools, ...)

Hello,

I have customized, fixed (e.g. the dm9000 network driver) and added some
nice features (like buzzer driver, touchscreen support etc.) in the linux
2.6.33 kernel for the mini2440 board and made a public git repository (I
also have stripped some unneeded files and directories). You can reach it
under
http://git.programmers-projects.de/?p=mini2440-dev.git;a=tree;hb=master

Developers are welcome to improve stuff and fix some bugs if there are
some. Compilation and booting should work fine. If you would like to join,
you can create an account on http://www.programmers-projects.de
The same account data you can also use to get write access to the
repositories over webdav so you don't have to register twice. The address
for accessing the project with your git client is
http://<username>@git.programmers-projects.de/mini2440-dev.git


Its planned to get the new QT embedded with a nice GUI working too.


Sincerely

Jay

Thank you for making your work available.

Just curious:  I recall a DM9000 issue in the deep dark past, was this not
fixed in 2.6.32.2?  If not, what was the problem?

Any GPIO and/or SPI support built in?

Cheers,
Dave

No problem, its my hobby and also git is good for backups and fixing stuff.

I have begun with the original 2.6.33 kernel (without patching the 2.6.32.2
source from friendlyarm) so I had to fix it manually. Now it is a
completely new mini2440 kernel tree with its own way and "style" ;)

Also the usb upload program is fixed and has some other little nice
features like percentage done and the memory should be freed correctly now
(in the original version, memory wasn't freed (correctly) before exit).

The next thing I will fix are the screen offsets (on my N35 display it's
not correct - there are black borders on the left and a little one on the
top).

Its surely this definition in the mach-mini2440.c file:
  [0] = {  /* mini2440 + 3.5" TFT + touchscreen */
    _LCD_DECLARE(
      7,      /* The 3.5 is quite fast */
      240, 21, 38, 6,   /* x timing */
      320, 4, 4, 2,    /* y timing */
      60),      /* refresh rate */
    .lcdcon5  = (S3C2410_LCDCON5_FRM565 |
           S3C2410_LCDCON5_INVVLINE |
           S3C2410_LCDCON5_INVVFRAME |
           S3C2410_LCDCON5_INVVDEN |
           S3C2410_LCDCON5_PWREN),
  },

I don't know why it hasn't already been fixed :/

Can you please tell me the correct offsets?

Thanks.

Hello,

maybe you would be interested in including the driver for the onboard
camera as well?

I am working on improved version : http://code.google.com/p/s3c2440camera/

Hi Jay,
Would you please share the diff of your work? It would be great if I can
patch your changes into my local source.

Cheers!

Netzwerkchip-Treiber (DM9000) - Bugfixes (MAC-Addresse etc. angepasst)

angepasst = adapted

Any details?

Offset problem:  I would suggest digging into the patches that buserror has
done to get issues like this sorted in the standard kerenel.

Thanks,
Dave

Hi Jay,

Mabe my suggestion will be stupid, but do you plan to integrate VIA VNT6656
wifi module driver to your kernel? It would be nice!

Thanks for your work

Okay, setting mini2440=3tb worked for me. It's the "T35" configuration but
it seems to be correct. The camara support should work if you just copy the
.ko file of the camera driver into the modules directory of mini2440 and do
insmod.

I will think about implementing the features told above. The problem is,
that I havn't a camera or wifi adapter so I can't test if it works. Maybe
another one would like to integrate these features (e.g. add files for
camery support in drivers/media/video/ov9560) of the kernel tree and fix
the Kconfig and Makefile of the )?

As I said the changes can be synchronized with your local pc by using a Git
client (you only need an account for getting write access). The address for
reading the mini2440-dev repository with a Git client is
http://git.programmers-projects.de/mini2440-dev.git (works over webdav).

Hint: the kernel camera driver will be loaded if you add 'c' to the
mini2440= parameterstring (e.g. mini2440=3tbc will enable T35 display +
touchscreen + backlight + camera interface).

Jay,

could you place a tar.gz or a zip of the kernel sources on the git page? 

Thanks,

I added the git snapshot download feature so you can download a snapshot of
every directory you want.

That was fast. :-)

Now, has this kernel tree suffered a lot of tweaking? 

[I'm asking this because I try to patch it with Xenomai and it's
impossible, since so many (unneeded) files were removed (after partial
Xenomai patching, I get an ugly error message).]

So, what patch was it that you applied to the vanilla kernel in order to
make it successfully compile and boot? 

Thanks.

Hi Jay,

One more time, I have a "easy to say, not to do" sugestion : maybe it could
be interesting to add a kind of generic driver which allow to drive each
digitl or ADC I/O of the board. Original FriendlyARM board comes with a led
driver, buttons and ADC1 channel drivers. I don't know if somebody has
already developped something more generic for the moment, but it could be a
nice idea. And this will offer many possibilities with your next step with
Qt embedded

To keep in mind?

Thanks

I vote for Screwface idea :
a kind of abstraction "driver" or utility that would drive the leds,
buttons, and >SPI +I2C< .
 Big but really usefull work. Maybe we could start ourselves ?

The problem is that there is so much "hacked crap" floating about that we
will end up in a complete mess.

By  "hacked crap" , I mean people going into kernel source and making
random and STUPID changes.

for example......


#if defined(CONFIG_ARCH_S3C2410)
  printk("Now use the default MAC address: 08:90:90:90:90:90\n");
  mac_src = "friendly-arm";
  ndev->dev_addr[0] = 0x08;
  ndev->dev_addr[1] = 0x90;
  ndev->dev_addr[2] = 0x90;
  ndev->dev_addr[3] = 0x90;
  ndev->dev_addr[4] = 0x90;
  ndev->dev_addr[5] = 0x90;
#else
  mac_src = "eeprom";

There are ways to do this , and this is not it.....

mouha,

If you take a look in the linux kernel there IS already an abstraction
layer......
that allows reading and writing of this sort of IO by setting/reading flags
in one of the linux  directories..

possibly /dev/'somethignorother' if i remember rightly.

Right. There is already nearly everything compiled in you need (an own
buzzer driver too as you can hear if you start the board). The leds can be
found in the /sys/class/leds directory structure... Nearly everything that
you can control you can find in the /sys/class system (in the newer linux
kernels its standard).

I don't understand why all kernel developers I know use compiled in mac
address settings.  there is an eeprom on the board (as far as I know its
1kB in size - I will only need the first 6 bytes for storing the mac
address). I try to implement a feature for storing (reading and writing)
the mac address there instead of the compiled in static one. I know, it's a
crazy idea but better than having things like this (as it actually is in
the dm9000 driver of my kernel tree):

1574 #if defined(CONFIG_ARCH_S3C2410)
1575         printk("Now use the MAC address: 1C:F7:1A:3D:89:E3\n");
1576         mac_src = "mini2440";
1577         ndev->dev_addr[0] = 0x1C;
1578         ndev->dev_addr[1] = 0xF7;
1579         ndev->dev_addr[2] = 0x1A;
1580         ndev->dev_addr[3] = 0x3D;
1581         ndev->dev_addr[4] = 0x89;
1582         ndev->dev_addr[5] = 0xE3;
1583 #else
1584         mac_src = "eeprom";
1585 
1586         /* try reading the node address from the attached EEPROM */
1587         for (i = 0; i < 6; i += 2)
1588                 dm9000_read_eeprom(db, i / 2, ndev->dev_addr+i);
1589 
1590         if (!is_valid_ether_addr(ndev->dev_addr) && pdata != NULL) {
1591                 mac_src = "platform data";
1592                 memcpy(ndev->dev_addr, pdata->dev_addr, 6);
1593         }
1594 
1595         if (!is_valid_ether_addr(ndev->dev_addr)) {
1596                 /* try reading from mac */
1597 
1598                 mac_src = "chip";
1599                 for (i = 0; i < 6; i++)
1600                         ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
1601         }
1602 
1603         if (!is_valid_ether_addr(ndev->dev_addr))
1604                 dev_warn(db->dev, "%s: Invalid ethernet MAC address.
Please "
1605                          "set using ifconfig\n", ndev->name);
1606 #endif

it depends WHERE you got your tree.

Just check
kernel/drivers/net/

is there a "dm9000.c_old"

If so then this is not a pure linux kernel.

Iv'e been back to 2.6.25 and this is not in there, I understand  what you
are trying to accomplish, but the only way you can be sure is by going back
to the vanilla linux and running a diff.

Because it could be that some of these hacks are actually stopping stuff
working once other mods are added.

it would also be good if you go and put all the other  removed files back,
so that we are working with a standard set of kernel files.

As for the MAC address, this should be done in :

some thing like:

#if defined(CONFIG_MAC)
..... split it out here

#else
        ndev->dev_addr[0] = 0x1C;
       ndev->dev_addr[1] = 0xF7;
        ndev->dev_addr[2] = 0x1A;
        ndev->dev_addr[3] = 0x3D;
        ndev->dev_addr[4] = 0x89;
        ndev->dev_addr[5] = 0xE3; 
#endif


then implement a menuconfig as a changeable constant that is then parsed
into the source code, allowing a central access for changes without having
to continually  DIFF the network files.
As it is , it is F***king stupid, requiring a "diff" of  dm9000.c for every
different manufacturers board, because we all know how they like to
fiddle.......



I'm still trying to get the  dm9k working:

 getting 

"IP-Config: No network devices available."

but it is showing up:

dm9000 Ethernet Driver, V1.31
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.

Just found why the network chip is not working, ---another dirty hack---

Any ideas what this is doing:


#if defined(CONFIG_ARCH_S3C2410)
  *((volatile unsigned int *)S3C2410_BWSCON) =
      (oldval_bwscon & ~(3<<16)) | S3C2410_BWSCON_DW4_16 |
S3C2410_BWSCON_WS4 | S3C2410_BWSCON_ST4;
  *((volatile unsigned int *)S3C2410_BANKCON4) = 0x1f7c;
#endif

(what values would it allocate?)

Nope!!!!!!

seems we may have a race condition...............

moving 1 line

&s3c_device_dm9k,

into "common-smdk.c" (where it should not be)
produces a working system:


dm9000 Ethernet Driver, V1.31
dm9000 dm9000: dm9000_probe()
dm9000 dm9000: resetting device
dm9000 dm9000: dm9000 revision 0x19
Now use the default MAC address: 08:90:90:90:90:90
eth0: dm9000a at c1804000,c1806004 IRQ 19 MAC: c0493934 (friendly-arm)
........
dm9000 dm9000: resetting device
eth0: link down
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
     device=eth0, addr=192.168.2.30, mask=255.255.255.0,
gw=255.255.255.255,
     host=192.168.2.30, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=192.168.2.101, rootpath=
Looking up port of RPC 100003/2 on 192.168.2.101
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Looking up port of RPC 100005/1 on 192.168.2.101
VFS: Mounted root (nfs filesystem).


but moving
&s3c_device_dm9k,

into the board files  mach-mini2440.c or  mach-smdk2440.c

just produces:

dm9000 Ethernet Driver, V1.31

This single change seems to have fixed all my issues related to the
networking.

Okay, but it seems to work for me with my kernel (and standard config file)
because I have installed Qtopia from here and got the konqueror working for
use with the internet :)

The outputs from above doesn't seem to stem from my kernel source tree
(because I have a different standard MAC address set) so I can't say what's
wrong.

Also I deleted some unused files because I wanted to get a smaller size of
the kernel source tree. Please say what features youre missing and I will
try to implement.

no the problem is not your files, 

The reason it does not match your "output" is that i have setup "friendly
arm" to do a NFS boot......

The os is stored on a server, after the kernel  boot of the FA it pulls 
the Android & the os from a central server.

It was done this way so we could implement mass testing in a factory
environment.

It was after we started to get a few boards together we found
"differences".

If I got plenty of time, I will try to get the 2.6.34 kernel working with
some adaptations. I messed up some stuff locally so was glad that I have
this git repository running on my server. Such a great comfortable
invention for development!

Hint: you can access and browse the git tree within your webbrowser (click
on tree to show up directories and files; if you click the "blob" link, you
can take a look into specific files). I also built in fancy syntax
highlighting for webbrowsers. Just inform me about what you would like to
improve or change so that I can make up the perfect mini2440 kernel. Its
not only useful for me but for all of us :)

I finally got the  android kernel running, just when it starts up, the  LCD
scrambles, but it is fine under linux.

I thin we need to look more at getting the latest android, rather than
chasing the latest kernel.

O.K ran into this with debug set:
after starting android....

it appears that the  "screen drivers" in s3c2410fb.c are being passed a
size of ZERO for the lcd's
Also the debug code in s3c2410fb.c is NOT displaying the correct values

init: cannot open '/initlogo.rle'
s3c2410fb: check_var(var=c0c4fda4, info=c048a800)
s3c2410fb: resolution or depth on default display 0x0 at 0 bpp
s3c2410fb: we were asked for 640x800 at 16 bpp
s3c2410fb: wrong resolution or depth 640x800 at 16 bpp

After applying the kernel fix here:

http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/965

finally android is being given the correct allocation from the kernel.

init: cannot open '/initlogo.rle'
s3c2410fb: check_var(var=c07c9da4, info=c048a800)
s3c2410fb: resolution and depth on default display 640x480 at 16 bpp
s3c2410fb: we were asked for 640x480 at 16 bpp
s3c2410fb: pixclk 40000, divisor is 4


this is VERY dependent on the memory allocation and what is being loaded,
as a result this bug will be  dependent on "memoryalloc"

I have pushed my completely new 2.6.34 Linux Kernel onto the git
repository. It should work fine because yesterday I already have compiled
it successfully. Also it brings loads of customizations and more!

You can use the default configuration by copying the config.save to
.config. If you have a cross-compiler-toolchain, type make and see if it
works. Please tell me if you have any problems while compiling and using
specific features.

Link: http://programmers-projects.de/project/mini2440-entwicklungsboard

Hello,

looks like link is broken - I am getting Page not found message

Huh? Really? It is working for me.
Try this please:
http://programmers-projects.de/en/project/mini2440-development-board

I have experimented a little bit with the usb upload tool. Now it has a
progress bar and it shows percentage done, upload speed, time elapsed, time
left and so on (I only have tested my programming skills a little bit) :)
It was complicated but now it's the best tool for uploading on mini2440
under linux I think ;)

http://git.programmers-projects.de/?p=mini2440-dev.git;a=tree;f=usb_uplo...

Maybe you can give me some advice to also improve the mini2440 config for
my 2.6.34 kernel because something is wrong but I can't find the mistake :/

Here is the output while booting my customized kernel (look the error at
the end):
load Image of Linux...Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34 (julien@Optiplex) (gcc version 4.4.4 (Debian 4.4.4-2)
) #1 PREEMPT Sun May 30 13:59:09 CEST 2010
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Mini2440 - ARM9 development board
ATAG_INITRD is deprecated; please update your bootloader.
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: noinitrd root=/dev/mtdblock3 init=/bin/bash
console=ttySAC0
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 59448k/59448k available, 6088k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc4800000 - 0xe0000000   ( 440 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0029000   ( 132 kB)
      .text : 0xc0029000 - 0xc04e2000   (4836 kB)
      .data : 0xc04fc000 - 0xc052b980   ( 191 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:85
irq: clearing subpending status 00000002
Console: colour dummy device 80x30
console [ttySAC0] enabled
Calibrating delay loop... 201.93 BogoMIPS (lpj=504832)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
NET: Registered protocol family 16
Mini2440 features string [0..9=LCD; t=Touchscreen; b=Backlight; c=Camera]:
mini2440=0tb
Mini2440 Buttons:
 [0: ENTER ] [1: UP    ] [2: POWER ]
 [3: LEFT  ] [4: DOWN  ] [5: RIGHT ]
Mini2440 LCD:
> 0: NL2432HC22 3.5" (0:240x320)
  1: TD035STED4 3.5" (1:240x320)
  2: AT056TN52  5.6" (2:640x480)
  3: AT070TN83  7.0" (3:800x480)
  4: VGA board       (4:1024x768)
S3C2440: Initialising architecture
S3C2440: IRQ Support
S3C24XX DMA Driver, Copyright 2003-2006 Simtec Electronics
DMA channel 0 at c4808000, irq 33
DMA channel 1 at c4808040, irq 34
DMA channel 2 at c4808080, irq 35
DMA channel 3 at c48080c0, irq 36
S3C244X: Clock Support, DVS off
s3c-adc s3c24xx-adc: attached adc driver
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
s3c-i2c s3c2440-i2c: slave address 0x10
s3c-i2c s3c2440-i2c: bus frequency set to 98 KHz
s3c-i2c s3c2440-i2c: i2c-0: S3C I2C adapter
Advanced Linux Sound Architecture Driver Version 1.0.22.1.
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Slow work thread pool: Starting up
Slow work thread pool: Ready
NTFS driver 2.1.29 [Flags: R/W].
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 116
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 40x29
fb0: s3c2410fb frame buffer device
s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
loop: module loaded
at24 0-0050: 1024 byte 24c08 EEPROM (writable)
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c24xx-nand s3c2440-nand: Tacls=3, 29ns Twrph0=7 69ns, Twrph1=3 29ns
s3c24xx-nand s3c2440-nand: NAND hardware ECC
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V
8-bit)
Creating 4 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "boot"
0x000000040000-0x000000060000 : "param"
0x000000060000-0x000000560000 : "kernel"
0x000000560000-0x000040000000 : "root"
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
dm9000 Ethernet Driver, V1.31
No MAC-adress set - using default: 1C:F7:1A:3D:89:E3
eth0: dm9000e at c4864300,c4868304 IRQ 51 MAC: 1c:f7:1a:3d:89:e3 (mini2440)
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: S3C24XX OHCI
usb usb1: Manufacturer: Linux 2.6.34 ohci_hcd
usb usb1: SerialNumber: s3c24xx
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
s3c2410_udc: debugfs dir creation failed -19
s3c2440-usbgadget s3c2440-usbgadget: S3C2440: increasing FIFO to 128 bytes
mice: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
s3c24xx-ts s3c2440-ts: driver attached, registering input device
input: S3C24XX TouchScreen as /devices/virtual/input/input1
input: buzzer as /devices/platform/buzzer/input/input2
S3C24XX RTC, (c) 2004,2006 Simtec Electronics
s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
i2c /dev entries driver
Linux video capture interface: v2.00
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
cpuidle: using governor ladder
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
s3c-sdi s3c2440-sdi: powered down.
s3c-sdi s3c2440-sdi: mmc0 - using pio, hw SDIO IRQ
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
No device for DAI UDA134X
No device for DAI s3c24xx-i2s
S3C24XX_UDA134X SoC Audio driver
UDA134X SoC Audio Codec
asoc: UDA134X <-> s3c24xx-i2s mapping ok
ALSA device list:
  #0: S3C24XX_UDA134X (UDA134X)
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
s3c2410-rtc s3c2410-rtc: setting system clock to 2010-05-30 18:21:15 UTC
(1275243675)
yaffs: dev is 32505859 name is "mtdblock3"
yaffs: passed flags ""
VFS: Mounted root (yaffs filesystem) on device 31:3.
devtmpfs: error mounting -2
Freeing init memory: 132K
Failed to execute /bin/bash.  Attempting defaults...
Kernel panic - not syncing: No init found.  Try passing init= option to
kernel. See Linux Documentation/init.txt for guidanc.
[<c002f920>] (unwind_backtrace+0x0/0xf0) from [<c03d4958>]
(panic+0x58/0xd8)
[<c03d4958>] (panic+0x58/0xd8) from [<c00295e4>] (init_post+0xac/0xd4)
[<c00295e4>] (init_post+0xac/0xd4) from [<c0008474>]
(kernel_init+0x118/0x158)
[<c0008474>] (kernel_init+0x118/0x158) from [<c002af84>]
(kernel_thread_exit+0x0/0x8)

your file system is not being mounted.

just a tip........

STOP messing about with these flashed storage for development, eventually
you will see bad blocks on the nand flash...... then you will be in real
trouble.

Instead use NFS, it is faster cleaner, and preserves your hardware.

Just for information: bad blocks are normal on NAND flash media. I have
scanned with u-boot and I have only see 4 bad blocks. So this isn't the
problem. Also I use a special flash filesystem called YAFFS2. This handles
these bad blocks, moves bad blocks (on non-bad-blocks) and makes it secure
against data loss...

It says "VFS: Mounted root (yaffs filesystem) on device 31:3" so I think
it's mounted cleanly. Why you think a NFS storage is a better alternative?
I don't think that it will be really faster because I already got it
working (with another, older customized kernel) and it was faster than I
thought. I think it's just a mistake in the configuration that I maybe have
overlooked.

Hi Jay,

I think bob wanted to explain that during development phase, you may have
to flash your filesystem image many times and this could damage your flash
chip as it is made to support a finite average number of write/erase
cycles.

Okay, then its clear. But why the kernel doesn't continue booting?
Supervivi is flashed, the Kernel is flashed and also the root filesystem
(embedded debian for arm) is flashed... The boot parameters (noinitrd
init=/bin/bash root=/dev/mtdblock3 console=ttySAC0 mini2440=1tb) seem to be
correct...

Can you please explain me, what's wrong?

Here are the last actual lines of debug info:
---------------------------------------------
TCP cubic registered
NET: Registered protocol family 17
s3c2410-rtc s3c2410-rtc: setting system clock to 2010-05-31 21:16:37 UTC
(1275340597)
yaffs: dev is 32505859 name is "mtdblock3"
yaffs: passed flags ""
usb 1-1: new full speed USB device using s3c2410-ohci and address 2
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
VFS: Mounted root (yaffs filesystem) on device 31:3.
Freeing init memory: 132K
Failed to execute /bin/bash.  Attempting defaults...
Kernel panic - not syncing: No init found.  Try passing init= option to
kernel. See Linux Documentation/init.txt for guidanc.
[<c002fa54>] (unwind_backtrace+0x0/0xf0) from [<c02cfa78>]
(panic+0x48/0xd0)
[<c02cfa78>] (panic+0x48/0xd0) from [<c00295cc>] (init_post+0xac/0xd4)
[<c00295cc>] (init_post+0xac/0xd4) from [<c0008474>]
(kernel_init+0x118/0x158)
[<c0008474>] (kernel_init+0x118/0x158) from [<c002af4c>]
(kernel_thread_exit+0x0/0x8)
-----------------------------------------------

After I got it with cross-compiling qt-4.6.2 I will try it first with the
2.6.32.2 kernel from here. I think at least this will work. But the error,
that the kernel can't continue booting, must be fixed.

try:

1. re flashing each area.
2. rolling back to your last set of working code.


Personally jay I would not try and chase the latest kernel, they have
stripped out certain items related to ADC

With kernel updates you are on a never ending  hamster wheel, you will get 
2.6.34 finished and working just in time for 2.6.35

It may be more productive to stabilize at a lower kernel , but to push on
with the latest android >2.0.

work on LCD /sound/ADC support/wiireless/bluetooth, and speed.


on the Nand-flash,  there really is a lot of background that you are not
aware of, nand -flash is not the bastion of reliability you think it is, 
the fact that you found 4 blocks > "1mb" of bad space does not take into
account  random read/write anomalies, and the general unreliability of nand
flash technology.

Yes, youre right, bob. The 2.6.33 Kernel worked just fine. I made a big
mistake by trying it with the 2.6.34 Kernel because I think that it is "to
new". And also the Version 2.6.35 of the Kernel has begun.

Also I know that NAND-flash media are not as reliable as they should be for
writing on the same areas more than 1 million times or so. But the kernel
needs to be on the OnBoard NAND as far as I know.

Thank you for the advices! I will try to give my best because I know that
it already has worked with the 2.6.33 Kernel so I will turn back to this
version. Also it will be faster, uses less RAM and will support most
bluetooth and wireless and all OnBoard-devices (including speaker driver,
status LEDs, nicier console outputs and better backlight support).

I don't know if Android is really better than a "normal", good styled
QT-GUI. As far as I know you can't use normal Linux-applications under
Android (because it uses a java virtual machine for its base). That's the
biggest disadvantage. So I have planned to get a nice QT-GUI working on top
of a debian rootfs with the 2.6.33 Kernel as its base.

Finally I got the "new" 2.6.33 kernel working with qpe :D

I have wondered that I have got it so optimized (with qpe started it only
uses 24MB RAM):
Mem: 24380K used, 36156K free, 0K shrd, 0K buff, 13164K cached

And wow, it's so damn fast :)
I like work and experiment with it. It's so cute this board ;)

yes , stick with 2.6.33 get all the bugs out and a stable system (watch
long term memory allocation)
then look at moving kernel later 

but just to be clear the android is an application that sits under linux.
If you want to "run" linux apps , just close down the  Android and revert
back to linux.(busybox is linux)

The advantage with android is the fact that you can program in semi-java ,
so there is a lot less work to be done on the GUI side, also there are no
license fees if you go commercial.
other than that if you use LGPL you MUST share all the code.

I find QT-GUI a real pain and not as good looking.
Then there is the licensing issue,  for  Hardware hackers and home brew
stuff I would say android, ideally it needs to be something the kiddies can
play with.

How is Qt's performance on this kernel?

The embedded Widget demo is a good starting place:
http://qt.nokia.com/files/embedded-widget-demos/qt-embedded-widgets-catalog

Use this video
http://www.youtube.com/watch?v=n62555v6m3Y
as a reference for speed, since it uses the "factory default" kernel

Maybe someone could make a benchmark test or something like that to compare
between my kernel (with standard configuration) and another one. But I will
never use another kernel than my own again. The best for me is that, what I
have made myself (because then I have a better overview).

Of course Jay. I ask about performance because I compiled buserror's
kernel, everything worked just fine, but Qt's performance was very slow
compared to the default kernel (in the video).

I need to investigate more why that happens, just wondering if the same
happens in your kernel... if it does, maybe friendly arm is doing some
hacking that we are not aware of in the framebuffer part

I don't think that it also is a problem in my kernel because it's just
working great. Also usb, buzzer, buttons, touchscreen and framebuffer
device. It also has more "style" at startup because it e.g. shows you the
button configuration (which button is for what) and the selected/all
available screen types (actually 5 are implemented - including external VGA
board).

But I am not so glad that I also had to "hack" the dm9000 driver (because I
havn't seen another possibility to get it working - but now it's working
good). I have tried to "hack" as few things as possible.

Great, unfortunately i don't have the time now to test your kernel and
check qt's performance now, i will do that test when my schedule here
allows it. For now, ill just use a modified filesystem of the factory
default system.

Yes, I think the factory default is good at the beginning. But the problem
is, that there is so much untidy stuff in it.

Hello all,

I'm using the latest 2.6.33 git from above and I am having trouble booting
off the SD card.  After mounting the ext3 partition it oopses hard:

mmcblk0: mmc0:7f37 SD04G 3.69 GiB 
 mmcblk0:
 p1 p2 p3
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p3): using internal journal
EXT3-fs (mmcblk0p3): recovery complete
EXT3-fs (mmcblk0p3): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:3.
Freeing init memory: 120K
Unable to handle kernel NULL pointer dereference at virtual address
00000018
pgd = c0004000
[00000018] *pgd=00000000
Internal error: Oops: 5 [#1]
last sysfs file: 
Modules linked in:
CPU: 0    Not tainted  (2.6.33-mini2440 #8)
PC is at __gpio_get_value+0x18/0x40
LR is at s3cmci_card_present+0x1c/0x38
pc : [<c01436c4>]    lr : [<c01c95f0>]    psr: 20000013
sp : c3981e40  ip : 00050151  fp : 00000000
r10: 00000000  r9 : 00000008  r8 : c3981f0c
r7 : 00000001  r6 : c3981ea0  r5 : c383e1a0  r4 : c0023070
r3 : c036c280  r2 : 00009f19  r1 : 0007752c  r0 : 00000000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 30004000  DAC: 00000017
Process mmcqd (pid: 724, stack limit = 0xc3980270)
Stack: (0xc3981e40 to 0xc3982000)
1e40: 00000000 c01c95f0 c383e000 c01ca4a0 c3981ea0 c383e000 00001000
c01bef0c
1e60: 0000049d 00000064 00000000 c383e800 00100100 00000000 c3981e78
c3981e78
1e80: c3978a24 c3953640 c397b000 00000001 c3978a24 c01c4aec 00000001
c0328590
1ea0: c3981eb4 c3981f0c c3981ee0 c3981e74 c01befa4 00000012 0036c710
00000000
1ec0: 00000000 00000000 00000000 000000b5 00000000 00000000 c3981f0c
c3981ea0
1ee0: 0000000c 00000000 00000000 00000000 00000000 00000000 0000049d
00000000
1f00: 00000000 00000000 c3981ea0 05f5e100 00000000 00000200 00000008
00000000
1f20: 00000200 00000000 c3981ee0 c3981ea0 00000001 c383e800 00000000
c012ec68
1f40: 00000002 c395d800 c39850a8 c3953640 00000111 c012f8dc c38ff840
00000000
1f60: 00000001 c3978a24 c38ff840 c3978a2c c3953640 c3978a24 c38ff840
c3953640
1f80: c01c56b8 c01251cc c38ff840 c3953640 c3978a24 c3980000 c3978a2c
c38ff840
1fa0: c38ff9a0 00000000 c3953640 c01c56b4 00000000 c3875e38 c3981fd4
c01c55cc
1fc0: c3978a24 00000000 00000000 c004c740 00000000 00000000 c3981fd8
c3981fd8
1fe0: 00000000 00000000 00000000 00000000 00000000 c0027e8c 00000000
00000000
[<c01436c4>] (__gpio_get_value+0x18/0x40) from [<c01c95f0>]
(s3cmci_card_present+0x1c/0x38)
[<c01c95f0>] (s3cmci_card_present+0x1c/0x38) from [<c01ca4a0>]
(s3cmci_request+0x28/0x8c)
[<c01ca4a0>] (s3cmci_request+0x28/0x8c) from [<c01bef0c>]
(mmc_wait_for_req+0x1e8/0x210)
[<c01bef0c>] (mmc_wait_for_req+0x1e8/0x210) from [<c01c4aec>]
(mmc_blk_issue_rq+0x1b0/0x4f8)
[<c01c4aec>] (mmc_blk_issue_rq+0x1b0/0x4f8) from [<c01c56b4>]
(mmc_queue_thread+0xe8/0xec)
[<c01c56b4>] (mmc_queue_thread+0xe8/0xec) from [<c004c740>]
(kthread+0x78/0x80)
[<c004c740>] (kthread+0x78/0x80) from [<c0027e8c>]
(kernel_thread_exit+0x0/0x8)
Code: e0010190 e59f3028 e1a02000 e7910003 (e5903018) 
---[ end trace ec56cfc268b2f5c2 ]---


Any ideas?

I'm sorry but my kernel only has in it's standard-configuration yaffs2 as
filesystem compiled in because the EXT filesystems are not so good for use
on flash devices (only for mechanical hard drives). But they (EXT2/3/4) are
available as modules so you need to install the modules correctly.

The Kernel is only tested for using it on the OnBoard-NAND. Maybe in a
newer version I will change the configuration a little bit if these
filesystems are essential for you.

hello,

  could you plz make a snapshot (in tar.gz) on your git site ? because I'm
behind a powerful firewall in the office. 


thanks

I added the snapshot link for downloading source trees as snapshots (in
tar.gz format) again.

Another problem is left: the MAX811 reset doesn't work properly I think.
Anyone has an idea how to solve this?

The Main Project Page can be found under
http://www.programmers-projects.de/projekt/mini2440-entwicklungsboard. The
releases of the project can be found under
http://www.programmers-projects.de/node/33/release. All german texts can be
translated by selecting a language in the GTranslate block on the right
side of each page.

Have you monitored the output of the MAX811 to determine this or ??

Do you mean that when you push the reset button, that it doesn't reset?

@davef: I meant that it doesn't reset properly if I want to restart via the
"shutdown -r now" command. So I think it is a problem in the kernel (or in
its configuration) that it can't trigger the reset through the MAX811 IC.
The reset button works without problems so it is no big problem but I would
like to solve it.

I don't see how any external control lines, except the manual reset pin,
would influence MAX811 behaviour. 

All it does is monitor the supply voltage and when it drops below a certain
level gives you a logic level that you can use to control the operation of
external devices.

Ah I see. But my kernel also needs a working software reset (not only
hardware reset). Can you please give me some advice to get it working?
Either there is missing some code for software reset in the kernel or the
configuration has a mistake in it.

If the kernel tries to reset the board, it only shows some backtrace
messages of memory addresses.

Who, me?  Sorry, wouldn't know where to start.  Well, actually I went to
familiar ground at AVRfreaks (8bit AVR) and did a search, as that topic
came up quite often and found:
***
Search this site for "software reset" and the like.

Short answer: Enable the watchdog timer and go into an eternal loop.
***
Somehow, me thinks there is more to it then this, but maybe it is a place
to start.

Good luck

Thank you. I think this could help :)

Touch screen is not working properly for the 7" LCD...

Also the MMC module crashes.


pgd = c3c08000
[f96f7ea4] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
last sysfs file:
/sys/devices/platform/s3c2440-sdi/mmc_host/mmc0/mmc0:0002/block/mmcblk0/mmcblk0p
1/dev
Modules linked in:
CPU: 0    Not tainted  (2.6.33-mini2440 #1)
pc : [<c01bb1e0>]    lr : [<c0274958>]    psr: 20000013
sp : c3b03e30  ip : 00000200  fp : c3b03e90
r10: c3b02000  r9 : c39b5ea4  r8 : 00000015
r7 : c3b03f54  r6 : c3b03e90  r5 : c383f1a0  r4 : c0023070
r3 : c045f940  r2 : 6f6e2073  r1 : 4e4a6159  r0 : 6f6e2073
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000317f  Table: 33c08000  DAC: 00000017
Process mmcqd (pid: 684, stack limit = 0xc3b02270)
Stack: (0xc3b03e30 to 0xc3b04000)
3e20:                                     c0023070 c0274958 c383f000
c0274f08
3e40: c3b03e90 c383f000 c3b03e54 c0268444 c3975640 00000000 c3b03e58
c3b03e58
3e60: c399bc00 c3975640 0000000d c026e5a4 ffffffff ffffffff ffffffff
00000001
3e80: ffffffff 00000000 c3b03ea4 ffffffff c3b03ea4 c3b03efc 00000000
c3b03e54
3ea0: c0268588 00000011 0000003f 00000000 00000000 00000000 00000000
000000b5
3ec0: 00000000 00000000 c3b03efc c3b03e90 0000000c 00000000 00000000
00000000
3ee0: 00000000 00000000 0000049d 00000000 00000000 00000000 00000000
05f5e100
3f00: 00000000 00000200 00000001 00000000 00000200 00000000 00000000
c3b03e90
3f20: 00000001 c383f800 c399e400 c39812c0 00000000 0000003c c399e400
c3975640
3f40: 000001b1 c3b00150 00000000 c01a3e9c 00000001 00000001 c383201c
c3b02000
3f60: c39812c0 c3b03f84 c3b02000 c39812c0 c3b03f84 00000000 c3975640
c01981b8
3f80: c3b02000 c3b02000 c39b5ea4 00000001 c3981420 00000000 c39812c0
c39b5eac
3fa0: c3975640 c026f0ac 00000000 c387fe20 c3b03fd4 c026eff4 c39b5ea4
00000000
3fc0: 00000000 00000000 00000000 c0054060 00000000 00000000 c3b03fd8
c3b03fd8
3fe0: 00000000 00000000 00000000 00000000 00000000 c0028fd0 ffffffff
ffffffff
Function entered at [<c01bb1e0>] from [<c0274958>]
Function entered at [<c0274958>] from [<c0274f08>]
Function entered at [<c0274f08>] from [<c0268444>]
Function entered at [<c0268444>] from [<c026e5a4>]
Function entered at [<c026e5a4>] from [<c026f0ac>]
Function entered at [<c026f0ac>] from [<c0054060>]
Function entered at [<c0054060>] from [<c0028fd0>]
Code: e92d4010 e59f302c e0801080 e1a02000 (e7930101)
---[ end trace 7292bec1c302ae59 ]---

@mobyfab:
Thank you for testing and the report. I think it is a problem in the
configuration of the kernel because there I used the IRQ instead of the
generic polling code when inserting a SD/MMC card. At the moment, just for
testing purposes.

In the next configuration update I will fix this besides some other
improvements.

What do you mean by "touchscreen isn't working properly"? Isn't it working
or is it working wrong (like the directions are wrong for up/down and/or
left/right - this could be fixed in userspace)?

Hi all

I am trying to do image processing using mini2440. I successfully
cross-compiled opencv and got 4 directories generated:
include
bin
share
lib

As i am running qtopia 2.2 rootfs on my board, i copied contents of
the above 4 directories to those in the board fs (for eg. bin to /bin
of board) Is this ok? will it work this way or do I need to make the
rootfs again? Also how to test whether the opencv is working or not?

PS. I'm actually a newbie

Tan

Hi,
great work Jay, I'm looking to port kernel 2.6.36, but ts don't work.
Let me know if you start from version 2.6.33 downloaded from www.kernel.org
vanilla ?
Where i can download your kernel 2.6.34 for mini2440 ?
Thanks

Well I already post patches to lkml to add new display types also ts
working for newest kernel but it's still not accepted (also without
comments). Also post patches to buserror which make 2.6.32-rc8 kernel
changes and he promise to push it to maintainer but still nothing. Hate
this way of working. Sad. Anyway you can find patches in lkml just search
for mini2440 ;)

marek

Hello!

After long time I decided to

My customized 2.6.33 linux kernel + usb upload tool for mini2440 is now
downloadable at ftp://gediam.de/projekte/mini2440/

It has different but easier compilation/installation process (see README
file). Please post any errors/difficulties and/or improvement suggestions
here.

If I have more time, I will see to get a newer kernel (2.6.38 or so)
running on mini2440 to also customize it a little bit. My goal is to get
the newest kernel (with newest YAFFS2 fs) running on mini2440 because of
improvements made in newer kernel versions. So my question also is if you
already got a kernel higher than version 2.6.33 running?

Thank you for any replies!

In the first sentence I meant "After long time I decided to move the kernel
to a new location." ;)

Jay,

Tried to download the kernel and it hung on the last few bytes.

If anyone has successfully downloaded it I would like to know before trying
again.

Cheers,
Dave

So it's a problem with the ftp connection? I successfully downloaded it a
few minutes ago...

Jay,

When I came back to the "almost" finished download an hour or two later I
noticed that it had completed.

Now, I just need to find a copy of mkimage.

Thanks,
Dave

Jay,

Recompiled for JFFS2 and it does run.

It takes quite a long time to get to the log-in prompt.  About 3-5 times
longer than the kernel I got from:

http://www.sendspace.com/file/6gdbp2
uImage

http://www.sendspace.com/file/zxfgyq
rootfs.tar.gz

Thanks to Ivan on this thread:
http://www.friendlyarm.net/forum/topic/2106

I have noticed that on a few of the recent uImages floating around, that
when you are using minicom you don't get any console messages until the
login prompt on the mini240 touchscreen.  If it is appropriate it would be
useful to see the messages flying past as it fires up the rootfs.

Didn't try your compilation process as I couldn't find your README file. 
After I got it working I had another look and found your comments in
INFORMATION.

Regards,
Dave

Hello,

what I have uploaded is an older backup of the modified kernel. The newest
one got lost so I only uploaded the one I could find.

The links are interesting. Because of there are many other good kernel
projects, I won't continue my kernel project. But the SQLite DBMS and
extended USB-Upload-Tool you can find on my website could be more
interesting.

Hi Joe,

I am a newbie to mini2440. Recently I have downloaded the kernel 2.6.33
from your repository. I have imported the T35 configuration file provided
with the mini2440 to your kernel. The images are successfully built and I
have downloaded into FLASH. But when I try to boot from NAND flash, it
gives 

load Image of Linux...Uncompressing Linux... done, booting the kernel.


and stucks. Can anyone guide me.

Thanks.

Hello Tarjun,

do you have given the right console in the boot parameters
(console=ttySAC0)? Where do you see this message? Is it on the Screen of
Mini2440 or in the RS-232 console?

Hi All,

I am facing one issue that DM9000AEP is not getting detected using Linux
2.6.32.2.

I am getting following Error when I am try boot the Kernel with Dm9000aep
driver.

dm9000 dm9000 read wrong id 0x46464646
dm9000 dm9000 wrong id 0x46464646
dm9000 dm9000 not found (-19)

Can anybody help me in solving this issue.

Base address or Address mapping of DM9000 is 
0x18000300-0x18000303 & 
0x18000304-0x18000307