Open IP Camera Forum

General => General Discussion => Topic started by: oliver on February 24, 2011, 09:41:02 pm

Title: Porting 2.4.20 upwards
Post by: oliver on February 24, 2011, 09:41:02 pm
Trying to give some input on the project too, I decided to look into the BSP supplied kernel.

After some looking at the Makefile for the linux-2.4.x kernel I noticed that it was supposed to be a 2.4.20 kernel with the uClinux uc0 patches applied.

Code: [Select]
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 20
EXTRAVERSION = -uc0

Easy I figured. Get a vanilla 2.4.20 kernel, apply the uClinux-2.4.20-uc0 diff and we should have the exact same kernel as supplied in the BSP! Let's call it the 2.4.20-uc0 kernel. Boy was I wrong. (Or I did something wrong :p)

Instead of just diff-ing the two dirs (certainly an option) I let svn do the hard work for me.

I quickly setup an svn repo, copied over the 2.4.20-uc0 kernel, svn add, svn commit and then copy over the linux-2.4.x kernel from the BSP. svn add *, svn commit and there we have it! only a handful of changes!

Apparently they used a different kernel combined with other stuffs!

Anyway, it's too late now to dig into what kernel they DID use, and just changed the makefile on it :) or .. who knows what.

Here's the diff for those interested.
http://schinagl.nl/~oliver/openipcam/nu745bsp.diff.bz2 (http://schinagl.nl/~oliver/openipcam/nu745bsp.diff.bz2)
Title: Re: Porting 2.4.20 upwards
Post by: admin on February 24, 2011, 11:08:06 pm
I think you need to take a look at the uClinux docs, specifically the porting ones.

We have an arch folder for our platform, which sets out layouts of memory etc, interrupts, gpio ports etc.
We have nuc_xxx char drivers and other platform drivers for the device specific stuff.

My issue is that i don't quite get the lds stuff as it currently is, so I can port to newer stuff.
Honestly though, I only spent a day or three on porting, as I felt it was better working on getting things running first, then looking at porting later.

It initially looked like porting would be a 1-2 day thing, but it is a bit more complex than you'd think, mostly due to the gcc and uclibc stuff being closely tied.

Lots of makefile changes etc when you change gcc versions, and then older stuff like the nuc char drivers break, and so on..

I should look at it again though, I know more than I did about it than last time I looked at it.

Lawrence.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on February 25, 2011, 07:08:19 am
It just bums me out a little that they took a standard 2.4.20-uc0 kernel and then not only added their own stuff, but updated certain bits and pieces on top of that, making it extremely hard to figure out, what exactly they added.

Ideally out of my little research, I popped out a nice diff, showing only the differences they made. But maybe there is hope, and they only added a few kernel/uclinux patches.

I'll search for more :)
Title: Re: Porting 2.4.20 upwards
Post by: oliver on February 27, 2011, 09:08:45 pm
Just a small update for today, did a lot of digging and found that the uClinux-2.4.20-uc0 kernel is more than just vanilla +patch. It apparently has the mtd patches applied as well, but no mention of that much. Problem was, my own tree has the newer mtd patches in, so made comparing a little more tedious.

Since I now know for almost 99% certain that the uClinux kernel is just that, I will use that as a base and see what things nuvaton changed and what not and try to compile a list of changes from that. With that in hand, upgrading to 2.4.37 and from there, in the far future, to 2.6.x might be possible.
Title: Re: Porting 2.4.20 upwards
Post by: admin on February 27, 2011, 11:40:53 pm
Might have a go tonight at it again.

What I did last time was take the BSP and the latest uClinux, download, unzip.

Then make a 3rd folder with the latest uClinux.
Copy over the drivers from the BSP (nuc_*)
Add the timer code from the init
Add the mach folders, and vendor folders.
Fix the inline asm to the way gcc 4 likes it (changed since 2.40.20)
Then got stuck on the lds bits, as thats changed, and I didn't quite understand that part.
Had it all compiling at least, but the linker was borking badly.

What toolchain are you going to use?

gcc 4.1x?

Should probably make another topic for this.  Can work on it together.
Makes life easier for the drivers anyway, as I don't need to patch it together..

2.6 is a lot more work, so lets aim for latest 2.4.x first.

Sound like a plan?
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 01, 2011, 08:05:45 am
Sounds like a plan indeed, though am working only on the kernel atm and I'm just a rookie, if anything.

I'll start a new threat, called 2.4 something :)
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 01, 2011, 08:12:41 am
I already split the topic.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 01, 2011, 09:09:51 am
This being mostly an exploration and learning project, I decided that the most important thing to do first, was figure out _exactly_ what was changed in comparison to the stock uClinux-2.4.20-uc0 kernel. This version is mentioned in the BSP supplied Makefile, so should be our starting point.

What i've done so far, take the vanilla 2.4.20 kernel, the 2.4.20-uc0 patch from uClinux and the uClinux-2.4.x kernel from the cvs, tagged 2.4.20-uc0 and see if there's any differences there to start from. Appearantly there's some OpenSSL headers added and the mtd patches. Applying the mtd patches to the 2.4.20 kernel +uc0 patches makes them pretty much identical. Not exactly as I just pulled the HEAD from the mtd cvs and used that.

Having been assured that 2.4.20-uc0 is really just standard stuff, I decided to move into more interesting stuff.

I created a quick SVN repository to experiment with (I should have used git, but I'm more familiar with SVN, i should have just used git, I know) and added the uClinux-2.4.20-uc0 kernel from cvs and commited that.

Code: [Select]
cvs -d:pserver:anonymous@cvs.uclinux.org:/var/cvs login
cvs -z3 -d:pserver:anonymous@cvs.uclinux.org:/var/cvs co -r uClinux-2_4_20-uc0 uClinux-2.4.x
For those that don't remember cvs commands, I surely didn't, having the -r at the end.

Once committed, I went to the BSP kernel, removed all those -x permissions on files and copied the tree over the uClinux tree.

You'd think there should be very limited changes, right? Wrong. Look at the 2MB compressed diff and see for yourself.
http://oliver.schinagl.nl/~oliver/openipcam/uClinux-2.4.20-uc0.diff.bz2 (http://oliver.schinagl.nl/~oliver/openipcam/uClinux-2.4.x-2.diff.bz2)

Firstly, they got uClinux-2.4.20-uc0 from somewhere, I'm strongly guessing the uClinux-dist, and added that to their own CVS tree. Not a huge biggie you'd think, except all the ID tags in files where updated to reflect that, so nearly every file was touched and changed with a version 1.1.1.1 cvs tag. Those files where manually filtered out over the course of a day and a half, by svn revert-ing the offending files, basically removing them from the copied tree.

Next, there where a bunch of files added, that don't seem to be from the uClinux or mtd projects, but I could be wrong. Haven't checked it out that closely yet. The reason for this statement? A block devices called 'doc' or Disk on Chip is included in the BSP, but also includes a closed source library. Also compressed copies? of the source of the DoC (sans the libosak closed library) is included.

Lastly, a bunch of files where dos-encoded, so those had to be dos2unix-ed to get a nice consistent patch.

Then, there are loads of random changes to random files that don't seem to be related to the W90N745 at all. They do actually match up to more up to date version of certain files in the kernel, so it looks very much like they took a more recent kernel, but left the old Makefile of 2.4.20-uc0 intact. Very confusing indeed. That will be my next step, slowly 'upgrading' the kernel to see what version they REALLY used.

BTW, The W90N745 is labeled as a NUVATON SoC, but a lot of the files related to the W90N745 appear to be copyrighted by Winbond. A lot of the BSP is actually non-GPL copywrited and the question arises whether this shouldn't be GPL marked? More later!
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 01, 2011, 10:43:56 am
So did the same to 2.4.20-uc1, first kernel 'up' and figured they'd use a few versions up. Or not ...

Let's look at the file http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/kernel/fork.c (http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/kernel/fork.c).

If we go back to 2.4.20-uc0, we notice that:
Code: [Select]
+#ifdef CONFIG_SYSCALLTIMER
+ p->curr_syscall = 0;
+#endif
does indeed not exist, and the old function dup_mmap happily exists in the 2.4.20-uc0 release. Going up one revision (not tagged by uc1 yet, from Thu Feb 20 05:18:24 2003 UTC (8 years ago) by gerg) the CONFIG_SYSCALLTIMER has been added and the dup_mmap function has been removed.
So this should be the kernel version to use? Well it's untagged, so how this specific version became to be, is unknown.
Going one revision up again, we already read in the change-set:
- kernel/fork.c: strip dead function dup_mmap()

So ... what did they do/think when they took the snapshot of uClinux?

I'll check if these mixed versions are happening all over the place, or this is just a fluke or something.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 01, 2011, 06:55:42 pm
I used the uClinux-2.4.20-uc1 and compared the BSP kernel with that. I noted the kernel version that seems to be what is used as base and noted any changes to those files.
Needless to say, it's quite messy :)

kernel
fork.c
uClinux-2.4.20-uc1 with the removal of dup_mmap from BSP kernel.

ksyms.c
uClinux-2.4.20-uc1 with the addition of ilookup from 2.4.24 vanilla (1.1.1.11) added

timer.c
uClinux-2.4.24 commented changes from uClinux-2.4.20-uc1. One specific W90N745 bit, not sure whether this is the right spot? Reverting to uClinux-2.4.20-uc1 with W90N745 changes in place.

sched.c
uClinux-2.4.20-uc1 + some unused DEBUG statement.

summary; remove the unused stuff, maybe relocate the W90N745 to maybe somewhere it belongs, but optional, should work any version theoretically.

scripts
mkdep.c
uClinux-2.4.20-uc0

summary: can be used from any version I'm guessing.

mmnommu
bootmem.c
uClinux-2.4.20-uc0 they changed void *ret; to void *ret=0; Appearantly an issue for the W90N745? Which is odd as it's actually assigned. Also a datatype was changed to volatile. Reverting it to the original.

page_alloc2.c
uClinux-2.4.20-uc1 +int flags; which is unused. reverting.

memory.c
uClinux-2.4.20-uc0 reverted to uClinux-2.4.20-uc1.

filemap.c
uClinux-2.4.20-uc0 keeping uClinux-2.4.20-uc1 should pose no problem.

slab.c
uClinux-2.4.20-uc1 added W90N745 specific (why here?). Strange thing is, they moved CHECK_PAGE(p) back to where it was in uClinux-2.4.20-uc0, reverting and keeping W90N745 additions.

page_alloc.c
uClinux-2.4.20-uc0 they patched the big-order allocations loop, but was patched also upstream differently/rewritten. Also they extended the BUG statement, but also that has been so far rewritten upstream. Reverting to uClinux-2.4.20-uc1 and hope the bug they fix isn't a huge showstopper.

vmscan.c
uClinux-2.4.20-uc0. going to leave it at 2.4.20-uc1

mmap.c
uClinux-2.4.20-uc1, some debug stuff was changed, but isn't used normally. Reverting.

Makefile
uClinux-2.4.20-uc0 uClinux-2.4.20-uc1 removes swap_state.o from mmnommu/Makefile causing other bits of mmnommu to miss swapper_space. Once the rest of the codebase is at 2.4.20-uc1 or higher, this should get fixed automatically, so leaving the uc0 version for now.

Documentation
intlat.txt
The intlat patch is from a 2.4.24+ version of the kernel, so it's likly this patch was applied to the 2.4.20-uc1 tree.

DocBook/librs.tmpl
Seems like lib reed-solomon-library was backported from the 2.6 kernels.

mtdnand.tmpl
Seems like atleast some parts of mtd where backported from the 2.6 kernels.

Configure.help
Some Disk on Chip patches where added, that uses a closed source libosak.a library. It's not in either uClinux or linus kernels so added there later. If it's not used by (any?) of the camera's dump this heap asap as it only adds cruft imo.
A few of the later (uClinux-2_4_24-uc0) PPTP, GRE, INFTL, Millenium Plus (disk on chip, again) stuff was added from a later version from uClinux. But strangly, not everything from the later version.

Summary: More informational really to track other weird patches. Reverting all docs to uClinux-2.4.20-uc1

ipc
no changes

init
main.c
uClinux-2.4.20-uc1 with changes. They added a few blank lines and added busybox as a default init next to /sbin/init etc. Cute, but no. Reverting to uClinux-2.4.20-uc1

lib
string.c
uClinux-2.4.20-uc1 with added parenthesis, reverted.

Config.in
uClinux-2.4.20-uc0 going to use uClinux-2.4.20-uc1 as that is our base tree for now. (Maybe uc0 was a better idea after all?

Makefile
uClinux-2.4.20-uc1 Addition of the reed-solomon lib

reed-solomon/
The reed-solomon lib from 2.6 but doesn't seem to be used. Removing Reed-solomon and reverting to uClinux-2.4.20-uc1.

net
atm/br2684.c
Removed some random header files; removed a list_empty check as per 2.6.24-uc0, but left other changes intact?!?

bluetooth/, ipv4, ipsec, sunrpc
lots of assorted changes, ignoring as porting can't possibly be related.

fs
exec.c
uClinux-2.4.20-uc1 (needs to be that version to match fork.c from above.

yaffs2-*/
external source, not in uClinux at all. I don't think it is used by the ipcam at all; thus can be reverted to uClinux-2.4.20-uc1

inode.c
uClinux-2.4.24-uc0 If it doesn't interfere with building or seriously crash immediately, the uClinux-2.4.20-uc1 should do fine.

binfmt_flat.c
uClinux-2.4.20-uc0 with some changes. I've reverted the file to 2.4.20-uc1 and added the winbond changes. Seems minor, but might be important? no clue why they modify the FS stuff though for winbond specifics ... No clue what caused me to draw that conclusion ... seems to be uClinux-2.4.20-uc0, going to be using 2.4.20-uc1

buffer.c
uClinux-2.4.20-uc1 some minor cosmetic changes with one specific mention, a do something while(); that was rewriten to be do { something } while(); Now to some curly bracers are distracting, and of course this change hasn't been done consequently throughout the changes, I do think having curly bracers around statements is a must. I bet this is just a leftover after having added extra code earlier, and was later removed. Shame really. Keeping the uClinux one of course :)

jffs2/
looks like the jffs2 stuff was updated out of the uClinux tree, can't find any Winbond reference luckly, might be wrong :), reverting it to uClinux-2.4.20-uc1

Config.in
This is an interesting one. Seems uClinux-2.4.20-uc1 pretty standardly, but they obvious jffs2 and yaffs2 additions are here too. Plain revert you'd think, but there is an actual mention for winbond MTD nand.
Code: [Select]
dep_bool 'YAFFS2 file system support' CONFIG_YAFFS_FS $CONFIG_MTD_NAND_WINBONDI don't think it's needed for anything ...

assorted files
uClinux-2.4.20-uc1 with extra lines and commented printk's. reverting all these to uClinux-2.4.20-uc1

drivers
scsi/
uClinux-2.4.20-uc1 with several W90N745 changes that make you wanna cry. For example, there are several assignments, which appearantly need to be | 0x800000'd. No idea why this is needed, but it is. They then go ahead, and put a #ifdef W90N745 around the statement in question. However in the else, they repeat the same assignment, and on the next line, do the assigment AGAIN! but then with the | 0x800000 added. Also they don't seem to like GFP_DMA for some reason, the W90N745 doesn't use it. So instead of making a small guard around that definition, they replace every statement with one that has GFP_DMA either set to 0 or removed. I don't understand half the changes they are doing and more importantly, do not understand whatsoever why they are in the scsi layer. Be it as it may, I cleaned the patch up as best I could, without risking 'injuring' any of the code, so some small silly-ness remains, and can be cleaned up for sure, once someone is able to test it at all. Ideally these changes go somewhere in the arch tree where it belongs?

gpio/
W90N745 gpio driver, should probably renamed. Location seems to be matching how 2.6 does it too, so not bad in that regard. Checked over on openwrt how they handle things, and in the 2.4 bits, gpio drivers seem to be mostly in the arch dir.

video/fbcon.c
Not sure where the changes are from. Some simple define changes and lots of printk's and other debug info.

char/tty_io.c
uClinux-2.4.20-uc0 with Winbond stuff added. They changed the default baudrate up from 38400 for some reason in the default setup, and later change it in the driver specific bit. Reverting to uClinux-2.4.20-uc1 with the original default, but with the winbond added stuff.

char/keyboard.c
uClinux-2.4.20-uc0 This one is very messy. They removed the GPL header and replaced it with a winbond specific header. Also they made this one 'version 1.00' even though it's basically the original keyboard.c. Some whitespace, ifdef guards later, the original keyboard.c emerges with winbond specifics added.
char/keyboard.h
uClinux-2.4.20-uc1 it seems, but from the the include/asm-i386/ directory. Cleaned it and moved it to where it belongs, asm-armnommu/arch-W90N745.

char/serial.c
uClinux-2.4.24-uc1 reverted to uClinux-2.4.20-uc1

char/w90n745_uart*
Copy of uClinux-2.4.20-uc0/drivers/char/serial.c and then some enabled/disabled changed stuff. All 3 files seem to be actually used, one seems to be the console, one the CTS/RTS pins, one appears to be some sound related serial port and all relate/compare to the PS/2 port. No clue what's really happening here, and why so many ports are needed, but it does seem quite apparent that you cannot use more than one of those serial ports at a time, as they all have the same function name to init. Probably combining and cleaning of this driver wouldn't hurt. I think 2.6 took a nicer generic approach.

char/
uClinux-2.4.20-uc1 generally, some different version-ed files from other kernel tree's, all unused by this board however so reverting those.

usb/serial/usbserial.c
uClinux-2.4.20-uc1 with 2 minor additions. Looking at this, you'd assume the W90N745 has an internal generic usb serial converter build in. very strange this one.

usb/storage/protocol.c
uClinux-2.4.20-uc1 with the same fixes as where required int he scsi stack. This time though, the double assignment can't work, as it's outside the loop, so it's a bug sort of. Removing the erroneous double assignment.

block/
uClinux-2.4.20-uc0 with extra mtd patches applied (to support the MSYS_DOC more). Reverting to uClinux-2.4.20-uc1 with winbond changes. I also checked how the W90N740 support was done, and noticed this was quite different. Really hope the original author can help with that, as for me, this is mostly all jibberish.

parport/
uClinux-2.4.24 first interesting thing to note; a plain copy of drivers/char/lp.c is made in this directory and linked together with parport_pc. Messy and ugly? Probably.
Then, the hd64465 parallel printer driver was added in the Makefile of uClinux-2.4.20-uc1, but the actual C file wasn't committed until 2.4.24. Going to add the C file from 2.4.24, and leave uc1 intakt.

sound/
uClinux-2.4.20-uc1 some random cvs commit variables changed, but that's it. clean addition almost of the sound driver.

drivers/mtd
This is a very messy mother. At first glance it's uClinux-2.4.20-uc1 but they manually applied the much later mtd patches. Since we want to find out the additions to the kernel from winbond, best bet is to compare the files to the mtd version and see the differences compared to that. Turns out, not only that, mtd back in the day required 3 or so Makefiles, and winbond decided to just mix them around, merge them about and create something similar, but completely different.

Having played with this for a few hours, mess was an understatement. It is very confusing, as it seems partially mixed. They use Makefile.24, which uClinux-2.4.20-uc1 uses too, but then all the code appears to be a cvs version from mtd. That being said, I find little to no changes, except one that strikes me as odd. They lowerd the MTD_BLOCK_MAJOR to 30 from 31 in mtd.h, and further down the line, change the hardcoded 31 to MTD_BLOCK_MAJOR. Not sure whats going on here. The mtd driver that uClinux-2.4.20-uc1 uses however, doesn't even use the that bit. Going to see if we can get this working with uClinux-2.4.20-uc1 still, otherwise, the mtd-cvs will be required.
nand/nand_base.c
mtd-cvs. Special mention for this file though, they seem to have used revision http://git.infradead.org/mtd-cvs.git/tree/b55100a60338d7c52f352355dc8144d9a7eb7a02 as far as I can tell. Funny fact, they seemed to have missed the commit a day later, as they manually circumvented the fix after. http://git.infradead.org/mtd-cvs.git/commitdiff/c6ee35059efe68f05365a84d09c276f1f52da46a There's 3 more fixes in the BSP version, that went into upstream a few weeks/months later. So keeping the mtd-cvs file with the BSP bugfixes. This file isn't actually used in the uClinux version (yet).

include/*mtd*/
uClinux-2.4.20-uc1 Because the mtd changes where so big, I had to also check the associated mtd-cvs header files. Turns out, they are using the stock uClinux-2.4.20-uc1 header files with 2 files slightly changed. Strange really how that works out.

others
Some random drivers are from 2.4.24, mostly that the hardware doesn't even have, so reverted all those to uClinux-2.4.20-uc1

mtd/
uClinux-2.4.20-uc1 There is actually a w90n745 specific file, leaving that for now, reverting unrelated stuff as they seem to use newer mtd then uClinux-2.4.20-uc1 supplied.


arch/
armnommu
uClinux-2.4.20-uc1 Makefile removed -msoft-float which is strange. It would give the impression the w90n745 doesn't have a mmu, but does have an FPU and thus should be able ot use hardware based floats. More likly, the msoft-float gcc option was giving them issues so they disabled it entirly. I'd imagine the kernel doesn't do a lot of float math anyway. config.in was more interesting. They stripped out all other archs and just left the w90n745's in place. They did it very sloppy however, leaving the now non-existing TI-DSC21 as default platform. Reverting to 2.4.20-uc1 and did my best to get the w90n745 specifics in.

armnommu/mm
uClinux-2.4.20-uc0 they they changed a few debug printk's and added some machine specifics to init.c. Reverting to uClinux-2.4.20-uc1 and keeping w90n745 changes. Going through proc-arm6,7.S gives the impression that they didn't use the release tagged uClinux-2.4.20-uc0 but 1 or 2 commits after that.

armnommu/boot/
uClinux-2.4.20-uc1 with w90n745 additions. keeping.

armnommu/tools/
uClinux-2.4.20-uc0 with w90n745 additions. Keeping additions, reverting to uClinux-2.4.20-uc1.

armnommu/kernel/
uClinux-2.4.20-uc1. time.c is interesting one, they wrote their own big version, then renamed it to time_old.c but isn't used anywhere. setup.c redefines how ROM works. They mount /dev/rom0 rw by default. Reverting this change, but it might, but unlikely, be required to get these boards working (#define CONFIG_CMDLINE "root=/dev/rom0 rw").


others/
reverted all other architectures back to uClinux-2.4.20-u1

include/
net/
Some of these seem to be uClinux-2.4.20-uc1 with a few lines backported from 2.4.22. Going to use uClinux-2.4.20-uc1.

linux/
uClinux-2.4.20-uc1; some changes for the winbond chips where very nastily modded into the standard drivers, should be really moved into their own files and be made more compliant. interrupt.h defines a new winbond interupt, but grepping for it, reveals no usage of it, so should/could be removed?

include/asm-armnommu/
memory.h put a #if0 guard around a bit in memory.h (For some reason other asm/.h files refer to these instead of the more public macros above.) However with the code as it currently is, it still depends on these macro's. Using uClinux-2.4.20-uc0 for now.

Most/all header files seem to be compatible with the changes so far, so leaving these as is for now. Going to do the headers last.
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 01, 2011, 11:05:27 pm
Suggest grab the older Winbond version of the BSP rather than the Nuvoton version.

Both are in the files section http://www.openipcam.com/files

In http://www.openipcam.com/files/BSP/

Nuvoton:

http://www.openipcam.com/files/BSP/NUC700%20Series%20MCU%20uCLinux%20BSP.zip (http://www.openipcam.com/files/BSP/NUC700%20Series%20MCU%20uCLinux%20BSP.zip)

Winbond:

http://www.openipcam.com/files/BSP/W90N745BSP05262008.tar.gz (http://www.openipcam.com/files/BSP/W90N745BSP05262008.tar.gz)

Winbond split off their chip fab into Nuvoton, its the same company (originally).

The older Winbond version is "cleaner" imho.

Its obvious that for the Nuvoton version, they did a search and replace for Winbond -> Nuvoton, but there are a few other changes.

I preferred working on the Winbond version anyway.
A bit offtopic, but the lady doing the work was Shirley Yu- clyu2@winbond.com.tw now CLYu2@nuvoton.com
Can always email her and ask. She still works there, as her name is on the ARM9 series BSP also in 2010. She should actually be in Shanghai (although possible she's in Taiwan), I could probably look up her details and give her a call. 

Marketing for China is 吴先生 (Mr Wu)
 jkwu@nuvoton.com
 http://www.nuvoton.com
 Office:  +886- 3-579 2715 (Taiwan)
 Mobile: +886- 936 222 228 (Taiwan)
 China : +86- 138 188 31678(Mainland number)

Quite possible she's in Shanghai though, probably likely close to my office as they have an office on yan an lu also (same as us), although more likely she's in the cao he jing one.

She's active locally - there is a post here from her in the local ourdev.cn forum.
http://www.ourdev.cn/bbs/bbs_content_all.jsp?bbs_sn=4331873

I guess I should also sign up and go to one of these just for the goodies, and the access to files and datasheets on their products ;)

Not that I haven't populated the download section already with some of that ->
http://www.openipcam.com/files/ARM7/ (http://www.openipcam.com/files/ARM7/)
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 02, 2011, 04:27:04 am
Suggest grab the older Winbond version of the BSP rather than the Nuvoton version.

Both are in the files section http://www.openipcam.com/files

In http://www.openipcam.com/files/BSP/

Nuvoton:

http://www.openipcam.com/files/BSP/NUC700%20Series%20MCU%20uCLinux%20BSP.zip (http://www.openipcam.com/files/BSP/NUC700%20Series%20MCU%20uCLinux%20BSP.zip)

Winbond:

http://www.openipcam.com/files/BSP/W90N745BSP05262008.tar.gz (http://www.openipcam.com/files/BSP/W90N745BSP05262008.tar.gz)
I actually used the W90N745 tar.gz! So that makes things easier I suppose :) I should compare the two actually and see what the one changes over the other ...

Winbond split off their chip fab into Nuvoton, its the same company (originally).

The older Winbond version is "cleaner" imho.

Its obvious that for the Nuvoton version, they did a search and replace for Winbond -> Nuvoton, but there are a few other changes.

I preferred working on the Winbond version anyway.
A bit offtopic, but the lady doing the work was Shirley Yu- clyu2@winbond.com.tw now CLYu2@nuvoton.com
Can always email her and ask. She still works there, as her name is on the ARM9 series BSP also in 2010. She should actually be in Shanghai (although possible she's in Taiwan), I could probably look up her details and give her a call. 

Marketing for China is 吴先生 (Mr Wu)
 jkwu@nuvoton.com
 http://www.nuvoton.com
 Office:  +886- 3-579 2715 (Taiwan)
 Mobile: +886- 936 222 228 (Taiwan)
 China : +86- 138 188 31678(Mainland number)

Quite possible she's in Shanghai though, probably likely close to my office as they have an office on yan an lu also (same as us), although more likely she's in the cao he jing one.

She's active locally - there is a post here from her in the local ourdev.cn forum.
http://www.ourdev.cn/bbs/bbs_content_all.jsp?bbs_sn=4331873

I guess I should also sign up and go to one of these just for the goodies, and the access to files and datasheets on their products ;)

Not that I haven't populated the download section already with some of that ->
http://www.openipcam.com/files/ARM7/ (http://www.openipcam.com/files/ARM7/)
I'm just dabbling here, finding the changes and documenting them is one thing, understanding them and knowing where I'm going with this, something completely else :) E.g. I'm just trying to help ;)

Later today, I'll start setting up a build environment from the Winbond BSP and see if I can build the kernel at all. After that, I'll try to decide whether to use a newer GCC first and port the code to work with the newer GCC, or probably easier, port the code to the new kernel using the old GCC, and then upgrade the toolchain.

Neither option sounds easier as there will be issues for both. First new gcc sounds better for some reason though :)
Title: Babysteps, babysteps.
Post by: oliver on March 02, 2011, 09:16:51 am
Uncompressed the arm_tools.tar.gz into /usr/local/arm_tools and chmod root:root to them. added the path via export PATH=$path:/usr/local/arm_tools/bin to my running shell and went to the uClinux-dist directory.

make clean, make dep, make ... and we got a kernel in linux-2.4.x. So the old 3.0 toolchain works. Tried to build just the kernel ... fail. A simple edit to the makefile (or setting the proper enviroment variables ;) fix that. ARCH := armnommu CROSS_COMPILE   = arm-elf- and we can run make clean, make dep and make! Sweet.

Now turning to our slightly modified kernel, e.g. uClinux-2.4.20-uc1 with a copied over BSP kerel fails slightly, but lets see if we can update this post later with a fix ;)

In the meantime, I'll readup about gentoo's crossdev toolchain installation howto and install the latest arm compiler :)

First minor update with the 2.4.20-uc1 kernel and gcc 3.0.0:
entry-armv.S:1078: Error: Internal_relocation (type 208) not fixed up (IMMEDIATE)
entry-armv.S:1129: Error: Internal_relocation (type 210) not fixed up (OFFSET_IMM)
entry-armv.S:1130: Error: Internal_relocation (type 210) not fixed up (OFFSET_IMM)

Since it works with the BSP version, it is strange. Especially since that after copying the file from the BSP, it still gives the same error ...

make[1]: Entering directory `/home/oliver/openipcam-oliver/test-kernel/arch/armnommu/kernel'
arm-elf-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/oliver/openipcam-oliver/test-kernel/include -DNO_MM -mapcs-32 -march=armv4 -mno-fpu   -c -o entry-armv.o entry-armv.S

Very strange, why does it work in the BSP directory, but not in my test-kernel directory, with them being identical ...

Appearantly it's related to the toolchain/kernel issues loosly related to constants.h. Re-doing make menuconfig (oldconfig bugs out after a while); make dep; make kinda fixes it, this is just noise now :)

apart from some minor issues (dependencies that got edited along the way from other versions) it's actually working now.

Ok, got the 'new' uClinux-2.4.20-uc1 with some changes etc compiled and everything with arm-elf-gcc-3.0. Since I don't own a camera yet ... Is there a brave soul out there to test it?
1a9e77f023ebae0026adaa514de4d8bf md5sum
http://schinagl.nl/~oliver/openipcam/linux.bin (http://schinagl.nl/~oliver/openipcam/linux.bin)
The diff to the original uClinux-2.4.20-uc1 with quite some cleanups:
http://schinagl.nl/~oliver/openipcam/uClinux-2.4.20-uc1.diff.bz2 (http://schinagl.nl/~oliver/openipcam/uClinux-2.4.20-uc1.diff.bz2)

I think I'll continue trying to get as many files back or close to the uClinux kernel, and remove certain other patches that where added to this tree without reason (DoC for example).
I'll look in the other topics which mtd/flash driver we are using with the camera. (If anybody could tell me straight off the bat, that would be even easier :)
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 03, 2011, 12:33:42 am
Usually I find a make clean; make dep; make will solve wierdness.

You can also look at the copious notes I've made on how to fix stuff on the uClinux forum on here.

Do you want me to setup an svn repo on here?  Might be easier if we are going to work on it.

Preferences for software?

svn or git?

Let me know, and I'll setup later today.  I should have time at work tonight to play.
DNS may take a while to propagate though if i add svn.openipcam.com or git.openipcam.com...

I also need to setup the opkg repo too..
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 03, 2011, 04:28:28 am
I know more about svn, but lets do it proper with git? Not sure if that will add extra complexness to our little thing, but may pay off in the end?

My repo atm is at svn://svn.schinagl.nl/openipcam-oliver but it has uncommitted bits.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 05, 2011, 06:58:11 am
As I keep editing my post up here, I noticed that the W90N745 does a lot of changes to the scsi, block and some other subsystems related to flash storage.

What flash driver is the W90N745 using? It's own and thus needs all the flash stuff enabled? I noticed that in the root Makefile, the flash stuff is actually uncommented. (Also, they choose an extremely bad name for their flash stuff, as 'flash' is pretty generic :)

I'm working on the drivers now, so once I've sorted that, just need the do include and then I should have a quite manageable patch!
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 10, 2011, 09:07:11 am
After having gone through half way of 'driver' I figured a build test was long overdue, and unfortunately it failed on so many levels ...

I've replaced the include and drivers dir with the BSP stuff, and started to work on fs instead. FS was from a much newer version of the mtd package. I'm trying to get it to build from the uClinux-2.4.20-uc1 release and once I've sorted out build issues (mostly my editing the Makefile and excluding things and what not, I'll start updating the post up again :)

P.S. one of the issues i'm having is with jffs2 not building. It's probably not needed, but took me a while to figure out. The older uClinux-2.4.20-uc1 fs/jffs2/dir.c requires defines which are in os-linux.h that have been removed ...
http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/fs/jffs2/Attic/os-linux.h shows it's up in the attic with a commit message that it's unnused. I guess nobody bothered to build the older version after it having been removed? Even with this file added and it included in nodelist.h, dir.c still won't build due to many many warning and errors, so what easier way to solve all this mess, then just to disable jffs2 support :) It wasn't used in the current kernel anyway, so no miss there, and hopefully, once 2.4.37 is running, it'll have proper updated jffs2 support.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 12, 2011, 05:25:34 am
I've completed another test binary.
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.0-uc1-01 8f08d560f128178dcd2f485dc97bf9f8

would really be helpful to know if it works at all, and how well.

This basically includes changes listed above:
most non-driver/include stuff reverted to uClinux-2.4.20-uc1; drivers and it's includes are still BSP. Sure that's the biggest part I guess, but having the rest be back to stock would be worth something I hope :)

I'll clean up my changes/reverts and will post a patch too.
http://schinagl.nl/~oliver/openipcam/001_basic.diff (http://schinagl.nl/~oliver/openipcam/001_basic.diff)

Here's a binary and a patch to get a -close to uClinux-2.4.20-uc1- experience. What IS needed from the BSP still:
include, drivers and arch subdirectories, the BSP's .config file and after compiling the image needs to be object-copied
Code: [Select]
arm-elf-objcopy -I elf32-littlearm -O binary linux linux.bin.

So to reproduce this binary, with the BSP included toolkit:
Get uClinux-2.4.20-uc1 and apply above patch, or, checkout my tree (revision 7) at svn://svn.schinagl.nl/openipcam-oliver/

Copy over above mentioned directories and the .config file;
make menuconfig && make dep && make clean && make
Binary should be with the same md5sum, right?

If anybody can test my binary or their own, It would mean some of this work actually payed off :D

edit: I forgot one important thing, include/asm-armnommu/flat.h needs to be reverted to the uClinux-2.4.20-uc1 version aswell. Should have mentioned that :)

Edit: As always, looking back at how you start something, you realize you where doing things wrong and silly. For some reason, I removed jffs2 support using these Makefiles. Shouldn't be needed at all, since we'd be using stock jffs2 which should build no matter what. Same goes for the mmnommu/Makefile.
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 14, 2011, 10:59:10 pm
Sorry I haven't replied, have been following what you're doing.


Will setup the GIT stuff later, got halfway last week, then the usual emergencies interrupted!.

Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 15, 2011, 09:22:11 am
No rush, my svn tree is working atm :) hopefully I can commit the changes to git later whilst keeping the log.

On a more update-ish note, I got the 2nd patch ready, that goes over the scsi layer. As mentioned above, some funky shit is going on here :) And it almost made me cry, on how this code was written. I don't know if it is normal to have changes in the actual generic scsi layer like they did, but so be it, for now.

A new binary to be tested, with the cleaned patch(es) and the new patch in itself:
http://schinagl.nl~/oliver/openipcam/02_scsi.diff (http://schinagl.nl~/oliver/openipcam/02_scsi.diff)

http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-02 (http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-02) 829295b35d09a5716b32023151ed8f92
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 15, 2011, 04:10:13 pm
Ok, finally setup Git.

The git repo has initially been populated from your files - take a look here for the gitweb version of your repo  ;D

http://git.openipcam.com/

Not sure how we merge this, but at least its up, and we can all start collaborating, eg once I give someone else write access...

I think it should be usable, but haven't really tested yet.  Its 4am here, and I do need to work tomorrow  :o

Let me know how badly or not I screwed up installing / setting up Git though.
If it doesn't work harangue me hehe.

Will probably do user access via Gitolite - https://github.com/sitaramc/gitolite/ (https://github.com/sitaramc/gitolite/)

Lawrence.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 16, 2011, 03:55:00 am
looks fine I think? It did take in the history! So that's good. I'll try later today/tomorrow to sync it and work from there, gonna tinker a little more with what i have atm. Looks like it's not that far from being done btw. The drivers subdir isn't that big of a mess it seems.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 16, 2011, 05:41:46 am
New build, now with the net bits patched and cleaned up too! Also gpio filtered out of the rest. Probably could do with better naming of files and won't even get into the quality of the patches, but even so ... here it is!

http://schinagl.nl/~oliver/openipcam/003_net.diff (http://schinagl.nl/~oliver/openipcam/003_net.diff) rev. 8:10
http://schinagl.nl/~oliver/openipcam/003_gpio.diff (http://schinagl.nl/~oliver/openipcam/003_gpio.diff) rev. 10:12
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u3 (http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u3) b76c0b1dead4a8a96c0a26caf577e04a

or checkout svn rev 12 for all patches so far.

P.S. this build actually has w90n745 wireless prism2 support (I enabled it to see if it would build at all, so a dmesg output would be interesting?)

edit: found something extremly interesting/usefull in one of the commit messages over at uClinux-2.x r 1.64
http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/drivers/char/Config.in?f=h;rev=1.64 (http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/drivers/char/Config.in?f=h;rev=1.64)
[qoute]this patch adds the Winbond W90N740 ARM7TDMI cpu to the latest 2.4
kernel, based on Winbond's original 2.4.20 port and Hugo Vincent's work.
[/qoute]
http://www.armtwister.com/download/w90n740-3.diff.gz (http://www.armtwister.com/download/w90n740-3.diff.gz)

So somone did the same work on the w90n740!

Once I got the patch for this one sorted; put it next to the w90n740 patch and take it from there!
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 16, 2011, 10:20:14 am
New build to be tested, new patch to be reviewed or whatever :)

Keyboard serial etc driver extracted and separated.

http://schinagl.nl/~oliver/openipcam/004_char.diff (http://schinagl.nl/~oliver/openipcam/004_char.diff) rev. 12:13
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u4 (http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u4) ae55c2904860fe26179a1a1fa7ae69bb

P.S. wireless is again disabled in this build, as we use the W90N745 config file again.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 16, 2011, 09:10:10 pm
New build to be tested, new patch to be reviewed or whatever :)

USB stuff extracted and separated.

http://schinagl.nl/~oliver/openipcam/005_usb.diff (http://schinagl.nl/~oliver/openipcam/005_usb.diff) rev. 13:18
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u5 (http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-u5) 55577e3d58b04dff104d3201a5a38ab5

P.S. removed the W9968* usb video driver as it is in some other form upstream in a later kernel.
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 16, 2011, 09:39:45 pm
updated local repo to match
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 18, 2011, 04:08:38 pm
Yet a nother new version that needs testing. This time, we have support for drivers/block/ that adds the winbond flash.

Now I wonder, is this support for the flash on our board only, or for winbond flash generically. You'd figure this be something very generic, like I could take any x86 board, use one of these flash chips, and use this code, right? So this isn't related to the W90N745 in the strictest sense?

In any case, a new binary to be tested and a new patch to go with it.

http://schinagl.nl/~oliver/openipcam/006_winbond_flash.diff (http://schinagl.nl/~oliver/openipcam/006_winbond_flash.diff)
http://schinagl.nl/~oliver/openipcam/linux.bin-uClinux-2.4.20-uc1-06 (http://schinagl.nl/~oliver/openipcam/linux.bin-uClinux-2.4.20-uc1-06) c468510d5d96df7fe0692eeda0f5eea1

I wonder if this all actually works at all ;)
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 18, 2011, 04:54:34 pm
Parallel port patch.

Something really interesting came up here. Besides adding a Winbond copyright above the notes above, they blatantly ignore notes from there.

* Note: Make no assumptions about hardware or architecture in this file!

Code: [Select]
if (port->irq != PARPORT_IRQ_NONE) {
#ifndef WINBOND_83977 //schen add 2004-2-17 09:49
parport_enable_irq (port);
#endif //schen add 2004-2-17 09:49
no_irq = 0;
}

Let use this example. The way I read this code, if port->irq is set to something other then the define PARPORT_IRQ_NONE try to enable the IRQ on the port. Instead, what I see here is, that this is still true, except when the parallel driver is for the WINBOND_83977. If that is the case, we know it doesn't have an interrupt (ok I assume that) and we don't want to enable it.

Wouldn't the proper solution have been to set port->irq = PARPORT_IRQ_NONE wherever this is supposed to
be initialized?

Then another example
Code: [Select]
static void __devinit detect_and_report_winbond (void)
{
#ifndef WINBOND_83977 //schen add 2004-2-9 11:42
if (verbose_probing)
printk(KERN_DEBUG "Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...\n");
winbond_check(0x3f0,0x87);
winbond_check(0x370,0x87);
winbond_check(0x2e ,0x87);
winbond_check(0x4e ,0x87);
winbond_check(0x3f0,0x86);
winbond_check2(0x250,0x88);
winbond_check2(0x250,0x89);
#else
show_parconfig_winbond(EFIR_REG, 0x87);
#endif
}
So either the check fails for this SoC/83977 chip (or combination thereof) or this was deemed faster/lazier? I'm sure they ran into some problems due to all the debug stuff that was enabled everywhere and maybe they removed the test to see if that's what was causing the fail? Seems unlikely however as there was a specific addition of the EFIR_REG earlier ...

I think this is just a sample of many cleanups needed for this SoC.

Best part is, the entire parallel port segment isn't even enabled in the kernel config.

Enabling it, does produce a binary, so in this image, it is actually enabled. Test and wheep!

I found that I had forgotten to add the gpio headers when adding the gpio module, so here is that bit.
http://schinagl.nl/~oliver/openipcam/007_gpio.diff (http://schinagl.nl/~oliver/openipcam/007_gpio.diff)
http://schinagl.nl/~oliver/openipcam/007_parport.diff (http://schinagl.nl/~oliver/openipcam/007_parport.diff)
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-07 (http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-07) fdc3e91f209ff82fbf0c083f7b52386d

P.S.S. Disclaimer: I will admit I have zero knowledge of the code involved and just going by what I see.
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 18, 2011, 11:42:12 pm
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.




Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 22, 2011, 08:49:55 am
Working on the mtd bit, I found one bit that bummed me out quite some. For some reason, they are changing the MTD_BLOCK_MAJOR from 31 to 30. This based on the struct mtd_blktrans_ops mtdblock_tr; I found no real information except this one page in chinese!

http://www.eet-china.com/ART_8800441120_617693_TA_4922dc54.HTM

Google translate makes me believe, that you jffs2 root support, the major number must be 30. since the major number in struct mtd_blktrans_ops mtdblock_tr seems (accidentally?) hardcoded?

A better translation would help. The odd thing however is, I don't think jffs2 support is currently being used at all, so I'd rather like to belive, if you enable jffs2 support, it will try to mount the flash mtd with major 31 as root, if it finds one, so if you change the major to 30, jffs2 won't try to mount it as such.

Any insight greatly appreciated :)
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 22, 2011, 08:54:15 am
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.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 31, 2011, 10:43:30 am
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/008_mtd.diff)
http://schinagl.nl/~oliver/openipcam/linux.bin-2.4.20-uc1-08 (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 :)
Title: Re: Porting 2.4.20 upwards
Post by: admin on March 31, 2011, 01:06:42 pm
I'll have more time for this in 2 weeks, when I'm back home from home again.

Want me to update git again?

Title: Re: Porting 2.4.20 upwards
Post by: oliver on March 31, 2011, 04:50:40 pm
yeah, whenever I post a diff, I usually run an svn diff -r before:after kinda thing, so that's always in svn.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on April 12, 2011, 10:41:15 am
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_usb.diff)
http://schinagl.nl/~oliver/openipcam/009_char.diff (http://schinagl.nl/~oliver/openipcam/009_char.diff)
http://schinagl.nl/~oliver/openipcam/009_parport.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 (http://schinagl.nl/~oliver/openipcam/009_upstreamfix.diff)

And finally, the architectural changes.
http://schinagl.nl/~oliver/openipcam/009_arch-w90n745.diff (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 (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 (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 :D

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.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on April 19, 2011, 07:41:59 am
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 (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.
Title: Re: Porting 2.4.20 upwards
Post by: oliver on April 19, 2011, 10:43:09 am
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?).

Quote
/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 (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 (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?
Title: Re: Porting 2.4.20 upwards
Post by: oliver on April 27, 2011, 08:27:48 am
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 (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
Title: Re: Porting 2.4.20 upwards
Post by: admin on May 12, 2011, 11:51:12 pm
PM me.
Title: Re: Porting 2.4.20 upwards
Post by: celem on May 23, 2011, 04:13:56 pm
What is the status of this effort? Where is the repository that reflects the final product?
Title: Re: Porting 2.4.20 upwards
Post by: oliver on May 24, 2011, 03:03:32 am
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/ (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.
Title: Re: Porting 2.4.20 upwards
Post by: celem on May 24, 2011, 11:53:27 am
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!

Title: Re: Porting 2.4.20 upwards
Post by: oliver on May 24, 2011, 02:16:14 pm
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 (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 :D More exitingly though, if it is 12, gcc 3.4.6 and all the changes nearly work!
Title: Re: Porting 2.4.20 upwards
Post by: oliver on June 10, 2011, 02:43:09 pm
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 :)
Title: Re: Porting 2.4.20 upwards
Post by: admin on June 18, 2011, 10:24:35 pm
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.