LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Xinu release

Wed Aug 08, 2018 1:13 pm

I finished the conversion of Xinu for the Pi1,2,3 and getting it ready to publish but just dealing with a few last strange bits

One of which is does anyone know what the strange characters on the Xinu start screen are
Image

I am guessing it's some sort of terminal emulation code to draw ascii code that I need to make the screen understand

When I hit a command like usbinfo it displays correctly .. I think :-)
Image
Last edited by LdB on Wed Aug 08, 2018 1:20 pm, edited 1 time in total.

procount
Posts: 1259
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Xinu release

Wed Aug 08, 2018 1:15 pm

They are ANSI escape sequences, in this case used to change the colour of the following text.
See https://en.wikipedia.org/wiki/ANSI_escape_code
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Wed Aug 08, 2018 5:45 pm

Cheers for that much better display after adding an escape sequence parser
Just documentation to do and all done.

Image

Image

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Fri Aug 10, 2018 4:36 am

In cleaning up the Xinu code there is something that puzzles me with the LAN9512 code in that it generates a random MAC address.

I am querying if that is correct and it shouldn't just be using the MAC address returned from the pi mailbox property tag 0x00010003
I know that return will always be b8:27:eb:??:??:??

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Xinu release

Sat Aug 11, 2018 4:19 am

Are you going to release the code on GitHub or GitLab?

User avatar
Ultibo
Posts: 135
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Xinu release

Mon Aug 13, 2018 11:37 am

LizardLad_1 wrote:
Sat Aug 11, 2018 4:19 am
Are you going to release the code on GitHub or GitLab?
Maybe neither, it seems the original authors of Xinu already have.

http://reu.mscs.mu.edu/index.php/Upgrad ... berry_Pi_3
https://dl.acm.org/citation.cfm?id=3162 ... CM&coll=DL




.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Mon Aug 13, 2018 6:13 pm

Someone hasn't been watching the discussion on the other thread with one of the publishers :-)

Yes I am going to put it up on Github. I am just finishing the port to ARCH64 which has meant going thru and putting uint32_t in critical positions and packing some structures which is time consuming.

My warning is the linked repository code isn't stable .. so if you want to dash ahead and use it I will give you the two big gotchas that will drive you crazy.

1.) This one will drive you nuts everytime you change code slightly and recompile and the code will crash. Write some more and it comes back to working. Basically anytime you change the size of the BSS you can have dramas.

The problem is in start.S with the fact the Stack Pointer must be align 8. If you look at the BSS clearing code and Stack Pointer set you will see the problem and then look at the context stacksetup code. There is a label called _end in the linker file which is aligned and use that instead and it will stabilize to be usable.

2.) The whole memory sizing by atags isn't working and so the heap etc can get crunched on different models. The proper solution is to use the Pi mailbox system on channel 8 and get the VC and ARM memory from them.

On the linked repository the upper address has actually been hard coded for a Pi3
https://github.com/rlatinovich/xinu/blo ... forminit.c

Code: Select all

platform.maxaddr = (void *)0x3EFFFFFC; /* Used only if atags are bad */
It just needs to be got from Pi mailbox system channel 8, tag 0x00010005 and add the two values returned (the first will be zero anyhow).

Here is the proper Xinu memory layout with how you get the values from the various calls/variables.

Code: Select all

/*=========================================================================
*
*   Specific for Raspberry Pi all models - Memory Layout (Not to scale)
*  1GB MAX OF PHYSICAL MEMORY AVAILABLE ON ALL MODELS. 1GB == 0x3FFFFFFF

* +----------+
* |          |
* |  SPECIAL | -> BC2836/7 Multicore support area 0x40000000- 0x4003FFFF described in (QA7_rev3.4.pdf)
* |          |
* +----------+
      ....
* +----------+
* |	      |
* | IO SPACE | -> Pi1: 0x20000000 to 0x20FFFFFF, Pi2/3: 0x3F000000 to 0x3FFFFFFF 
* |          |    reserved for IO (GPIO, UART, SYS TIMER, USB CORE)
* +----------+
* |          |
* |  UNUSED  | -> Possible unused space on Pi1 with 256K, Pi2/3 with 512K memory
* |          |
* +----------+   <---- You get this from Pi mailbox system channel 8, tag 0x00010006 add the two values
* |          |
* |   GPU    | -> GPU will reserve 80-300K memory always at back of available memory
* |          |
* +----------+   <---- You get this from Pi mailbox system channel 8, tag 0x00010006
* |          |
* | UNUSED?  | -> Never seen but possible based on Pi mailbox system channel 8, tag 0x00010005, 0x00010006
* |          |
* +----------+   <---- You get this from Pi mailbox system channel 8, tag 0x00010005 add the two values
* |          |
* |          |
* |   HEAP   | -> getmem allocates from here
* |          |
* |          |
* +----------+
* |          |
* | OS STACK | -> becomes the null process stack of core(s) (size is set by NULLSTK in start.S)
* |          |
* +----------+   <---- _end label from linker file points here
* |          |
* |   BSS    | -> needed for C environment
* |          |
* +----------+
* |          |
* |   DATA   | -> XINU data variables
* |          |
* +----------+   <---- _etext label from linker file points here
* |          |
* |  RODATA  | -> XINU code constants
* |          |
* +----------+
* |          |
* |   TEXT   | -> XINU code
* |          |
* +----------+	  <---- _start address 0x8000 code kicks from here
* |          |
* | RESERVED | -> interrupt handler and vectors go here
* |          |
* +----------+ -> Address 0
*/

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Xinu release

Tue Aug 14, 2018 11:44 pm

I was really looking for a way to setup interrupts in AARCH64. I would imagine that xinu had interrupts working so I thought I could take a look at the code and see how it was done. I attempted it based of bzt's debugger however when I trigger brk #0 it jumps to the wrong address. I would be very grateful if some of you could take a look at the thread. In the meantime is it possible I could see the way that xinu sets up interrupt requests in AARCH64?

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Wed Aug 15, 2018 1:46 am

Now just checking if you are talking about debugging EL1 user mode code I can help. If you are talking about EL2 or EL3 hypervisor debugging I can't never played with it. So assuming user code continue on.

ARM64 hardware timer interrupt code already exists on my repo in the standard blinker example
https://github.com/LdB-ECM/Raspberry-Pi ... /myBlinker

Stick the kernel8.img file from here on your SD card and it will show you it working
https://github.com/LdB-ECM/Raspberry-Pi ... er/DiskImg

The specific code for the handler is called "irq_handler" in
https://github.com/LdB-ECM/Raspberry-Pi ... tStart64.S

It's the stock standard nested handler from the ARM site (the link is in the code) saving all registers BUT not FPU. If you use the FPU in your interrupt code you will need to save them. If you know what registers you trash in the interrupt you can cut back the register saves making the irq faster.

It occurs to me with a timer polling debugger it may be easier to set the debugger up on one core and debug the code on another core.

I also discussed and provided code to handle core timer interrupts on a core other than 0
viewtopic.php?t=214006
I have code on repo as well
https://github.com/LdB-ECM/Raspberry-Pi ... 3Interrupt

You must have setup the core before you start handling interrupts by my smartstart code has always done that :-)
Last edited by LdB on Wed Aug 15, 2018 8:11 am, edited 1 time in total.

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Xinu release

Wed Aug 15, 2018 3:52 am

Sorry for contaminating the thread but yes it is in EL1. I have started a thread called bzt's debugger if you are able to help. I tried .balign instead of .align but that didn't help either.

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Wed Aug 15, 2018 7:12 am

Sure no problems .. Do you have a git repo and I can look at fixing and where is the other thread?

Just made sure my repo was slightly more updated for you if you need to play.
I fully setup the core3 processing interrupt example.
https://github.com/LdB-ECM/Raspberry-Pi ... 3Interrupt

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Xinu release

Wed Aug 15, 2018 8:52 am

Hi LdB,

Here is the link to my GitHub repo: https://github.com/OllieLollie1/Raspi3-Kernel
Here is the thread: viewtopic.php?f=72&t=219693

Some information regarding the error is in the forum thread.

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Mon Aug 20, 2018 9:58 am

If there is anyone with a Pi2 or Pi Zero and has a minute to test some code for me, I would really appreciate it.

Just load the four files on a formatted SD card from here (the code hopefully autoetects Pi model)
https://github.com/LdB-ECM/Exchange/tree/master/Xinu

It takes a few seconds to bind the USB keyboard once you see the xinu message and I haven't got a message to tell you what its doing yet :-)

The ethernet is offline as I need to add the new driver for the Pi3B controller but beside that it should all work.

All the normal commands usbinfo, memstat etc should work.

If you could the run the command "testsuite" it should get down to test 23, 24 and crash as the ethernet is offline.

boochow
Posts: 3
Joined: Thu Feb 08, 2018 2:42 pm
Contact: Website Twitter

Re: Xinu release

Wed Aug 22, 2018 2:54 pm

Hi,

Here is Pi2 results. usbinfo and memstat seem to work well.
rpi2-1.jpg
rpi2-1.jpg (44.31 KiB) Viewed 1152 times
rpi2-2.jpg
rpi2-2.jpg (103 KiB) Viewed 1152 times
Attachments
rpi2-2.jpg
rpi2-2.jpg (103 KiB) Viewed 1153 times
rpi2-1.jpg
rpi2-1.jpg (44.31 KiB) Viewed 1153 times

boochow
Posts: 3
Joined: Thu Feb 08, 2018 2:42 pm
Contact: Website Twitter

Re: Xinu release

Wed Aug 22, 2018 3:01 pm

... and Pi Zero W results:
rpi0w-1.jpg
rpi0w-1.jpg (74.3 KiB) Viewed 1151 times
rpi0w-2.jpg
rpi0w-2.jpg (107.97 KiB) Viewed 1151 times

cwrseck
Posts: 4
Joined: Thu Sep 06, 2018 12:52 pm

Re: Xinu release

Thu Sep 06, 2018 1:02 pm

I've been trying to run Xinu on an RPi Zero W, and haven't had much success.

Adding the Xinu kernel image from the LdB-ECM github repository to the current
Raspbian boot directory and logging in via a serial line doesn't show anything at all,
but a subsequent reset produces:

>Detected platform as: BCM2835, Raspberry Pi
>
> 520093696 bytes physical memory.
> 32768 bytes reserved system area.
> 280612 bytes Xinu code.
> 8128 bytes stack space.
> 502568448 bytes heap space.

so something is going on somewhere.

I'm building under Linux, and so some of the files from from a current
git clone of LdB-ECM need editing.

In the compile/Makefile:
Change RM from "-rm -f" to "rm -f"
Change CP from cpy to mv
Initialise CFLAGS to -std=c99
Remove one of CFLAGS's duplicated -mno-aligned-access options.

In the arm-rpi/platformVars file, replace backslash path separators
with forward slashes.

Compiling with the ARM x86 cross compiler then gave:
[email protected] compile $ make
../loader/platforms/arm-rpi/start.S: Assembler messages:
../loader/platforms/arm-rpi/start.S:83: Error: bad expression -- `ldr r1,=#ARM6_CPU_ID'
../loader/platforms/arm-rpi/start.S:141: Error: bad expression -- `ldr r1,=#ARM6_CPU_ID'
../loader/platforms/arm-rpi/start.S:238: Error: bad expression -- `ldr r1,=#ARM6_CPU_ID'
../loader/platforms/arm-rpi/start.S:243: Error: bad expression -- `ldr r1,=#0x8000'
make: *** [../build/start.o] Error 1
[email protected] compile $

Looking at the code the idea is to load the value at the given address, whereas
the # symbols denote immediate addressing. I removed them, and the compilation
continued. (The other uses of immediate addressing in start.S seemed ok.)

There's also the warning:

../system/platforms/arm-rpi/ctxsw.S:49: Warning: if writeback register is in list,
it must be the lowest reg in the list

which I ignored.

The compilation then blew up with the missing includes:
#include <usbKbd.h>
#include <frameBuffer.h>
The lowercase versions of these files were available, so I linked to them
and went on to a successful build. However, the result was the same as that
given by the prebuilt kernel, shown above.

I'm not clear that I've configured the build correctly for the RPi Zero W;
does anyone know what further flags / configuration files should be set to
give a bootable system?

Many thanks - Will

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Thu Sep 06, 2018 3:16 pm

First have you updated your code to the current repository (it has changed recently). I know you are on an earlier copy because I recently updated the makefile to hopefully be linux compatible. There was something I missed originally which was on the early models the serial port was automatically setup. I had not setup the actual IO port output. Now it's rather easy to prove if that is the problem if you type "uartstat" it will give you send and recieve details and if I am right it will say it has sent output even though you never see it. That being the case just update your sources and you will find the port should now work.

The other choice is I have the wrong serial port on the Pi zero W so the terminal is being opened up on the wrong port.
That is done in platform.inc in ... system\platforms\arm-rpi you will see the different models are detected and the serial port assigned.

Basically there are two choices shown below .. currently the Pi_zero W is set to make the console the first one on the ns16550 compatable miniuart
ns16550_Install(0, "SERIAL0", 0, RPi_IO_Base_Addr + 0x00215040, rpi_MailBoxAccess);
pl011_Install(0, "SERIAL0", 0, RPi_IO_Base_Addr + 0x00201000);

If I have it wrong cut and paste the case the MODEL_PI_ZEROW: to the other grouping it's fairly obvious in the switch statement or just let me know and I will do it. It can only be wrong if this document is wrong which is what I based the code on as I don't actually have one
https://www.raspberrypi.org/documentati ... on/uart.md
By default, on Raspberry Pis equipped with the wireless/Bluetooth module (Raspberry Pi 3 and Raspberry Pi Zero W), the PL011 UART is connected to the BT module, while the mini UART is used for Linux console output.

The context switch code is a warning because they overrun register 13 which is bank switched anyhow it's original xinu code which I have ignored because I actually have a replacement code. Just so you aware of the change which will be pushed tonight and will be documented but for the record.

Xinu as it was on the official repo is specifically soft float only compatible in that in the context switch and interrupt they only save the general registers. If you were to turn on the FPU and hard floats it crashes and burns. What I have done is added compiler detection into the assembler code and it now adds in new sections of code to allow use of the FPU. So you can force a change between the two modes by simply changing the flags on the compiler for hard floats -mfloat-abi=hard, for soft floats -mfloat-abi=soft. Since you have it compiling on your current compiler soft FPU is the default.

Now important the file to change is platformvars in compile\platforms\arm-rpi. AFTER THE CHANGE you must do a clean and libclean and then do a make upon which it will rebuild everything.

The deeper background is xinu does lazy context switching there is no dirty flags to allow marking of partial saves for speed on a switch (something I am going to add). Under soft floats Xinu saves just the 16 registers (1 automatically), under hard FPU it saves 50 registers (1 automatically). The difference is obvious to the user there is quite a speed improvement on almost everything and especially anything with floats. The downside the context switch itself is slower an issue I am dealing with, along with offering a couple of different switcher codes and a there will be a few different multicore options.

If you run across the problem with the letter case problem on the include, can you let me know what file they are in because I am shocked my compiler is letting them thru, it isn't supposed to. You will always have to install the -std=c99 yourself I am targeting the c11 standard but there isn't anything that I use in the newer spec and probably won't be as C99 had most of the stuff I use anyhow.

Good luck and let me know if there is any issues :-)

cwrseck
Posts: 4
Joined: Thu Sep 06, 2018 12:52 pm

Re: Xinu release

Fri Sep 07, 2018 2:39 pm

Thanks for your comments.

I fetched the code on 5 September:
git clone --depth=1 https://github.com/LdB-ECM/xinu.git
I'll do another pull today.

Running grep in the xinu directory I get:

[email protected] ~ $ cd xinu
[email protected] xinu $ grep -R usbKbd.h *
system/platforms/arm-rpi/platforminit.c:#include <usbKbd.h>
[email protected] xinu $ grep -R frameBuffer.h *
device/framebuffer_rpi/framebuffer_Install.c:#include <frameBuffer.h>
[email protected] xinu $

Looking at my comments on the Makefile, CP should be changed to "cp -p"
not "mv" to more closely match Windows. Sorry.

The file compile/data/mytar.tar.o is odd. mytar.tar is corrupt; at least,
tar complains about it but extracts a README file anyway. I rebuilt mytar.tar
to contain just the README, but something still tries to build an object
(.o) file from it.

I changed the tty settings in system/platforms/arm-rpi/platforminit.c to:

ns16550_Install(0, "SERIAL1", 1, RPi_IO_Base_Addr + 0x00215040, rpi_MailBoxAccess);
pl011_Install(27, "SERIAL0", 0, RPi_IO_Base_Addr + 0x00201000);

but once again I get a valid header from the serial port on reset:

Detected platform as: BCM2835, Raspberry Pi

520093696 bytes physical memory.
32768 bytes reserved system area.
280612 bytes Xinu code.
8128 bytes stack space.
502568448 bytes heap space.

and no sign of a shell prompt; I tried entering "uartstat" blind with no result.

Will

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Fri Sep 07, 2018 3:57 pm

Okay I will change the initial stuff for linux compiling. The tar file I know little about it was obviously something in the old conf building system and I will just take it out therefore.

Now I missed one thing so you are getting the initial screen message it's not giving you the bash prompt .. got it now. I will investigate. Put the port back where it was correct as it can't be wrong if you are getting output hence right port and IRQ is firing :-)

You are really deep into the start up process the printed message comes out from system/main.c line 37 which does "print_os_info();" the code is down further in the file line 143.

What it does next is open the ethernet and "standard consoles" up where you can type into
I would suggest you try commenting out the ethernet lines 41 to 52 in system/main.c (you will notice you can define them out but I will resolve if that is issue).

You will notice the very next thing it does should be bring the console up on the serial port.

I can already see one scary thing with that ethernet open code it calls the function pointer blindly without checking for NULL which will be the case if the ethernet detection code fails. Does the PiZeroW have an ethernet is that what is happening?

UPDATED REPOSITORY: I added to code to test for the NULL pointer and fixed those couple of linux issues. I added some extra startup detail so we can see a bit more of what it detects your system as.

cwrseck
Posts: 4
Joined: Thu Sep 06, 2018 12:52 pm

Re: Xinu release

Sat Sep 08, 2018 10:33 am

I cloned the current github repository and replaced the backslash path
separators in the compile/platforms/arm-rpi/platformVars file with
forward slashes. I also edited the #includes in
system/platforms/arm-rpi/platforminit.c
device/framebuffer_rpi/framebuffer_Install.c
to make them lower case.

In system/main.c I commented out the ethernet device initialisation code
and changed cpuid in main.c to platform.model_id to avoid ambiguity in
identification. Recompiling then got me a successful boot-up:

xsh$
Processor identification: 0x0000000C
Detected platform as: BCM2835, Raspberry Pi

520093696 bytes physical memory.
32768 bytes reserved system area.
245340 bytes Xinu code.
8128 bytes stack space.
502602304 bytes heap space.


-----------------------------------------------------
____ ___.__ .___ .__
\ \/ /|__| ____ __ __ | _ \ |__|
\ / | |/ \| | \ | |_| || |
/ \ | | | \ | / | __/ | |
/___/\ \|__|___| /____/ | | |__|
\_/ \/ |/ v3.0Aplha
-----------------------------------------------------

Welcome to the wonderful world of Xinu!
xsh$


The initialisation sequence detects one ethernet device, which
is where the startup hangs.

Running testsuite (with escape codes edited out of the results) gives:

xsh$ testsuite
Test Suite 1: Argument Passing [PASS]
Test Suite 2: Priority Scheduling [PASS]
Test Suite 3: Thread Preemption [PASS]
Test Suite 4: Recursion [PASS]
Test Suite 5: Single Semaphore [PASS]
Test Suite 6: Multiple Semaphores [PASS]
Test Suite 7: Counting Semaphores [PASS]
Test Suite 8: Killing Semaphores [PASS]
Test Suite 9: Process Queues [PASS]
Test Suite 10: Delta Queues [PASS]
Test Suite 11: Standard Input/Output [PASS]
Test Suite 12: TTY Driver [PASS]
Test Suite 13: Character Types [PASS]
Test Suite 14: String Library [PASS]
Test Suite 15: Standard Library [PASS]
Test Suite 16: Type Limits [PASS]
Test Suite 17: Memory [PASS]
Test Suite 18: Buffer Pool [PASS]
Test Suite 19: NVRAM [SKIP]
Test Suite 20: System [PASS]
Test Suite 21: Message Passing [PASS]
Test Suite 22: Mailbox [PASS]
Test Suite 23: Ethernet Driver ../test/test_ether.c:114 ..
../test/test_ether.c:120 ..
../test/test_ether.c:126 ..
../test/test_ether.c:132 ..
../test/test_ether.c:138 ..
../test/test_ether.c:144 ..
../test/test_ether.c:173 ..
[FAIL]
Test Suite 24: Ethernet Loopback Driver [PASS]
Test Suite 25: Network Addresses [PASS]
Test Suite 26: Network Interface [PASS]
Test Suite 27: ARP [PASS]
Test Suite 28: Snoop [PASS]
Test Suite 29: UDP Sockets [PASS]
Test Suite 30: Raw Sockets [PASS]
Test Suite 31: IP [PASS]
Test Suite 32: User Memory [PASS]
Test Suite 33: Simple TLB [SKIP]
xsh$

Interestingly, ethstat gives:

xsh$ ethstat
eth0:
MAC Address F2:95:64:10:6A:A7
MTU 1500
Device state DOWN
Rx packets in queue 0
Rx errors 0
Rx overruns 0
Rx USB transfers done 0
Tx USB transfers done 0
xsh$

xsh$ uartstat
SERIAL0:
STATISTICS:
------------------------------------------
3011 Characters Output
26 Characters Input
0 Characters Overrun
0 Receiver Error Count
416 Output IRQ Count
26 Input IRQ Count
227 Output buffer count
1 oIdle state

INTERRUPT ENABLE:
------------------------------------------
ON Receiver FIFO Reached Trigger Level
ON Transmitter FIFO Empty
OFF Receiver Error or BREAK
OFF Modem Status
SERIAL1:
STATISTICS:
------------------------------------------
0 Characters Output
1 Characters Input
0 Characters Overrun
0 Receiver Error Count
0 Output IRQ Count
1 Input IRQ Count
0 Output buffer count
0 oIdle state

INTERRUPT ENABLE:
------------------------------------------
ON Receiver FIFO Reached Trigger Level
0 UARTRXINTR raw Level
0 UARTRTINTR raw Level
OFF Transmitter FIFO Empty
0 UARTTXINTR raw Level

xsh$

xsh$ usbinfo
[USB Device 001]
[Device Descriptor]
bLength: 18
bDescriptorType: 0x01 (Device)
bcdUSB: 0x200 (USB 2.0 compliant)
bDeviceClass: 0x09 (Hub)
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 64
idVendor: 0x0000
idProduct: 0x0000
iManufacturer: 0
iProduct: 1
(USB 2.0 Root Hub)
iSerialNumber: 0
bNumConfigurations: 1

[Configuration Descriptor]
bLength: 9
bDescriptorType: 0x02 (Configuration)
wTotalLength: 25
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 0xc0
(Self powered)
bMaxPower: 0 (0 mA)

[Interface Descriptor]
bLength: 9
bDescriptorType: 0x04 (Interface)
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 1
bInterfaceClass: 0x09 (Hub)
bInterfaceSubClass: 0x00
bInterfaceProtocol: 0x00
iInterface: 0

[Endpoint Descriptor]
bLength: 7
bDescriptorType: 0x05 (Endpoint)
bEndpointAddress: 0x81 (Number 1, IN)
bmAttributes: 0x03 (interrupt endpoint)
wMaxPacketSize: 0x40 (max packet size 64 bytes)
bInterval: 255



Diagram of USB:

001 [high-speed USB 2.0 Hub class device (USB 2.0 Root Hub) (idVendor=0x0000, idProduct=0x0000)]
xsh$

For some reason I thought that since the RPi Zero W could act as an Ethernet
Gadget it would have an Ethernet chip, but of course it doesn't. Under
Raspbian, the RPi WiFi driver needs the firmware blobs brcmfmac434*-sdio.bin
and their corresponding configuration brcmfmac434*-sdio.txt to work properly,
and the Bluetooth driver needs the BCM43430A1.hcd firmware file. The serial
device /dev/ttyAMA0 then has to be attached to the Bluetooth stack.

None of this is really practical in Xinu; at a guess the wireless chip (?)
confuses one of the network drivers into thinking Ethernet is available.


Will
bnhhh

LdB
Posts: 857
Joined: Wed Dec 07, 2016 2:29 pm

Re: Xinu release

Tue Sep 11, 2018 5:41 am

I have ordered one so I can play around they are so cheap.

It's fairly clear what they are doing on the linux driver code, I just need to be able to check for it before I do the standard Pi ethernet check and it will get over the problem.

So I will undoubtably add an update when it's all done.

cwrseck
Posts: 4
Joined: Thu Sep 06, 2018 12:52 pm

Re: Xinu release

Fri Sep 14, 2018 2:46 pm

The file /home/projects/arm/xinu/compile/platforms/arm-rpi/platformVars
also needs to be edited, with something like:

SEP := / # Linux

# Embedded Xinu device drivers to build into the kernel image
DEVICES := uart \
uart$(SEP)ns16550 \
uart$(SEP)pl011 \
framebuffer_rpi \
usb \
usb$(SEP)dwc2000 \
usbkbd \
null \
raw \
tty \
loopback \
ethernet \
ethernet$(SEP)smsc9512 \
ethernet$(SEP)lan78xx \
ethloop \
tcp \
telnet \
udp \
gpio \
gpio$(SEP)rpi_gpio

Good luck - Will

Return to “Bare metal, Assembly language”

Who is online

Users browsing this forum: No registered users and 5 guests