Porting 2.4.20 upwards

We don't have parallel i/o, and won't use it in this, so no real benefit fixing it up.

From the datasheet:

The W90N745 provides one USB 1.1 host controller, one USB 1.1 device controller, one AC97/I2S controller, one 2-channel GDMA, four independent UARTs, one watchdog timer, two 24-bit timers with 8-bit pre-scale, up to 31 programmable I/O ports, PS2 keyboard controller and an advanced interrupt controller. The external bus interface (EBI) controller provides for SDRAM, ROM/SRAM, flash memory and I/O devices. The system manager includes an internal 32-bit system bus arbiter and a PLL clock controller.

Yeah I figured as much, but who knows will find this page with this chip, as a print-server maybe? Who knows, just thought I mention it for completeness sake I did a quick search on the chip they support with the driver, and couldn't find directly if it is supported by linux at the moment. I wouldn't be surprised if it worked just fine?

The whole registry list thing you posted up there, is somewhat magic to me, no clue on what to do with the information. (Except that I can see what devices are supported etc, I do 'see' what it is.

Sorry for being quiet for such a long time, been busy with my new house, work etc, and of course, the MTD bit of kernel.

I mentioned it above, I complained before, but what a mess. So here is what I've done. Searched for more or less the exact revision they used from the mtd-cvs tree over on infradead (c6ee35059efe68f05365a84d09c276f1f52da46a from what I found) and copied over the mtd bits from the BSP. Copmared those, found out what they changed and to my best of abilities ported those over to uClinux-2.4.20's mtd. Tricky, but possible. Don't know if it's functional however They did backport a few changes, or fixed them themselves? From later releases of mtd. Had to rename and backport a few changes from later mtd versions to uClinux-2.4.20 also, as the flash mapping driver from the w90n745 required it. The driver does however use a future feature that I didn't find any other reference too (map->owner) so the driver sets it, but it doesn't get used elsewhere, which is why it's commented (for now, un-comment later I suppose).

http://schinagl.nl/~oliver/openipcam/008_mtd.diff
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-08 1da825a9a01af1c5bfe729eb974250cd

Having this one tested by someone with an actually supported camera, should prove extremely interesting. If this would work (even if unstably) it would still work nonetheless.

This patch actually concludes the driver bit. Only left now are the include, and arch directories. I'm betting, that there aren't much/any changes in include anymore, so gonna tackle this next

I'll keep you all posted

I'll have more time for this in 2 weeks, when I'm back home from home again.

Want me to update git again?

yeah, whenever I post a diff, I usually run an svn diff -r before:after kinda thing, so that's always in svn.

After spending literally my entire work day solving this, I did manage to get the last-ish patch out!

So what caused me to be busy all day?

Code: [Select]

init/main.o: In function `start_kernel':
init/main.o(.text.init+0x444): undefined reference to `__virt_to_phys'
arch/armnommu/kernel/kernel.o: In function `request_standard_resources':
arch/armnommu/kernel/kernel.o(.text.init+0x914): undefined reference to `__virt_to_bus'
arch/armnommu/kernel/kernel.o(.text.init+0x92c): undefined reference to `__virt_to_bus'

What turns out to be maybe relatively easy, wasn't so easy to find, in part two 2 changes upstream.

include/asm-armnommu/memory.h enabled a #if 0 guard around the above mentioned __virt_to_phys routines, claiming the other macro's should be used instead. In conjunction with that change, include/asm-armnommu/page.h removed the reference to memory.h (Whilst using the __virt_to_phys macro's itself). So far, in the 2.4 tree, I haven't found a workaround, but we'll see when we use a later kernel version.

So removing the guard, and re-adding the include, solves all headaches. I'll finish sorting out the diff's and build a nice kernel for the final patch-set!

So here it is, the final patch-set, with the architecture specific changes from the BSP.

As mentioned before, I had forgotten some include files that where supposed to go with other settings.

http://schinagl.nl/~oliver/openipcam/009_usb.diff
http://schinagl.nl/~oliver/openipcam/009_char.diff
http://schinagl.nl/~oliver/openipcam/009_parport.diff

Then something needed or else the whole thing won't build.
http://schinagl.nl/~oliver/openipcam/009_upstreamfix.diff

And finally, the architectural changes.
http://schinagl.nl/~oliver/openipcam/009_arch-w90n745.diff

Lots of patches, Makes one wonder if the produced binary actually still works.

Some minor changes from the top of my head, are to the armnommu/config.in file, I think it should make slightly more sense now, useless/silly includes etc reverted etc.

http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-09 86c610206880a6ae0c9981f844a3f60b

and a final image, which is without the mtdblock stuff I mentioned in build 08

http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-10 11b3d5c1c18bd965a99738c23e4eb331

This binary should be possible to achieve with uClinux-2.4.20-uc1 +all diffs!

So with all these diffs and changes, the cleansed uncompressed patch is 1.2MB; 176KB bzip2 compressed in size! I'd call that a big win

Compare that to the previous 14MB, 2.1MB bzip2 compressed diff we had before, it quickly becomes very obvious that there was a lot of useless junk that should have been there. Assuming it works.

The only odd thing, is that I don't get yet, is that the linux binary, went up in size. From 846KB for the BSP kernel, to 943KB for our 'patched' kernel. Might be the uC1 changes or ... something.

So what am I going to do now? Get a 2.4.20 vanilla kernel, patch it up to uc1 and apply these patches. Probably in a different order and hopefully combine the right ones, creating more sensible patches

After that, compare them to the latest nuvoton BSP and try and get in touch with winbond/nuvoton and have hem signoff the patch as GPL, maing it possible to integrate it into <anything>?

Back to work for now

P.S. I won't update svn anymore, everything is committed afaik, and I might use the patches from the ~public_html bit anyway. So once git is update; i'll pull from that and use that exclusively.

New small-update.

Fixed-up the diff files. Some dos2unix was necessary throughout the tree, committed those and fixed the diff-files with that.

Fixed path-ing in diff files (I wasn't consistent with the path from where I ran the diff ...

Also created a new interesting build. Not very exciting really, but interesting nevertheless. I took a vanilla 2.4.20 kernel, patched it with the uclinux-2.4.20-uc1 patch (interestingly, this includes the uc0 stuff too) and patched all my seperate patches in. It built cleanly and should work exactly the same as the previous build. md5sums where different somehow though.

http://schinagl.nl/~oliver/openipcam/linux.bin-uclinux-2.4.20-uc1-11 6d1aecd8ab2687a81d07db11a3a01769

This build should be the most interesting as to how well it works, as this one should be reproducable using the patches.

So the next step in this epic endeavor is of course, porting to 2.4.37 using gcc4. Problem is of course, chicken and egg.

gcc4 or atleast, 3.4.6 won't build 2.4.20. Will gcc3.0 (the one supplied with the BSP) build 2.4.32 however (the latest kernel that has uclinux patches up on cvs)?

To make things worse (for me), I have 2 servers that I can compile on. Both 64bit, one intel based, one AMD based. For some reason however, the AMD one does not want to run the arm-elf-gcc binary. 32bit emulation is set the same on both kernels, and I think I have the compatibility libraries installed, or do I? Come to think of it, I have no 32bit applications on the AMD server, and cecking for the compatibility libraries, there are none! Alas after installing "app-emulation/emul-linux-x86-compat" "emul-linux-x86-baselibs" still no go. Why it works on my intel box and not amd box, baffles me.

Back to business, gcc-3.0 from the BSP does apparently almost build 2.4.32 using the 'winbond' (e.g. w90n740) architecture (the dsc21 failed, but may be broken?).

/usr/local/arm_tools/bin/arm-elf-ld.real: Error: _udivsi3.o uses hard floating point, whereas linux uses soft floating point

Unfortunately using mrproper and then rebuild doesn't fix this one, as it did with a post elsewhere on this forum.

Since gcc-3.3.4 is included with the BSP also, let's now check, what does build with the BSP supplied gcc-3.3.4! Well not uClinux-2.4.20-uc1. Luckly, Lawrance already did most of the hard work in the 'compiler tips #2' post as he tried the same, so let's see what we can do with that!

And a day later, a lot of help from that post and got it working.

http://schinagl.nl/~oliver/012_gcc_3.3.4_support.diff

These are the patches from uClinux that add 3.3.4 support. It does seem however, that arm_tool_3.3.4 isn't built with soft-float support whereas the arm_tools_3.0 is, pure speculation at this point however, the original BSP did remove -msoft-float from the  Makefile too.

http://schinagl.nl/~oliver/openipcam/linux-2.4.20-uc1-12 a3ebc2aa68a93516687679e653de03db

This should be the same kernel as the previous one, but built with gcc_3.3.4 and the according patches.

Next up, gcc_3.3.6. One thing that I still am not sure of, Does the armv7 have an FPU or not? We remove 'msoft-float' and remove 'mfo-fpu' bits are compiled with hard-fp, we saw errors as such in the compile tips #2 ...

I'm sure some code uses floats, even in the armnommu bit, so knowing how it is compiled and what we need is important?

With having uClinux-2.4.20-uc1 +W90N745 running using GCC 3.4.6 I suppose a git-svn-pull would be needed, so that I can start the new work (2.4.31 or so)!

http://schinag.nl/~oliver/openipcam/012_gcc_3.4.6_support.diff

Also I really need to purchase a cam with the W90N745 chipset so I can actually test code myselfsome


P.S. I can't clone the repo

git://git.openipcam.com/openipcam-oliver/.git is the repo i'm using (would have expected openipcam-oliver.git tbh but in any case, using that url fails, and doing it over http it complains.

Cloning into openipcam-oliver...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
is the error over http

Cloning into openipcam-oliver...
git.openipcam.com[0: 66.135.39.220]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
when cloning over git

PM me.

What is the status of this effort? Where is the repository that reflects the final product?

What is the status of this effort? Where is the repository that reflects the final product?

I have sporadically followed your progress in "Porting 2.4.20 upwards". A couple of questions: (1) Did you ever get anyone to test your build? - or did you get a camera to test yourself? If not, I would be willing to give it a try. Likewise, I would like to be able to create my own local build, but I admit, I am confused about were your repository is right now and what would be the best way to proceed.

I thought I documented progress quite well But here a short summary.

All of the following code is untested. I did only compile checks basically. Since there are no structural changes, those should be plenty. Bugs may exist in certain bits, as they have been backported/downgraded to match the uClinux version.

Ideally, we'd all be using the git sources Lawrence is supplying us with. I do have my own repository still, and if you really want it, it's somewhere in this thread, but ideally, we'd keep development in one spot. That said, it badly needs to be updated again

I do have the patches that could be considered the end result here: http://schinagl.nl/~oliver/openipcam/

Each patch-set (identified by the leading number) matches one of the kernels (by the end-number). Don't try to apply these patchsets to a vanilla 2.4.20-uC1 kernel, as they are based off the BSP kernel. The whole set however can be applied to vanilla 2.4.20-uC1 and should result in a working binary.

Patchset 10 and 11 are missing, as they aren't patches really. 10 Removed some stuff from the tree and 11 is vanilla-2.4.20-uC1 with the patches applied. So if 11 works, all my work was awesome. If not, which is more likly, the intermediate patches need to be checkt to see which one causes the camera to no longer boot. 01 should really work however, since there's hardly any change. The 12 patches yield gcc-3.3.4 and 3.4.6 support, or should as I used gentoo's gcc's version, so not sure if they applied patches that break things. (Gentoo makes cross-development much easier and cleaner imo).

And that is it.

Personally, I've been playing with a virtual machine, based on KVM instead of vmware, running a bare gentoo system including the cross-dev stuff and the 3 or 4 gcc versions usable.

Next up, getting a newer version of the uClinux sources working, but that's proving to be a little more difficult then I first thought. I can't get 2.4.37 to build at all, but haven't put any effort into that at all.

Oliver,
Bad news. I loaded your version linux.bin-2.4.20-uc1-11 linux into my wansview NC541/W Ip-camera and it fails with a kernel panic. Here is the console output:

Code: [Select]

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

bootloader > ls
Image: 0 name:BOOT INFO base:0x7F010000 size:0x00000048 exec:0x7F010000 -f
Image: 7 name:linux.zip base:0x7F020000 size:0x00078F80 exec:0x00008000 -acxz
Image: 6 name:romfs.img base:0x7F0E0000 size:0x0010C400 exec:0x7F0E0000 -a
Image: 8 name:webui.bin base:0x7F200000 size:0x000A6F80 exec:0x7F200000 -a

bootloader > boot

Rebooting the system ...
                        �


W90P745 Boot Loader [ Version 1.1 $Revision: 1 $ ] Rebuilt on May 11 2010
Memory Size is 0x1000000 Bytes, Flash Size is 0x400000 Bytes
Board designed by Winbond
Hardware support provided at Winbond
Copyright (c) Winbond Limited 2001 - 2006. All rights reserved.
Boot Loader Configuration:

MAC Address         : 00:B8:00:00:68:D2
IP Address          : 192.168.0.178
DHCP Client         : Enabled
CACHE               : Enabled
BL buffer base      : 0x00300000
BL buffer size      : 0x00100000
Baud Rate           : 115200
USB Interface       : Enabled
Serial Number       : 0xFFFFFFFF


For help on the available commands type 'h'

Press ESC to enter debug mode ......
Cache enabled!
Processing image 1 ...
Processing image 2 ...
Processing image 3 ...
Processing image 4 ...
Processing image 5 ...
Processing image 6 ...
Processing image 7 ...
Unzip image 7 ...
Executing image 7 ...
Linux version 2.4.20-uc1 (oliver@7of9) (gcc version 3.0) #2 Tue Apr 19 13:28:28 CEST 2011
Processor: Winbond W90N745 revision 1
Architecture: W90N745
On node 0 totalpages: 1792
zone(0): 0 pages.
zone(1): 1792 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/rom0
Calibrating delay loop... 39.83 BogoMIPS
Memory: 7MB = 7MB total
Memory: 5880KB available (944K code, 177K data, 44K init)
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
Winbond W90N745 Serial driver version 1.0 (2005-08-15) with no serial options enabled
ttyS00 at 0xfff80000 (irq = 9) is a W90N745
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 700000-AB1AABFF [VIRTUAL 700000-AB1AABFF] (RO)
RAMDISK driver initialized: 16 RAM disks of 1024K size 1024 blocksize
loop: loaded (max 8 devices)
CFI command set 0002 will be used
01 eth0 initial ok!
which:0
SCSI subsystem driver Revision: 1.00
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
Creating 2 MTD partitions on "POS-TAX flash device":
0x00000000-0x00300000 : "images 3M"
0x00300000-0x00400000 : "user 1M"
Can't allocate major number 31 for Memory Technology Devices.
usb.c: registered new driver hub
add a static ohci host controller device
: USB OHCI at membase 0xfff05000, IRQ 15
hc_alloc_ohci
usb-ohci.c: AMD756 erratum 4 workaround
hc_reset
usb.c: new USB bus registered, assigned bus number 1
Unhandled fault: alignment exception (93) at 0x00000001
fault-common.c(97): start_code=0x7f000168, start_stack=0xa8)
Internal error: Oops: 0
CPU: 0
pc : [<0002bc00>]    lr : [<00103b24>]    Not tainted
sp : 0015debc  ip : 8014e460  fp : 0015ded4
r10: 00000087  r9 : 0010b800  r8 : 00000005
r7 : 00000000  r6 : a0000013  r5 : 8014dc00  r4 : 00000000
r3 : 01731980  r2 : a0000093  r1 : 01603968  r0 : 0012e018
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: 0
Process swapper (pid: 1, stackpage=0015d000)
Stack:
0015dea0:                            00103b24  0002bc00 a0000093 ffffffff 00000000
0015dec0: 8014dc00 8014e460 0015df08 0015ded8  000907e4 0002bbcc 00000000 0000012c
0015dee0: 0000356c 00010000 00000000 8014dc00  0000000f 000120fc 0015df70 0015df30
0015df00: 0015df0c 000914d0 00090738 00000001  00000000 00000000 00000000 0000012c
0015df20: 8014dc00 0015df50 0015df34 00092298  00091490 00096858 8014dc00 0016f800
0015df40: 0000000f 0015df68 0015df54 00099088  00092284 00000000 0016f800 0015df98
0015df60: 0015df6c 00010000 00098f6c 0016f800  00003531 00000087 000120fc fff05000
0015df80: fff05000 0000005c 0012b4e8 0015dfb8  0015df9c 000100d8 0000fee0 000122ec
0015dfa0: 000122fc 0010b804 00078f80 0015dfc8  0015dfbc 00010148 0001009c 0015dfe0
0015dfc0: 0015dfcc 000086b4 00010140 001142a0  0012b4e8 0015dffc 0015dfe4 0001304c
0015dfe0: 000086a8 001142a0 0012b4e8 0010b804  00000000 0015e000 00016848 0001304c
Backtrace:
Function entered at [<0002bbbc>] from [<000907e4>]
 r6 = 8014E460  r5 = 8014DC00  r4 = 00000000
Function entered at [<00090728>] from [<000914d0>]
 r8 = 0015DF70  r7 = 000120FC  r6 = 0000000F  r5 = 8014DC00
 r4 = 00000000
Function entered at [<00091480>] from [<00092298>]
 r4 = 8014DC00
Function entered at [<00092274>] from [<00099088>]
 r6 = 0000000F  r5 = 0016F800  r4 = 8014DC00
Function entered at [<00098f5c>] from [<00010000>]
 r5 = 0016F800  r4 = 00000000
Function entered at [<0000fed0>] from [<000100d8>]
 r8 = 0012B4E8  r7 = 0000005C  r6 = FFF05000  r5 = FFF05000
 r4 = 000120FC
Function entered at [<0001008c>] from [<00010148>]
 r7 = 00078F80  r6 = 0010B804  r5 = 000122FC  r4 = 000122EC
Function entered at [<00010130>] from [<000086b4>]
Function entered at [<00008698>] from [<0001304c>]
 r5 = 0012B4E8  r4 = 001142A0
Function entered at [<0001303c>] from [<00016848>]
 r6 = 0010B804  r5 = 0012B4E8  r4 = 001142A0
Code: e59e3000 e0813003 (e5934004) e7905001 e594000c
Kernel panic: Attempted to kill init!



It does boot quite far actually. The BSP is mostly drivers, and those seem to load okay.

That kernel panic can be a lot of things. I assume it's uClinux-2.4.20-uc1-12 based on the '31' error about the mtd stuff. Which may be the cause of it all.

Unhandled fault: alignment exception (93) at 0x00000001


Seems to be the culprit, not sure what that means, but did find it elsewhere:

https://gsoc.xelerance.com/issues/1166


So interesting is when/what causes the segfault (compiler version difference, kernel memory offset etc) and at what patch version.

So was googling a bit more about that error, and from my understanding, it might be related to the binflat format or something like that. The binflat bits where reverted to. So unlikly the bug is there, it's default stuff now.

http://www.mail-archive.com/rtnet-users@lists.sourceforge.net/msg00414.html makes one think it's a driver though.

All in all, this needs to be checked out, patch by patch. Should be a small or minor thing I hope More exitingly though, if it is 12, gcc 3.4.6 and all the changes nearly work!

I made the transition to git myself now. I've set up a repository http://git.schinagl.nl/openipcam/ though haven't checked out permissions etc and not running a git daemon yet. So the cgit frontend may be useless, who knows Be very carefull to not click any of the big items, such as 2.4.20 vanilla import or 2.4.31 import. It'll generate a 270MB xml file, I have plenty room in my cache for it, but your browser might grind to a halt

Have updated the local repo with your one, and removed the old one.
Had to add a static entry in my hosts file to see your server, as would resolve locally, but not on this box.

Some quick notes - should probably want to set the default ROMFS location 7F0E0000 in your config, rather than at 700000
eg

ROMFS_BASE=7F0E0000

Just so we're all on the same page haha, (programmers joke).


Also put the 2.6 Kernel stuff on there too.