Wazzup! ,

I was pondering about how to get good dual screen setup with various
hardware.

Found some hints here..

http://forums.xaprief.com/showthread.php?s=&threadid=2313

Any input in how we could control this from Amithlon ?

Best regards
--
Smith & Wesson: The Original Point And Click Interface

Hi,
I have compiled a c program with both linux (m68k-amigaos-gcc) and
amithlon.
When I run program with run_elf (1.6) a window popup tell me:

           Run_elf
UNDEFINED SYMBOL: _CallLib68k

or something like this :-P

On linux:
CC=m68k-amigaos-gcc
./configure
make

On amithlon:
i686be-amithlon-gcc -r -noixemul prog.c

What's wrong?
Regards

----- Original Message -----
From: vmconline
To: amithlondev@yahoogroups.com
Sent: Monday, September 22, 2003 3:05 PM
Subject: [amithlondev] What happened to Gary Colville?


>Hiho there,

>anyone any idea whats up with him? i have send now several
>emails to him over the last few months without any response.

>Best regards

>VMC Harald Frank, Developer and Founder of Amithlon

Hi Harald, I sent him an email awhile ago about porting mplayer to Amithlon.
He did reply saying he was very busy and didn't have time at the moment....

Darren

Hiho there,

anyone any idea whats up with him? i have send now several
emails to him over the last few months without any response.

Best regards

VMC Harald Frank, Developer and Founder of Amithlon

> Hello,
>
> I know several guys here made kernels for different hardware.
> I also know that you have a problem in putting the stuff
> online because of the GPL and the file size.
>
> If you're interested in making these kernels available for
> all users, then contact me.
>
> There is enough webspace available to hold your kernels.

Im happy to provide mirror =D

Hello,

I know several guys here made kernels for different hardware. I also know that
you have a problem in putting the stuff online because of the GPL and the file
size.

If you're interested in making these kernels available for all users, then
contact me.

There is enough webspace available to hold your kernels.

  also weg und so na denn und schuesss !!!

                            Guido


Author of:

AmithlonUSB, AmithlonTV, AView, AFind, BoulderDaesh, GuideCheck, GuideFormat,
Execute64, SiedlerBoot, R(equest), DVBControl, MCControl, Simplecat, AvailCPU,
VBRControl, TrackDisplayClock, SnoopRouter, Meridian, MMKeyboard, ParKeyboard,
WheelMouseSupport, ...

Wazzup! vmconline

On  1.Aug.2003, you wrote:

> --- In amithlondev@yahoogroups.com, TigerGutt <tigergutt@b...> wrote:
>> Wazzup! ,
>>
>> I attched an snip from quesions I ask Hollywood dev.
>>
>>>> I run an highend Amithlon machine that I like to play with.
>>>> I also have an VGA->S-VHS converter and an TV card in my pc.
>>>>
>>>> Do you have any users currently using such hardware ?
>>>
>>> Yes, I have users using Amithlon and Hollywood runs fine EXCEPT
>>> audio: There seems to be a problem with the Amithlon AHI driver
>>> which returns FALSE where it should return TRUE and therefore
>>> makes Hollywood to abort. I have contacted the driver author at
>>> katodev about it but didn't get a reply because Amithlon is
>>> discontinued. So I'll be doing a work around by do not checking
>>> for a correct return value. This is planned for Hollywood 1.5 Rev 2.
>>
>> Any way we could work this out ?
>>
>> Anybody with reach of katodev to try change their mind ?
>>
>> Best regards
>
> Hello,
>
> read my former posting in Amithlon ml about this issue first please.
>
> Best regards,

Will do.

With regards
--
>... File not found. Should I fake it? (Y/N)

--- In amithlondev@yahoogroups.com, TigerGutt <tigergutt@b...> wrote:
> Wazzup! ,
>
> I attched an snip from quesions I ask Hollywood dev.
>
> > >I run an highend Amithlon machine that I like to play with.
> > >I also have an VGA->S-VHS converter and an TV card in my pc.
> > >
> > >Do you have any users currently using such hardware ?
> >
> > Yes, I have users using Amithlon and Hollywood runs fine EXCEPT
> > audio: There seems to be a problem with the Amithlon AHI driver
> > which returns FALSE where it should return TRUE and therefore
> > makes Hollywood to abort. I have contacted the driver author at
> > katodev about it but didn't get a reply because Amithlon is
> > discontinued. So I'll be doing a work around by do not checking
> > for a correct return value. This is planned for Hollywood 1.5 Rev 2.
>
> Any way we could work this out ?
>
> Anybody with reach of katodev to try change their mind ?
>
> Best regards

Hello,

read my former posting in Amithlon ml about this issue first please.

Best regards,

VMC Harald Frank, Developer and Founder of Amithlon

Wazzup! ,

I attched an snip from quesions I ask Hollywood dev.

> >I run an highend Amithlon machine that I like to play with.
> >I also have an VGA->S-VHS converter and an TV card in my pc.
> >
> >Do you have any users currently using such hardware ?
>
> Yes, I have users using Amithlon and Hollywood runs fine EXCEPT
> audio: There seems to be a problem with the Amithlon AHI driver
> which returns FALSE where it should return TRUE and therefore
> makes Hollywood to abort. I have contacted the driver author at
> katodev about it but didn't get a reply because Amithlon is
> discontinued. So I'll be doing a work around by do not checking
> for a correct return value. This is planned for Hollywood 1.5 Rev 2.

Any way we could work this out ?

Anybody with reach of katodev to try change their mind ?

Best regards
--
WinErr 547: LPT1 not found... Use backup... PENCIL & PAPER.

--- In amithlondev@yahoogroups.com, Bernie Meyer <amithlon@a...> wrote:
> >could be 0 location...but the same kernel works on an athlon
> >system. So I'm think it has to be a cpu instruction/flag that is
> >causing it that the Eden doesn't like. I'm still reading kernel
> >source trying to find out exacly what happens....
>
> The "works on the athlon" thing is easy --- Have a look in "mem_init()",
> you will find
>
>         if (boot_cpu_data.wp_works_ok < 0)
>                 test_wp_bit();
>
> and earlier in the bootup, in pagetable_init(), you find
>
>                         if (cpu_has_pse) {
>                                 unsigned long __pe;
>
>                                 set_in_cr4(X86_CR4_PSE);
>                                 boot_cpu_data.wp_works_ok = 1;
>
> Which means that on any CPU with "PSE", the test routine is never even
> called. The C3 is the only x86 processor currently in production I am
> aware of which lacks PSE, so it's no surprise that this problem doesn't
> show up on other systems.
>
> Bernie

I'm thinking the PSE flag is important to Amithlon seeing like you said most
cpu's
have it and the C3 doesn't and if you build the kernel with i386 settings you
miss
some of the paging features of the pentium classic cpu features and such. I've
tried
i386 settings and other cpu's and also some kernel boot flags like
mem=nopentium.
also tried setting the kernel config to read the bios directly ect...

But it still leads me to something that has been hacked into the amithlon
kernel.

a) 2.4.18bf2 debian works , 2.4.2x-ac? works under gentoo
b) so it leads me to believe it is a memory allocation problem.
c) or something in [big,small]ird.gz's  ./linuxrc could be causing is. I have
objdump'd
and grep'd for cmov instructions and it is clean. but there could be something
else.
Seeing it only bombs after it mounts and sets all the default variables.

Bernie, Sorry to sound like I'm repeating this but thats the only conclusion
I've come
to. I'm real thankful for all the insight you have given me. I still want to get
this thing
working but it is out of my abilities now.

Paul (pkp)

>could be 0 location...but the same kernel works on an athlon
>system. So I'm think it has to be a cpu instruction/flag that is
>causing it that the Eden doesn't like. I'm still reading kernel
>source trying to find out exacly what happens....

The "works on the athlon" thing is easy --- Have a look in "mem_init()",
you will find

         if (boot_cpu_data.wp_works_ok < 0)
                 test_wp_bit();

and earlier in the bootup, in pagetable_init(), you find

                         if (cpu_has_pse) {
                                 unsigned long __pe;

                                 set_in_cr4(X86_CR4_PSE);
                                 boot_cpu_data.wp_works_ok = 1;

Which means that on any CPU with "PSE", the test routine is never even
called. The C3 is the only x86 processor currently in production I am
aware of which lacks PSE, so it's no surprise that this problem doesn't
show up on other systems.

Bernie

--- In amithlondev@yahoogroups.com, "pkp700" <pkp@t...> wrote:
> --- In amithlondev@yahoogroups.com, Bernie Meyer <amithlon@a...> wrote:
> > >        *pte = mk_pte_phys(0, PAGE_READONLY);
> > >        local_flush_tlb();
> > >        boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);
> > >
> > >/*      *pte = old_pte; */
> > >^^^^^^^^^^^^^^^^^^^^^^^^^^  causes the panic....
> >
> > I can see why that might happen. I can't look at kernel source right
> > now (the machine that has kernel sources needs rebooting :), but I
> > suspect that the first line up there tries to create a page table entry
> > for the page starting at address 0.
> > In Amithlon, that page (which is probably available to the kernel in
> > all "normal" linux situations) is reserved for use by the emulator;
> > As far as the kernel is concerned, that memory doesn't even exist.
> >
> > So that might cause all sorts of interesting problems --- and judging
> > from *where* things crash, I suspect "pte" ends ub being NULL. The top
> > line above does _not_ crash because at that point, address 0 is still
> > both readable and writable. Then the page table cache gets flushed, and
> > address 0 is suddenly read-only.... so assigning to "*pte" fails.
> >
> > This is also what I suspect causes your crash-after-boot problem.
> > Commenting out the line you did will probably leave the page at address 0
> > in a read-only state, so once Amithlon gets all started up and ready
> > to go, it tries to clear the emulated Amiga's memory (which starts,
> > not surprisingly, at address 0 :), and the very first memory write
> > bombs out with an uncorrectable segmentation violation.
> >
> > Couple of points come to mind:
> >
> >   a) Q: Why doesn't the same thing happen on other machines?
> >      A: Because all other current CPUs support "PSE" (whatever that is :),
> >         and if so, the kernel never calls this test routine
> >
> >   b) Q: What can you do about it?
> >      A: Replace the whole function with a dummy, as shown beloe
> >
> >          void __init test_wp_bit(void)
> >          {
> >              /* Any processor capable of running Amithlon *does* support
> >                 the WP bit even in supervisor mode */
> >              boot_cpu_data.wp_works_ok = 1;
> >          }
> >
> >
> no joy Bernie....boots and starts going through the [small,big]ird.gz then
gets to
the
> setting of the video mode to vesa and then reboots. :(
>
> Paul (pkp)

I'm just confused with this whole thing. a regular kernel that has the excact
same
code works, but the exact same code on the amithlon kernel does not. So it must
be
amithlon allocating memory in a specific location. I wish I could debug the
kernel
before it does the reboot to see what is exactly causing the reboot. like you
said it
could be 0 location...but the same kernel works on an athlon system. So I'm
think it
has to be a cpu instruction/flag that is causing it that the Eden doesn't like.
I'm still
reading kernel source trying to find out exacly what happens....

:(
argh!

Paul (pkp)

If anyone has a via mini-itx board that uses the new nemehiah chip please let me
know as I would be interested to see if the kernel works on that cpu seeing how
it has
a slightly diffferent core.


>
>  Give that a shot, and let me know how it goes.
> >
> > Hope it helps,
> >
> >    Bernie

--- In amithlondev@yahoogroups.com, Bernie Meyer <amithlon@a...> wrote:
> >        *pte = mk_pte_phys(0, PAGE_READONLY);
> >        local_flush_tlb();
> >        boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);
> >
> >/*      *pte = old_pte; */
> >^^^^^^^^^^^^^^^^^^^^^^^^^^  causes the panic....
>
> I can see why that might happen. I can't look at kernel source right
> now (the machine that has kernel sources needs rebooting :), but I
> suspect that the first line up there tries to create a page table entry
> for the page starting at address 0.
> In Amithlon, that page (which is probably available to the kernel in
> all "normal" linux situations) is reserved for use by the emulator;
> As far as the kernel is concerned, that memory doesn't even exist.
>
> So that might cause all sorts of interesting problems --- and judging
> from *where* things crash, I suspect "pte" ends ub being NULL. The top
> line above does _not_ crash because at that point, address 0 is still
> both readable and writable. Then the page table cache gets flushed, and
> address 0 is suddenly read-only.... so assigning to "*pte" fails.
>
> This is also what I suspect causes your crash-after-boot problem.
> Commenting out the line you did will probably leave the page at address 0
> in a read-only state, so once Amithlon gets all started up and ready
> to go, it tries to clear the emulated Amiga's memory (which starts,
> not surprisingly, at address 0 :), and the very first memory write
> bombs out with an uncorrectable segmentation violation.
>
> Couple of points come to mind:
>
>   a) Q: Why doesn't the same thing happen on other machines?
>      A: Because all other current CPUs support "PSE" (whatever that is :),
>         and if so, the kernel never calls this test routine
>
>   b) Q: What can you do about it?
>      A: Replace the whole function with a dummy, as shown beloe
>
>          void __init test_wp_bit(void)
>          {
>              /* Any processor capable of running Amithlon *does* support
>                 the WP bit even in supervisor mode */
>              boot_cpu_data.wp_works_ok = 1;
>          }
>
>
no joy Bernie....boots and starts going through the [small,big]ird.gz then gets
to the
setting of the video mode to vesa and then reboots. :(

Paul (pkp)

  Give that a shot, and let me know how it goes.
>
> Hope it helps,
>
>    Bernie

>        *pte = mk_pte_phys(0, PAGE_READONLY);
>        local_flush_tlb();
>        boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);
>
>/*      *pte = old_pte; */
>^^^^^^^^^^^^^^^^^^^^^^^^^^  causes the panic....

I can see why that might happen. I can't look at kernel source right
now (the machine that has kernel sources needs rebooting :), but I
suspect that the first line up there tries to create a page table entry
for the page starting at address 0.
In Amithlon, that page (which is probably available to the kernel in
all "normal" linux situations) is reserved for use by the emulator;
As far as the kernel is concerned, that memory doesn't even exist.

So that might cause all sorts of interesting problems --- and judging
from *where* things crash, I suspect "pte" ends ub being NULL. The top
line above does _not_ crash because at that point, address 0 is still
both readable and writable. Then the page table cache gets flushed, and
address 0 is suddenly read-only.... so assigning to "*pte" fails.

This is also what I suspect causes your crash-after-boot problem.
Commenting out the line you did will probably leave the page at address 0
in a read-only state, so once Amithlon gets all started up and ready
to go, it tries to clear the emulated Amiga's memory (which starts,
not surprisingly, at address 0 :), and the very first memory write
bombs out with an uncorrectable segmentation violation.

Couple of points come to mind:

   a) Q: Why doesn't the same thing happen on other machines?
      A: Because all other current CPUs support "PSE" (whatever that is :),
         and if so, the kernel never calls this test routine

   b) Q: What can you do about it?
      A: Replace the whole function with a dummy, as shown beloe

          void __init test_wp_bit(void)
          {
              /* Any processor capable of running Amithlon *does* support
                 the WP bit even in supervisor mode */
              boot_cpu_data.wp_works_ok = 1;
          }

Give that a shot, and let me know how it goes.

Hope it helps,

    Bernie

--- In amithlondev@yahoogroups.com, "pkp700" <pkp@t...> wrote:
> Well after spending a few days on it I've come to the conclusion that
> Eden is not 100%
> compatible with x86 chips. A kernel that I've built boots on my athlonXP
> [small,big]ird.gz no problem.  that same kernel boots [small,big]ird.gz BUT!
>

just edited this section I missed a couple of things

> -after it does all the default settings ie cachesize,video timings,> fat95
ect...
>   it does a hard reset.
>
> So I'm thinking it is a memory allocation. I had to disable the
> detect_wp_bit in the ./arch/i386/mm/init.c to get it that far on the Eden
board.
> Even though when I do a cat /proc/cpuinfo  it shows the WP Flag: yes. To be
honest
> I have no idea. The moving PCI NOW! section seems to be all out of alignment.
> I've tried to hack in some 2.4.2x stuff from Alan Cox seeing he is doing some
> C3/Eden stuff in his tree.
>
> But a regular linux kernel detects the WP no problem....
> this segment of code is identical to the standard linux kernel. but
> the section I've
> remarked out is causing the kernel panic on boot. with it remarked
> out it boots to the
> point as described above.
>
> /usr/src/linux/arch/i386/mm/init.c
> *
>  * Test if the WP bit works in supervisor mode. It isn't supported on
> 386's
>  * and also on some strange 486's (NexGen etc.). All 586+'s are OK.
> The jumps
>  * before and after the test are here to work-around some nasty CPU
> bugs.
>  */
>
> /*
>  * This function cannot be __init, since exceptions don't work in that
>  * section.
>  */
> static int do_test_wp_bit(unsigned long vaddr);
>
> void __init test_wp_bit(void)
> {
> /*
>  * Ok, all PSE-capable CPUs are definitely handling the WP bit right.
>  */
>
>        const unsigned long vaddr = PAGE_OFFSET;
>         pgd_t *pgd;
>         pmd_t *pmd;
>         pte_t *pte, old_pte;
>         printk("Checking if this processor honours the WP bit even in
> supervisor mode...
> ");
>
>         pgd = swapper_pg_dir + __pgd_offset(vaddr);
>         pmd = pmd_offset(pgd, vaddr);
>         pte = pte_offset(pmd, vaddr);
>         old_pte = *pte;
>         *pte = mk_pte_phys(0, PAGE_READONLY);
>         local_flush_tlb();
>         boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);
>
> /*      *pte = old_pte; */
> ^^^^^^^^^^^^^^^^^^^^^^^^^^  causes the panic....
>
>         local_flush_tlb();
>         if (!boot_cpu_data.wp_works_ok) {
>                 printk("No.\n");
> #ifdef CONFIG_X86_WP_WORKS_OK
>                 panic("This kernel doesn't support CPU's with broken WP.
Recompile it
for a
> 386!");
> #endif
>         } else {
>                 printk("Ok.\n");
>         }
> }
>
> Memory Allocation problems???
>
>
> I wish there was a way to send the debug output into a file. so I
> could post it.
>
> So for now my Eden/Amithlon project is shelved. Unless another person
> with a Eden
> board with kernel knowledge could help.
>
> Paul (pkp)

Well after spending a few days on it I've come to the conclusion that
Eden is not 100%
compatible with x86 chips. A kernel that I've built boots
[small,big]ird.gz no problem.
that same kernel boots [small,big]ird.gz BUT!

-after it does all the default settings ie cachesize,video timings,
fat95 ect...
   it does a hard reset.

So I'm thinking it is a memory allocation. I had to disable the
detect_wp_bit in the
./arch/i386/mm/init.c to get it that far on the Eden board. Even
though when I do a
cat /proc/cpuinfo  it shows the WP Flag: yes. To be honest I have no
idea. The moving
PCI NOW! section seems to be all out of alignment. I've tried to hack
in some 2.4.2x
stuff from Alan Cox seeing he is doing some C3/Eden stuff in his tree.

But a regular linux kernel detects the WP no problem....
this segment of code is identical to the standard linux kernel. but
the section I've
remarked out is causing the kernel panic on boot. with it remarked
out it boots to the
point as described above.

/usr/src/linux/arch/i386/mm/init.c
*
  * Test if the WP bit works in supervisor mode. It isn't supported on
386's
  * and also on some strange 486's (NexGen etc.). All 586+'s are OK.
The jumps
  * before and after the test are here to work-around some nasty CPU
bugs.
  */

/*
  * This function cannot be __init, since exceptions don't work in that
  * section.
  */
static int do_test_wp_bit(unsigned long vaddr);

void __init test_wp_bit(void)
{
/*
  * Ok, all PSE-capable CPUs are definitely handling the WP bit right.
  */

        const unsigned long vaddr = PAGE_OFFSET;
         pgd_t *pgd;
         pmd_t *pmd;
         pte_t *pte, old_pte;
         printk("Checking if this processor honours the WP bit even in
supervisor mode...
");

         pgd = swapper_pg_dir + __pgd_offset(vaddr);
         pmd = pmd_offset(pgd, vaddr);
         pte = pte_offset(pmd, vaddr);
         old_pte = *pte;
         *pte = mk_pte_phys(0, PAGE_READONLY);
         local_flush_tlb();
         boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);

/*      *pte = old_pte; */
^^^^^^^^^^^^^^^^^^^^^^^^^^  causes the panic....

         local_flush_tlb();
         if (!boot_cpu_data.wp_works_ok) {
                 printk("No.\n");
#ifdef CONFIG_X86_WP_WORKS_OK
                 panic("This kernel doesn't support CPU's with broken WP.
Recompile it for a
386!");
#endif
         } else {
                 printk("Ok.\n");
         }
}

Memory Allocation problems???


I wish there was a way to send the debug output into a file. so I
could post it.

So for now my Eden/Amithlon project is shelved. Unless another person
with a Eden
board with kernel knowledge could help.

Paul (pkp)

>I think I might have found the problem. The Eden cpu'sdo not support
>the CMOV instruction.

That in itself shouldn't be a problem --- the JIT compiler is designed
to run on cmov-less CPUs, substituting conditional branches. It's
less efficient, but it *should* work (and I recall people reporting that
they ran Amithlon on K6 machines, which also lack CMOV).

>So if the JIT compiler uses CMOV instructions  then it won't work,

As I mentioned above, it *shouldn't* use CMOV. It uses the cpuid bits to
decide, and from looking at the code again, it looks like I didn't screw
it up.

You should be able to check this with the test cd ISO image... You can
still grab it from

      http://www.amithlon.net/test/booter_cdrom.zip

When that has booted up (and hopefully failed to crash and burn :),
it should tell you whether cmov is available (near the place where
it talks about "rat-stall", too). The code is the same as used inside
Amithlon.

>The only person that might know this is Bernie seeing he rewrote the
>JIT m68k thingy (babe?)

The detection routine is somewhat different from that in UAE-JIT. See below.
If someone can see something wrong with that, please speak up :) The
"cpuid()" function does the obvious, and the "x86_regs" structure has
the obvious members......

Bernie


static void raw_init_cpu(void)
{
     x86_regs x;
     uae_u32 maxlev;

     x=cpuid(0);
     maxlev=x.eax;
     write_log("Max CPUID level=%d Processor is %c%c%c%c%c%c%c%c%c%c%c%c\n",
               maxlev,
               x.ebx,
               x.ebx>>8,
               x.ebx>>16,
               x.ebx>>24,
               x.edx,
               x.edx>>8,
               x.edx>>16,
               x.edx>>24,
               x.ecx,
               x.ecx>>8,
               x.ecx>>16,
               x.ecx>>24
               );
     sprintf(processor,"%c%c%c%c%c%c%c%c%c%c%c%c",
             x.ebx,
             x.ebx>>8,
             x.ebx>>16,
             x.ebx>>24,
             x.edx,
             x.edx>>8,
             x.edx>>16,
             x.edx>>24,
             x.ecx,
             x.ecx>>8,
             x.ecx>>16,
             x.ecx>>24
             );
     have_rat_stall=(x.ecx==0x6c65746e);

     if (maxlev>=1) {
         x=cpuid(1);
         if (x.edx&(1<<15))
             have_cmov=1;
     }
     if (!have_cmov)
         have_rat_stall=0;
     write_log ("have_cmov=%d, have_rat_stall=%d\n",
                have_cmov,have_rat_stall);
}

I think I might have found the problem. The Eden cpu'sdo not support
the CMOV instruction. So if the JIT compiler uses CMOV instructions
then it won't work, but I found a patch that emulates the CMOV in the
linux kernel. So I'll give it a try once I get gentoo installed on my
machine.

The only person that might know this is Bernie seeing he rewrote the
JIT m68k thingy (babe?)

Paul (pkp)

Begin forwarded message:

> From: Paul Pledge <pkp@...>
> Date: Wed Jul 23, 2003  5:22:11 AM America/Vancouver
> To: amithlondev@yahoogroups.com
> Subject: Re: [amithlondev] Re: Bernie: slight progress on the eden
> booting amithlon
>
>
> On Wednesday, July 23, 2003, at 04:43 AM, Bernie Meyer wrote:
>
>> >> =====moving pci now! =======
>> >> bus resource 1: 04000000 - e5ffffff
>> >> bus resource 2: e0000000 - e3ffffff
>>
> ok it is
> dc000000 - ddffffff
> d8000000 - dbffffff
>
> :)
>
> And it get's to the point of loading up smallird.gz which starts to
> set the predefined settings ie:
>
> cachsize to 8192   (JIT stack?)
> all the video sync timings
> clockflags
> asynchronous ect....
> then when it reaches the setting of the preset ramdisk size it sets it
> then reboots.
>
> I wish I had a camera I could take a picture of it
>
> I hope this clarifies things
>
> Paul (pkp)
>
>> Are you sure that first line isn't a typo? If it really starts at
>> 04000000, rather than (as I suspect) e4000000, that's at least part
>> of the problem.... The Amithlon kernel cannot handle PCI resources
>> larger than about 1.5GB (The whole PCI address space, *plus* the
>> CPU stack, need to fit into the 0x60000000 to 0xc0000000 range).
>>
>> >OK it boots!!!! but it dies on the config settings ie vesa
>> horizontal ect...
>>
>> Hmmm... So you get all the way into AmigaOS? Can you provide more
>> detail
>> exactly what fails, and exactly what happens when it does?
>>
>> Bernie
>>
>>
> <image.tiff>
>>
>>
>> To unsubscribe from this group, send an email to:
>> amithlondev-unsubscribe@yahoogroups.com
>>
>>
>>
>> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi TigerGutt, on Jul 23 you wrote:

  > Humz, so the rest is up to me to mess with correct settings to my monitor ?

That's right, the mentioned setconfig line only removes the 99 MHz
limitation of Picasso96Mode.

       ...
       _ . Thomas Tavoly
  . _ // . aTmosh@...
  . \X/    http://distributed.amiga.org
  ...  5.5

Wazzup! Amithlondev-list@...

On 14.Jul.2003, you wrote:

> Hi TigerGutt, on Jul 14 you wrote:
>
>> Humz, I have my Pixel clokc to 99, is there any way to get it higher ?
>> I think my monitor handle some more before it burn up.
>
> setconfig p96clockmax 300
>
> in your startup-sequence (earlier than the setconfig rebootifchanged
> line). All this does is lift the 99 MHz limit in Prefs/Picasso96Mode, so
> shouldn't burn up your monitor by itself. You have to change screenmodes
> to actually use the new range that has been opened up.
>
> This is the MHz value the RAMDAC can do, 350 is common, some newer cards
> go even higher (400+), according to at least one webpage I found the
> Voodoo 3 does 300-350 MHz so 300 should be a safe upper limit. Any decent
> monitor will simply switch off if you specify a mode which goes over the
> edge anyway.

Humz, so the rest is up to me to mess with correct settings to my monitor ?

Thanks for info!

With regards
--
Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS

Wazzup! rudolph-riedel@...

On 14.Jul.2003, you wrote:

> tigergutt@... (TigerGutt) wrote on 14.07.2003:
>
> Hello!
>
>> motion.c:1566: Unable to generate reloads for:
>> (jump_insn 249 248 147 (parallel[
>>             (set (pc)
>>                 (if_then_else (ge (plus:SI (reg/v:SI 37)
>>                             (const_int -1 [0xffffffff]))
>>                         (const_int 0 [0x0]))
>>                     (label_ref 68)
>>                     (pc)))
>>             (set (reg/v:SI 37)
>>                 (plus:SI (reg/v:SI 37)
>>                     (const_int -1 [0xffffffff])))
>>         ] ) 313 {decrement_and_branch_until_zero+1} (nil)
>>     (expr_list:REG_NONNEG (nil)
>>         (expr_list:REG_NONNEG (nil)
>>             (nil))))
>>
>> Any clues ?
>
> You have a loop that is to complicated to compile with the few
> registers available in this function.
>
> Go thru this function and comment out parts of it
> untill it compiles.
>
> Then try to modify the "faulty" loop to be simpler.
>
> If it's not to long you also could place the fragment
> in question here.

To much for an newbie like me..

Still I like I got one binary :)

With regards
--
Disinformation is not as good as datinformation.

On Wednesday, July 23, 2003, at 04:43 AM, Bernie Meyer wrote:

> >> =====moving pci now! =======
> >> bus resource 1: 04000000 - e5ffffff
> >> bus resource 2: e0000000 - e3ffffff
>
ok it is
dc000000 - ddffffff
d8000000 - dbffffff

:)

And it get's to the point of loading up smallird.gz which starts to set
the predefined settings ie:

cachsize to 8192   (JIT stack?)
all the video sync timings
clockflags
asynchronous ect....
then when it reaches the setting of the preset ramdisk size it sets it
then reboots.

I wish I had a camera I could take a picture of it

I hope this clarifies things

Paul (pkp)

> Are you sure that first line isn't a typo? If it really starts at
> 04000000, rather than (as I suspect) e4000000, that's at least part
> of the problem.... The Amithlon kernel cannot handle PCI resources
> larger than about 1.5GB (The whole PCI address space, *plus* the
> CPU stack, need to fit into the 0x60000000 to 0xc0000000 range).
>
> >OK it boots!!!! but it dies on the config settings ie vesa horizontal
> ect...
>
> Hmmm... So you get all the way into AmigaOS? Can you provide more
> detail
> exactly what fails, and exactly what happens when it does?
>
> Bernie
>
>
<image.tiff>
>
>
> To unsubscribe from this group, send an email to:
> amithlondev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

>> =====moving pci now! =======
>> bus resource 1: 04000000 - e5ffffff
>> bus resource 2: e0000000 - e3ffffff

Are you sure that first line isn't a typo? If it really starts at
04000000, rather than (as I suspect) e4000000, that's at least part
of the problem.... The Amithlon kernel cannot handle PCI resources
larger than about 1.5GB (The whole PCI address space, *plus* the
CPU stack, need to fit into the 0x60000000 to 0xc0000000 range).

>OK it boots!!!! but it dies on the config settings ie vesa horizontal ect...

Hmmm... So you get all the way into AmigaOS? Can you provide more detail
exactly what fails, and exactly what happens when it does?

Bernie

--- In amithlondev@yahoogroups.com, "pkp700" <pkp@t...> wrote:
> OK, So I have munged the kernel by disabling the WP detection code on
arch/i386/
> mm/init.c
>
> the /proc/cpuinfo states the cpu supports the WP but the detecting code
panics.
>
> so it boots to the point where it starts the pci address moving. It stays on
that for a
> bit then screen goes black and then reboots...
>
> =====moving pci now! =======
> bus resource 1: 04000000 - e5ffffff
> bus resource 2: e0000000 - e3ffffff
>
> sits at that point then reboots after about 2-3 seconds

OK it boots!!!! but it dies on the config settings ie vesa horizontal ect...

right when it sets ramdisk size

Bernie??

>
> could it be low memory? I've only got 128megs but I was only using 128megs on
my
> athlon system prior to the eden.
>
> the boing ball even spins...
>
> Bernie? :)
>
> I think I'm making progress.
>
> Paul (pkp)

OK, So I have munged the kernel by disabling the WP detection code on arch/i386/
mm/init.c

the /proc/cpuinfo states the cpu supports the WP but the detecting code panics.

so it boots to the point where it starts the pci address moving. It stays on
that for a
bit then screen goes black and then reboots...

=====moving pci now! =======
bus resource 1: 04000000 - e5ffffff
bus resource 2: e0000000 - e3ffffff

sits at that point then reboots after about 2-3 seconds

could it be low memory? I've only got 128megs but I was only using 128megs on my
athlon system prior to the eden.

the boing ball even spins...

Bernie? :)

I think I'm making progress.

Paul (pkp)

processor : 0
vendor_id : CentaurHauls
cpu family : 6
model  : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz  : 599.719
cache size : 64 KB
fdiv_bug : no
hlt_bug  : no
f00f_bug : no
coma_bug : no
fpu  : yes
fpu_exception : yes
cpuid level : 1
wp  : yes
flags  : fpu de tsc msr cx8 mtrr pge mmx 3dnow
                          ^^^
is that what we are looking for for cycle counter

bogomips : 1196.03


Paul (pkp)

--- In amithlondev@yahoogroups.com, Bernie Meyer <amithlon@a...> wrote:
> >I've worked on trying to get the kernel to boot on my eden me6000
> >board to no avail.  It seems (checking with ksymoops) that
> >./arch/i386/mm/init.c is the culprit.  Seems to be the function
> >'test_wp_bit' I have no idea what is wrong... Maybe I can get a hold
> >of Bernie
>
> Just spent 17 hours straight at work, so I'll be somewhat brief....
>
> The first thing Amithlon *insists* on having is a cycle counter. IIRC,
> the Eden boards use the VIA C3; I don't know whether VIA might have
> economized there.... if the C3 doesn't have a cycle counter, the kernel
> *will* panic.
> If you boot a "normal" linux, can you find out what the resolution of
> gettimeofday() actually is? If it goes up in steps of 10ms, there is
> no cycle counter.
>
> I made a number of changes in init.c, related to reserving a lot of
> memory for Amithlon. I am not sure exactly what test_wp_bit() does;
> One thing to check might be that it doesn't blindly try to use
memory that
> doesn't belong to the kernel anymore. Also, however it tries to do the
> check, you might try replacing it with a simple stub replying
appropriately
> (look at a normal linux bootup to find out what the appropriate response
> is).
>
> Lastly, try not compiling in APM support into the kernel. The Eden
boards
> may do weird things and confuse the Amithlon kernel.
>
> Best of luck,
>
>    Bernie

Thanks Bernie for the insight, I'll look into it and see what I come
up with.

Paul (pkp)

>I've worked on trying to get the kernel to boot on my eden me6000
>board to no avail.  It seems (checking with ksymoops) that
>./arch/i386/mm/init.c is the culprit.  Seems to be the function
>'test_wp_bit' I have no idea what is wrong... Maybe I can get a hold
>of Bernie

Just spent 17 hours straight at work, so I'll be somewhat brief....

The first thing Amithlon *insists* on having is a cycle counter. IIRC,
the Eden boards use the VIA C3; I don't know whether VIA might have
economized there.... if the C3 doesn't have a cycle counter, the kernel
*will* panic.
If you boot a "normal" linux, can you find out what the resolution of
gettimeofday() actually is? If it goes up in steps of 10ms, there is
no cycle counter.

I made a number of changes in init.c, related to reserving a lot of
memory for Amithlon. I am not sure exactly what test_wp_bit() does;
One thing to check might be that it doesn't blindly try to use memory that
doesn't belong to the kernel anymore. Also, however it tries to do the
check, you might try replacing it with a simple stub replying appropriately
(look at a normal linux bootup to find out what the appropriate response
is).

Lastly, try not compiling in APM support into the kernel. The Eden boards
may do weird things and confuse the Amithlon kernel.

Best of luck,

    Bernie

Wazzup! pkp700

On 20.Jul.2003, you wrote:

> --- In amithlondev@yahoogroups.com, "pkp700" <pkp@t...> wrote:
>> ok, I managed to get a console with the kernel panic
>>
>> as follows
>>
>> Uncompressing Linux... Ok, booting the kernel
>> *pde = 00000063
>> *pte = 00000025
>> Oops: 0003
>> CPU:       0
>> EIP:         0010:[<c0217f0e>]    Not tainted
>> EFLAGS:  00010246
>> eax:   00000001   ebx: 00000000  ecx: 00000025  edx: c0000000
>> esi:    00000163   edi:  0000003c   ebp:  00000005  esp:  c020dfc0
>> ds:  0018   es: 0018  ss: 0018
>> Process swapper (pid: 0, stackpage=c020d000)
>> Stack: c0000000 00000319 c100001c c02180ee
>>           00134000 00000005 00007000 00007000
>>           00005a19 00000000 00098700 c0105000
>>           0008e000 c020e691 c024bfc0 c0100191
>> Call Trace: [<c0105000>]
>>
>> Code: 89 b3 00 00 c0 5e 0f 20 d8 0f 22 d8 80 3d c4 be 1e c0 00
>>  <0>Kernel Panic: Attempted to kill idle task!
>> In idle task - not syncing
>>
>>
>>
>> Any kernel hackers / Bernie have ideas??
>>
>>
>> Paul (pkp)
>
> ok here is the output
>
> ksymoops 2.4.4 on i686 2.4.18-3.  Options used
>     -v ./vmlinux (specified)
>     -K (specified)
>     -L (specified)
>     -O (specified)
>     -m ./System.map (specified)
>
> *pde = 00000063
> Oops: 0003
> CPU: 0
> EIP: 0010:[<c0217f0e>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000001 ebx: 00000000 ecx: 00000025 edx: c0000000
> esi: 00000163 edi: 0000003c ebp: 00000005 esp: c020dfc0
> ds: 0018 es: 0018 ss: 0018
> Process swapper (pid: 0, stackpage=c020d000)
> Stack: c0000000 00000319 c100001c c02180ee
> 00134000 00000005 00007000 00007000
>       00005a19 00000000 00098700 c0105000 0008e000 c020e691 c024bfc0
> c0100191
> Call Trace: [<c0105000>]
> Code: 89 b3 00 00 c0 5e 0f 20 d8 0f 22 d8 80 3d c4 be 1e c0 00
>
>>> EIP; c0217f0e <isapnp_proc_init+4e/a0>   <=====
> Trace; c0105000 <_stext+0/0>
> Code;  c0217f0e <isapnp_proc_init+4e/a0>
> 00000000 <_EIP>:
> Code;  c0217f0e <isapnp_proc_init+4e/a0>   <=====
>   0:   89 b3 00 00 c0 5e         mov    %esi,0x5ec00000(%ebx)   <=====
> Code;  c0217f14 <isapnp_proc_init+54/a0>
>   6:   0f 20 d8                  mov    %cr3,%eax
> Code;  c0217f17 <isapnp_proc_init+57/a0>
>   9:   0f 22 d8                  mov    %eax,%cr3
> Code;  c0217f1a <isapnp_proc_init+5a/a0>
>   c:   80 3d c4 be 1e c0 00      cmpb   $0x0,0xc01ebec4
>
> <0>Kernel Panic: Attempted to kill idle task!
>
> seems isapnp is the culprit...

AIK, Amithlon dont support ISA.
Can this be removed from the kernel sources ?

With regards
--
NT and security should not be used in the same sentence without negation.