Last visit was: Sat Oct 23, 2021 12:05 pm
It is currently Sat Oct 23, 2021 12:05 pm



 [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
 nPower 
Author Message

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
robfinch wrote:
Apparently the assembler does not seem to be able to follow the .org directives. I am sure it is just an option I am missing.


GNU AS?
GAS doesn't follow the common ".org" directive used by Motorola' AS (Sierra and similar), but rather it delegates to the linker's script, where you have to describe sections.


Last edited by DiTBho on Tue Dec 29, 2020 11:49 am, edited 1 time in total.



Mon Dec 28, 2020 4:26 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
This is using vasm not GNU AS but it is similar. The linker script I tried is one in a previous post. If ELF is selected as the output format from vasm then a ‘missing PHDRs’ error occurs during linking. If bin is selected then the linker says it is not a supported format. So, I am trying to use just .bin output directly from the assembler, bypassing the link stage.

This project is kind of stuck if a larger program cannot be built for testing.

There is no OS; code needs to be in ROM. There isn't a file system or a program loader available. One thought I had was to try writing a simple loader for something like S37 format. But a text file occupies too much room in ROM. Even if a loader is written how does it get to a ROM image?

_________________
Robert Finch http://www.finitron.ca


Tue Dec 29, 2020 4:22 am WWW

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 73
OK. Thanks!


Last edited by DiTBho on Fri Jan 01, 2021 1:35 pm, edited 1 time in total.



Tue Dec 29, 2020 12:07 pm

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 74
robfinch wrote:
This is using vasm not GNU AS but it is similar. The linker script I tried is one in a previous post. If ELF is selected as the output format from vasm then a ‘missing PHDRs’ error occurs during linking. If bin is selected then the linker says it is not a supported format. So, I am trying to use just .bin output directly from the assembler, bypassing the link stage.

This project is kind of stuck if a larger program cannot be built for testing.

There is no OS; code needs to be in ROM. There isn't a file system or a program loader available. One thought I had was to try writing a simple loader for something like S37 format. But a text file occupies too much room in ROM. Even if a loader is written how does it get to a ROM image?


I've just had a quick play with this, and the PHDR problem you're having appears to be related to the AT attribute in the link script - removing that causes my test program to build just fine. For my experiments in the past I avoided this problem by simply disallowing mutable non-zero data in the ROM - anything predefined was read-only, anything mutable was BSS. I created a very small TRAP memory region, and directed .data sections there to make the linker throw an error if I had mutable data in the ROM. There might well be a better solution, but right now I don't know what it is.

(The linker output switch you want is "-brawbin1" by the way - vasm calls it bin, vlink calls it rawbin1, just to keep things simple and consistent!)

If you need to bootstrap from ROM into RAM then the best bet is probably to compress your binary image with LZ4 or suchlike, and include some decompression code. I did something similar for MIPS once when I had plentiful RAM but needed to get an SD-card-reading bootloader into just 4K of ROM.

(LZ4 is *really* simple - here's the 68K decompression code I used as reference: https://github.com/arnaud-carre/lz4-68k ... allest.asm - Note: the LZ4 compressor creates a small header which will need to skipped over or stripped off.)


Wed Dec 30, 2020 9:12 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Quote:
I've just had a quick play with this, and the PHDR problem you're having appears to be related to the AT attribute in the link script - removing that causes my test program to build just fine. For my experiments in the past I avoided this problem by simply disallowing mutable non-zero data in the ROM - anything predefined was read-only, anything mutable was BSS. I created a very small TRAP memory region, and directed .data sections there to make the linker throw an error if I had mutable data in the ROM. There might well be a better solution, but right now I don't know what it is.
That is pretty drastic. I do not think that pre-initialized mutable data can be omitted from the system I am building. I spent some more time experimenting and managed to come up with something that appears to work. I had to change the system's memory map.

The following linker script is now in use. I think the PHDRS are redundant, but it works.

Code:
ENTRY (_start)

MEMORY {
   BIOS_BSS : ORIGIN = 0xFFFC0000, LENGTH = 512
}

MEMORY {
   BIOS_DATA : ORIGIN = 0xFFFC0200, LENGTH = 63k
}

MEMORY {
   BIOS_CODE : ORIGIN = 0xFFFD0000, LENGTH = 128K
}

MEMORY {
   BIOS_RODATA : ORIGIN = 0xFFFF0000, LENGTH = 64K
}

PHDRS {
   bios_bss PT_LOAD AT (0xFFFC0000);
   bios_hdr PT_LOAD AT (0xFFFC0200);
   bios_code PT_LOAD AT (0xFFFD0000);
   bios_rodata PT_LOAD AT (0xFFFF0000);
}

SECTIONS {
   .bss: {
      . = 0xfffc0000
      _start_bss = .;
      *(.bss);
      . = ALIGN(4);
      _end_bss = .;
   } >BIOS_BSS
   .data: {
      . = 0xfffc0200;
      _start_data = .;
      *(.data);
      . = ALIGN(4);
      _end_data = .;
   } >BIOS_DATA
   .text: {
      . = 0xfffd0000;
      *(.text);
      . = ALIGN(4);
      _etext = .;
   } >BIOS_CODE
   .rodata: {
      . = 0xffff0000;
      _start_rodata = .;
      *(.rodata);
      . = ALIGN(4);
      _end_rodata = .;
   } >BIOS_RODATA
}

The assembler keeps insisting on putting the .data section before .code. So, I altered the system to place the bios data area just before the code.
Finally, the rom is being built in a manner that can be set in bram.

Latest Fixes:
<hardware>A signal to update the link register was not propagated in the pipeline from the register fetch stage. This caused the link register to never be updated resulting in a crash on return from subroutine.

Milestone:
It looks like the core managed to execute the rand() routine from stdlib successfully. The next step will be to build up the test system in the FPGA. The text controller may need to be modified. The first demo will be just to place random characters on-screen.
Here is the current system memory map.
Code:
+-------------------------+
|                         |
|                         |
| 00000000 to 1FFFFFFF    |
| DRAM 512MB              |
|                         |
|                         |
+-------------------------+
|                         |
|                         |
| 20000000 to FAFFFFFF    |
| Empty space             |
|                         |
|                         |
+-------------------------+
| FBxxxxxx XBUS                  |
| 16MB                             |
+-------------------------+
| FFDxxxxx MMIO area      |
| 1MB                     |
+-------------------------+
| FFE00000 to FFFBFFFF    |
| Empty space             |
+-------------------------+
| FFFC0000 to FFFCFFFF    |
| 64k BIOS DATA Area      |
+-------------------------+
| FFFD0000 to FFFEFFFF    |
| 128k BIOS Code area     |
+-------------------------+
| FFFF0000 to FFFFFFFF    |
| 64k BIOS Rodata area    |
+-------------------------+


I changed the reset address to $FFFD0000.

_________________
Robert Finch http://www.finitron.ca


Thu Dec 31, 2020 3:52 am WWW

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 74
robfinch wrote:
The assembler keeps insisting on putting the .data section before .code. So, I altered the system to place the bios data area just before the code.
Finally, the rom is being built in a manner that can be set in bram.


If you have trouble with the order of sections (I think they're emitted in numerical address order?) - or if you want sections with large address gaps between them, one option is to use the -brawbin2 option with vlink - then you get a separate binary file for each section. You're then free to embed those within your ROM however you see fit, and copy the mutable data section to its final location at boot should you so wish.

Glad to see you've found a solution, anyway - have fun!


Thu Dec 31, 2020 9:35 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Quote:
If you have trouble with the order of sections (I think they're emitted in numerical address order?) -
There is code in the assembler to select numerical order, but it is irrelevant since each section is org’d at zero automatically. (I put debugging code in to see what was going on.)

The -rawbin2 options sounds like it would work.

Since the sections all have the same address, the assembler/linker just picks one (the data section) to place first. When binary output is selected this causes a ‘sections can not overlap’ error. Unfortunately putting in an .org statement in each section does not help because .org works in a strange fashion, moving relative to the start of the current section. As far as I can tell there is no way to .org sections continuously in memory. This seems strange to me because for binary output it is needed to build images that fit into specific areas of memory.

My own assembler works differently. A new section can be started continuously from a previous section, and it places the sections in order of first appearance. It makes it easy to generate a predictable ROM image using just the assembler. Alas my assembler does not handle PowerPC code, and I desire to use a linker as well.

_________________
Robert Finch http://www.finitron.ca


Thu Dec 31, 2020 11:57 am WWW

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 74
robfinch wrote:
Since the sections all have the same address, the assembler/linker just picks one (the data section) to place first.


Unless I'm missing something, won't it emit the sections in ascending address order, as defined by the MEMORY directives? So it was picking data first because that has the lowest address?

Quote:
As far as I can tell there is no way to .org sections continuously in memory.


If I'm understanding correctly, your problem here is that you want them continuous in the emitted binary file and thus the ROM, but for the references to be correct after the data section has been copied from the ROM image to its final location.

Quote:
This seems strange to me because for binary output it is needed to build images that fit into specific areas of memory.


Well, like I say, the rawbin2 format helps, but I think the linkscript syntax you're looking for might be this:

Code:
   .data: {
      _start_data = .;
      *(.data);
      . = ALIGN(4);
      _end_data = .;
   } >BIOS_DATA AT >BIOS_ROM


Fri Jan 01, 2021 12:12 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Latest Fixes:
<hardware> Propagation of the compare decode signal got missed. This led to condition register updates being missed. Ultimately causing branches to fail. Divide was returning the fractional portion of the divide instead of the whole quotient portion.

All is good at the moment, there is code that can be executed from BRAM. It should work good enough to allow a loader to be written. The goal is to load software via the PTI (parallel transfer interface). Anyone know of a small OS (<512kB) that can be run on the PowerPC?

In my compiler, the stride of the enum can be passed as an parameter like so:
Code:
enum(-1) {
     E_Ok = 0,
     E_BadTCBHandle,
     E_BadPriority,
     E_BadCallno,
     E_BadEntryno,
     E_Arg,

Which tells the compiler to assign enum values, decrementing by one for each value. It is a pita to convert to a compiler that does not support the feature.

_________________
Robert Finch http://www.finitron.ca


Fri Jan 01, 2021 3:15 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Stuck on this error now: internal error in compiler:
Code:
vbcc V0.9f (c) in 1995-2017 by Volker Barthelmann
vbcc code-generator for PPC V0.6c (c) in 1997-2008 by Volker Barthelmann
>       DBGDisplayAsciiString("\nerrors: ");
warning 161 in line 113 of "memmgnt3.c": implicit declaration of function <DBGDisplayAsciiString>
>               brks[n] = 16777216;
warning 113 in line 185 of "memmgnt3.c": only 0 should be assigned to pointer
>      pt_setup_pte(&q,pe,asid,acr,key);
warning 161 in line 250 of "memmgnt3.c": implicit declaration of function <pt_setup_pte>
>void
error 158 in line 323 of "memmgnt3.c": internal error 0 in line 323 of file machines\ppc\machine.c !!
aborting...
unexpected end of file
1 error found!
NMAKE :  U1077: 'D:\cores2020\nPower\v1\software\CC64\vbcc\bin\vbccppc.EXE' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

_________________
Robert Finch http://www.finitron.ca


Sat Jan 02, 2021 11:46 am WWW

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 74
robfinch wrote:
Stuck on this error now: internal error in compiler:


Needless to say without seeing the actual code it's choking on no-one can help there - but I see you're using vbcc 0.9f. It's worth trying 0.9g from http://sun.hasenbraten.de/vbcc/ or the development snaphot of 0.9h pre at http://www.compilers.de/vbcc.html

If both of those fail, have a look at the vbcc/machines/ppc/machine.c file to see what's going on at the line of the internal error - it might give you a clue as to what it is about the code it doesn't like. If the code is valid standard C and still won't compile with 0.9h then report the bug!


Sat Jan 02, 2021 12:53 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Quote:
If both of those fail, have a look at the vbcc/machines/ppc/machine.c file to see what's going on at the line of the internal error - it might give you a clue as to what it is about the code it doesn't like. If the code is valid standard C and still won't compile with 0.9h then report the bug!

Yeah, I had a look at machine.c. It appears to be croaking trying to load an address value into a register.
This is the line it croaks on according to the error message:
Code:
static void load_address(FILE *f,int r,struct obj *o,int typ)
/*  Generates code to load the address of a variable into register r.   */
{
  BSET(regs_modified,r);
  if(!(o->flags&VAR))
    ierror(0);

It looks like o->flags&VAR is not a VAR.
Unfortunately it is just a guess as to what line of source code is failing. I note the line number given for the source code is the same line number as in machine.c. This would be one heck of a co-incidence, or the line number is not reported correctly.
This is the routine that begins at line 323 of source code. It is pretty standard C code. I do not see where an address value is being taken which makes me think the issue is elsewhere in the source code.
Code:
void *pt_alloc(int key, int asid, int amt, int acr)
{
   char *p;
   int npages;
   int nn;

   if (asid < 0 || asid > 255)
      return ((void *)E_BadASID);
   p = (char *)E_NoMem;
   DBGDisplayChar('B');
   amt = round4k(amt);
   npages = amt >> 12;
   if (npages==0)
      return (p);
   DBGDisplayChar('C');
   if (npages < sys_pages_available) {
      sys_pages_available -= npages;
      p = brks[asid];
      brks[asid] += amt;
      for (nn = 0; nn < npages-1; nn++) {
         pt_alloc_page(key,asid,(int)p+(nn << 12),acr,0);
      }
      pt_alloc_page(key,asid,(int)p+(nn << 12),acr,1);
      p = (char *)((int)p | (asid << 56));
   }
   DBGDisplayChar('E');
   return (p);
}


_________________
Robert Finch http://www.finitron.ca


Sat Jan 02, 2021 10:42 pm WWW

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 74
Some printfs in load_address() might give you a clue what's going on.

something along the lines of
printf("Flags: %d, Var %s",o->flags,o->Var->identifier);
will, if you're lucky, give you the name of the variable it's choking on. If you're not lucky you might need to guard against o->var->identifier being NULL.

You can also put something like:
if (p->file)
printf("File %s, line %d\n",p->file, p->line);

in the gen_code function's inner loop, (just after the " for(;p;pr(f,p),p=p->next){" at line 2775) to get a running commentary of which source line is being processed before it crashes.

(Also have a look at the supp.h header file and the backend interface documentation http://www.ibaug.de/vbcc/doc/vbcc_13.html if you need to get more details of the obj and var structures.)


Sat Jan 02, 2021 11:37 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
I got the var it is choking on: "key". This is simply an int parameter nothing strange.

Code:
D:\cores2020\nPower\v1\software\fmtk>nmake

Microsoft (R) Program Maintenance Utility Version 14.28.29335.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        cd source && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe" /C FMTK
        vbccppc -c99 -ID:\cores2020\nPower\v1\software\inc memmgnt3.c
vbcc V0.9f (c) in 1995-2017 by Volker Barthelmann
vbcc code-generator for PPC V0.6c (c) in 1997-2008 by Volker Barthelmann
>               brks[n] = 16777216;
warning 113 in line 192 of "memmgnt3.c": only 0 should be assigned to pointer
Flags: 64, Var key>void
error 158 in line 343 of "memmgnt3.c": internal error 0 in line 324 of file .\machines\ppc\machine.c !!
aborting...
unexpected end of file
1 error found!
NMAKE :  U1077: 'D:\cores2020\nPower\v1\software\CC64\vbcc\bin\vbccppc.EXE' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.


I fixed up a couple of the warnings and now it does not choke on that line, but it also does not complete successfully.
PS. The line 323 *was* just a co-incidence. Adding more code changed the line number.
It just quits now with no explanation.
Code:
D:\cores2020\nPower\v1\software\fmtk>nmake

Microsoft (R) Program Maintenance Utility Version 14.28.29335.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        cd source && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe" /C FMTK
        vbccppc -c99 -ID:\cores2020\nPower\v1\software\inc memmgnt3.c
vbcc V0.9f (c) in 1995-2017 by Volker Barthelmann
vbcc code-generator for PPC V0.6c (c) in 1997-2008 by Volker Barthelmann
NMAKE :  U1077: 'D:\cores2020\nPower\v1\software\CC64\vbcc\bin\vbccppc.EXE' : return code '0xc0000005'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

More digging required.
I will try and find a newer version of the compiler.

_________________
Robert Finch http://www.finitron.ca


Sun Jan 03, 2021 2:38 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1508
Location: Canada
Came up with a scalar in-order version of the core. Without caches or memory management and no floating-point. The core is pipelined with each stage taking multiple clock cycles. The core is only about 1000 LUTs.
Got the nPower SoC built and running in an FPGA. The LEDs light up with the correct pattern! And the four A’s appear onscreen. I made a simple demo of randomly updated characters onscreen, but I forgot to seed the random number generator. This resulted in the same screen position being updated with the same data constantly. So, there was no visible screen update. I thought the processor was hung, but it turned out to be software. Well, the simple demo is not working quite yet.
The demo is programmed in ‘C’ and compiled with the vbcc C compiler.
Code:
int main()
{
   int* pLEDS = 0xFFDC0600;
   int* pScreen = 0xFFD00000;
   int* pMem = BIOSMEM;
   int n;
   int DBGAttr;

   *pLEDS = 0xAA;
   pMem[5] = (int)ext_irq|0x48000002;
   pMem[12] = (int)syscall|0x48000002;
   DBGAttr = 0x4FF0F000;
   pScreen[0] = DBGAttr|'A';
   pScreen[1] = DBGAttr|'A';
   pScreen[2] = DBGAttr|'A';
   pScreen[3] = DBGAttr|'A';
   
   srand(1234);
   for (n = 0; n < 100000; n = n + 1)
      pScreen[abs(rand())%(64*33)] = rand();
      
}

_________________
Robert Finch http://www.finitron.ca


Sat Sep 18, 2021 6:14 am WWW
 [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software