Skip to contentSkip to conversation

SGI VISWS support for 2.5

RFC PATCH In review Andrey Panin 3 participants 5 messages Jun 20, 2002 – Jun 21, 2002

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 SGI VISWS support for 2.5

Hi all,

attached patch is a forward port of latest (2.4.17) visws patch from sourceforge. It's mostly trivial textual merge. Builds, unteseted.

Please take a look at it.

Signature · 2 lines
Andrey Panin            | Embedded systems software engineer
[email protected]        | PGP key: wwwkeys.eu.pgp.net
#1 lore raw

Thanks for doing this. I'm checking it out now on a 320.

Jesse

Quoted 10 lines · Andrey Panin

Hi all,

attached patch is a forward port of latest (2.4.17) visws patch from sourceforge. It's mostly trivial textual merge. Builds, unteseted.

Please take a look at it.

Signature · 2 lines
Andrey Panin            | Embedded systems software engineer
[email protected]        | PGP key: wwwkeys.eu.pgp.net
#2 lore raw
In reply to Andrey Panin

yeah!! I plan to port over the visw framebuffer soon. Care to try it out once your stuff gets merged into 2.5.X.

. ---

   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\

\___)=(___/

Quoted 10 lines · Andrey Panin

Hi all,

attached patch is a forward port of latest (2.4.17) visws patch from sourceforge. It's mostly trivial textual merge. Builds, unteseted.

Please take a look at it.

--
Andrey Panin | Embedded systems software engineer
[email protected] | PGP key: wwwkeys.eu.pgp.net

#3 lore raw
In reply to Andrey Panin

I gave it a go on a 320 that I have here and it gets into start_kernel somewhere, but I don't get any output on the serial console. If you'd like to get it into 2.5, maybe we should clean it up a little first (as well as get it working)?

When I ported the last patch forward to 2.4.17, I noticed that there were quite a few parts that could use some work. Looking through the patch, it seems like the head.S stuff could be done in a better way, maybe a seperate head.S for machines that start in protected mode? Then again, maybe the boot loader should just be changed? The interrupt handler code also needs to be fixed up.

I haven't looked at the patch to seperate out i386 subarches yet, but maybe that would be a good first step to abstracting away some of the visws setup code?

Jesse

Quoted 10 lines · Andrey Panin

Hi all,

attached patch is a forward port of latest (2.4.17) visws patch from sourceforge. It's mostly trivial textual merge. Builds, unteseted.

Please take a look at it.

Signature · 2 lines
Andrey Panin            | Embedded systems software engineer
[email protected]        | PGP key: wwwkeys.eu.pgp.net
#4 lore raw
Quoted 4 lines · Jesse Barnes

I gave it a go on a 320 that I have here and it gets into start_kernel somewhere, but I don't get any output on the serial console. If you'd like to get it into 2.5, maybe we should clean it up a little first (as well as get it working)?

We definetely need to make it working and cleanup is a good thing too, but i dont have a VISWS (right now) so i'm limited to trivial mergework.

Quoted 3 lines

When I ported the last patch forward to 2.4.17, I noticed that there were quite a few parts that could use some work. Looking through the patch, it seems like the head.S stuff could be done in a better way,

As far as i understand VISWS fragment in the head.S does 3 thing:
1) fills page tables;
2) twiddle some bits in cr3.
3) loads gdt and idt;
My small brain can't understand why we must do 1 and 3 so early. BTW looks like we are filling page tables many times (for every CPU). And why we move stext and _stext for VISWS ?
These are great mysteries ...

Quoted 1 line

maybe a seperate head.S for machines that start in protected mode?

I'm doubtfull, does it worth the effort ?

Quoted 5 lines

Then again, maybe the boot loader should just be changed? The interrupt handler code also needs to be fixed up.
I haven't looked at the patch to seperate out i386 subarches yet, but maybe that would be a good first step to abstracting away some of the visws setup code?

2.5 with James's arch-split patch has most of VISWS code separated already. The only big trouble that remains is VISWS hacks in parse_mem_cmdline() function.

Also when 2.5 will realy use platform driver to support reboot, halt and power off, it will be possible to split VISWS code from process.c.

Signature · 2 lines
Andrey Panin            | Embedded systems software engineer
[email protected]        | PGP key: wwwkeys.eu.pgp.net