From: antispam@fricas.org   
      
   albert@spenarnc.xs4all.nl wrote:   
   > In article ,   
   > Waldek Hebisch  wrote:   
   >>albert@spenarnc.xs4all.nl wrote:   
   >>> In article ,   
   >>> Waldek Hebisch  wrote:   
   >>>    
   >>>>   
   >>>>RISCV ciforth beta 2023Mar30   
   >>>>MMAP-IO   
   >>>> OK   
   >>>>HEX   
   >>>> OK   
   >>>>VMA-IO @ .   
   >>>>B2000000  OK   
   >>>>DEV-MEM @ .   
   >>>>3  OK   
   >>>>   
   >>> Encouraging.   
   >>>   
   >>>>Datasheet says that device address space starts at 0x01000000   
   >>>>and ends at 0x7FFFFFFF (above is DRAM).  There is a command   
   >>>>line utility to do I/O.  Sending 0x01000000 to 0x03022000 turns on   
   >>>>blue LED, sending 0x0 truns it off.  AFAICS in lina corresponding   
   >>>>address is B2022000.  More generally, there are four GPIO devices   
   >>>>(ports).  Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at   
   >>>>0x03022000, port 3 at 0x03023000.  Device access should be done in   
   >>>>32-bit units.   
   >>>   
   >>> This suggest that you can do the same from lina using virtual   
   >>> addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000.   
   >>> You probably have to initialize the ports to output in some way   
   >>> for this to work.   
   >>   
   >>I tried first things like above and got segfaults.  AFAICS lina B2000000   
   >>corresponds to 0x3000000 in device space, so 0x03022000 corresponds to   
   >>B2022000.  It seems that lina did not map block between 0x1000000   
   >>and 0x3000000, in this block that are 'ap_mailbox' and 'ap_system_ctrl',   
   >>it is probably not wise to mess with them from user space.   
   >   
   > Apparently it was wrong to add the 0x0100,0000. vma-io contains the   
   > device start. Then it works.   
   > The addresses below 0x0100,0000 are for chip control, start up,   
   > not so much for peripherals.   
   >>   
   >>> All io must be accessed with 32 bit. lina provides L! L@ for   
   >>> this. (My conventions is B-W-L-Q ).   
   >>   
   >>1000000 B2022000 L!   
   >> OK   
   >>0 B2022000 L!   
   >> OK   
   >>   
   >>blinks the LED.  I tried and 64-bit access works too, but it reads   
   >>or writes also the second register, so L! and L@ are simpler to use.   
   >>   
   >>I still need to check which GPIO-s are actually usable, there is   
   >>4*32 = 128 logical lines, but the 64-Mb chip has only 68 pins.   
   >   
   > The board I have DongshanNezha a ball grid with 377 balls.   
   > Io pins are A-G with up to 18 bits per port, a bit irregular but   
   > a lot.   
   > Not bad for less than 30 euro's. 60 pin's readily available to   
   > attach to.   
   > For generating midi (31kbaud serial) I used merely one pin to   
   > play FIG leaf rag on the keyboard.   
   >   
   >>   
   >>There are several control registers deciding what pins do:   
   >>PINMUX, RTCSYS_GPIO and control registers for GPIO device.   
   >>LED was configured for GPIO output by bundled software, so   
   >>it was enough to write to the data port.   
   >   
   > If you have a detailed electronics layout, it is easy to see   
   > what ports are free to use.  It can be a pain to configure the   
   > io. There is an example for the DongshanNezha board in forth.lab.   
      
   Well, chip datasheet, schematics and board description each used   
   different names for pins, but I worked out which pins are   
   connected to outside.  There is compilcation as some I/O lines   
   are 1.8V only and some are probably 3.3 tolerant but use 1.8V   
   signalling.  Normal lines are 3.3V, but 3 lines are 1.8V and   
   connected to level shifters so that on board connector there   
   3.3V signalling.  However "useful" for me is a bit more   
   complicated.  Chip contains bunch of SPI-s, I2C-s, SPI-s,   
   UART-s and PWM-s.  There are 2 SDIO interfaces, camera   
   interface and ethernet interface.  In principle one can use   
   camera and ethernet lines as GPIO, but it is tricky to   
   connect to camera lines (camera connector uses small pitch   
   ribbon) and both camera and ethernet use 1.8V signalling.   
   So there are electical questions (level shifters and 1.8V   
   signalling make lines less useful).  There is question of   
   cooperation with Linux: IIUC Linux considers ethernet and   
   SDIO0 lines as its own (and possibly several other lines).   
   So there is question which lines can I use without interfering   
   with Linux.  Given that chip contains 3 cores and only one   
   core runs Linux there should be a way to tell Linux that   
   some lines/device should be left alone.   
      
   Concerning forth.lab, I see there only examples for Raspberry Pi   
   and Orange Pi, but nothing for Risc-V boards.  I fetched   
   version from 2023Mar30, which looked as only available version   
   for Risc-V.  Assembly code is clearly for Risc-V, but   
   documentation says Arm or aarch and forth.lab also looks   
   like one form Arm.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)