News:

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 18228 times)

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!

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.
« Last Edit: March 10, 2011, 09:53:16 am by oliver »

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

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.
« Last Edit: April 13, 2011, 07:30:09 am by oliver »

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


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/linux.bin-2.4.20-uc1-02 829295b35d09a5716b32023151ed8f92

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

Lawrence.
« Last Edit: March 15, 2011, 04:35:21 pm by admin »

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.

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 rev. 8:10
http://schinagl.nl/~oliver/openipcam/003_gpio.diff rev. 10:12
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
[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

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!
« Last Edit: March 16, 2011, 06:34:33 am by oliver »

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 rev. 12:13
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.

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 rev. 13:18
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.

  • No avatar
  • *****
March 16, 2011, 09:39:45 pm
updated local repo to match

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/linux.bin-uClinux-2.4.20-uc1-06 c468510d5d96df7fe0692eeda0f5eea1

I wonder if this all actually works at all ;)

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_parport.diff
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.
« Last Edit: March 18, 2011, 07:28:09 pm by oliver »

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





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 :)
« Last Edit: March 22, 2011, 09:07:08 am by oliver »