Re-organized the forum to more cleanly delineate the development section, as the end user support side appears to have taken a life of its own!

Author Topic: Porting 2.4.20 upwards  (Read 20773 times)

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]

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.
« Last Edit: March 14, 2011, 07:18:45 am by oliver »

  • No avatar
  • *****
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.


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 :)

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.

  • No avatar
  • *****
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?

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 :)

  • No avatar
  • *****
March 01, 2011, 08:12:41 am
I already split the topic.

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 login
cvs -z3 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.

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 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!
« Last Edit: March 14, 2011, 07:19:23 am by oliver »

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

If we go back to 2.4.20-uc0, we notice that:
Code: [Select]
+ p->curr_syscall = 0;
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.

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 :)

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

uClinux-2.4.20-uc1 with the addition of ilookup from 2.4.24 vanilla ( added

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.

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.


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

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.

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

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

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

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.

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.

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

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

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.

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.

Seems like lib reed-solomon-library was backported from the 2.6 kernels.

Seems like atleast some parts of mtd where backported from the 2.6 kernels.
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

no changes

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

uClinux-2.4.20-uc1 with added parenthesis, reverted.
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?

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

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.

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.

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

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

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.

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

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 :)

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
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

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?

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.

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

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.

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.
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.

uClinux-2.4.24-uc1 reverted to uClinux-2.4.20-uc1

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.

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.

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.

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.

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.

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.

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

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.
mtd-cvs. Special mention for this file though, they seem to have used revision 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. 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).

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.

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

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.

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. 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.

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.

uClinux-2.4.20-uc1 with w90n745 additions. keeping.

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

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").

reverted all other architectures back to uClinux-2.4.20-u1

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.

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?

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.
« Last Edit: April 12, 2011, 03:33:30 am by oliver »

  • No avatar
  • *****
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




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- now
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)
 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 forum.

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 ->

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



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- now
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)
 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 forum.

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 ->
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 :)

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
The diff to the original uClinux-2.4.20-uc1 with quite some cleanups:

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 :)
« Last Edit: March 14, 2011, 07:20:17 am by oliver »

  • No avatar
  • *****
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 or

I also need to setup the opkg repo too..

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:// but it has uncommitted bits.