Bare metal BCM43438 Driver

[LdB]

You are posting to someone who had not played with the wifi before yesterday

I am just following this .. read it .. I am doing first steps which is on the SDIO aka SDHost
https://iosoft.blog/2020/03/08/zerowi-part3/

Now the only thing I know is the question he asks why the CRC fails
It is because the Pi SDHost rolls the CRC out of the register ... the SD card does the same.

Code: Select all

It’d be nice to understand why two of the commands have failed CRCs, 
but the Linux driver ignores that error, so I will as well. 
The above sequence is implemented in my code as follows:

I commented the CRC issue on the SDCard host .. .The Pi SDHost cant do CRC it's been cleaved ... hence the linux driver notes the error and ignores it.

Code: Select all

/* The CID is Big Endian and secondly the Pi butchers it by not having CRC */
/*  So the CID appears shifted 8 bits right with first 8 bits reading zero */

Now the blogger manually toggles the SDIO lines to clock the data out. Your code sets up the SDhost properly and fires the data out using it so it is a lot more advanced than his code. However he has nutted out the sequence by parsing massive data dumps so we can simply follow it with the SDHost doing the work.

So now back to code ... so this is the code I am following for step one from the blog
I had to do that because I have reached the end of your code and you haven't provided any more
I don't know what the first 2 lines do yet ... your code doesn't have those functions
So I am picking it up from the second delay and currently I get to sdio_cmd(3, 0, &resp);
So what I am after is a valid rca.

Code: Select all

int rca;
sdio_cmd52(SD_FUNC_BUS, 0x06, 0, SD_RD, 0, 0);   
usdelay(20000);
sdio_cmd52(SD_FUNC_BUS, 0x06, 8, SD_WR, 0, 0);   
usdelay(20000);
sdio_cmd(0, 0, 0);
sdio_cmd(8, 0x1aa, 0);
// Enable I/O mode
sdio_cmd(5, 0, 0);
sdio_cmd(5, 0x200000, 0);
// Assert SD device
sdio_cmd(3, 0, &resp);
rca = SWAP16(resp.rsp3.rcax);
sdio_cmd7(rca, 0);

If you go to the next part on the blog the next thing we are going to do is download the binary to the wifi chip.
There is a clunk here the blogger doesn't do ... I want to handshake with the wifi chip and change the SDIO speed
up to high speed. I do not want to be communicating at 400Khz on what is probably a 100Mhz bus. I assume it
is like SD cards you negotiate the speed. So we are going to have to work that out from the linux driver the blogger
could never do that speed manually.

So at the moment we are following the linux driver but using your functions you got from U-boot and I fixed but following the blog. So it's a mashup of all the different code ... what could possibly go wrong

If you want to jump ahead that is cmd 3 on a normal SDCard on an SDHost
https://github.com/LdB-ECM/Raspberry-Pi ... rd.c#L2433
Note he jumps straight to CMD7 after CMD3 .... on an SDCard you send CMD 9 and engage high speed, I suspect we will do same.

[zeoneo]

You are posting to someone who had not played with the wifi before yesterday

I am just following this .. read it .. I am doing first steps which is on the SDIO aka SDHost
https://iosoft.blog/2020/03/08/zerowi-part3/

Now the only thing I know is the question he asks why the CRC fails
It is because the Pi SDHost rolls the CRC out of the register ... the SD card does the same.

Code: Select all

It’d be nice to understand why two of the commands have failed CRCs, 
but the Linux driver ignores that error, so I will as well. 
The above sequence is implemented in my code as follows:

I commented the CRC issue on the SDCard host .. .The Pi SDHost cant do CRC it's been cleaved ... hence the linux driver notes the error and ignores it.

Code: Select all

/* The CID is Big Endian and secondly the Pi butchers it by not having CRC */
/*  So the CID appears shifted 8 bits right with first 8 bits reading zero */

Now the blogger manually toggles the SDIO lines to clock the data out. Your code sets up the SDhost properly and fires the data out using it so it is a lot more advanced than his code. However he has nutted out the sequence so we can simply follow it with the SDHost doing the work.

So now back to code ... so this is the code I am following for step one from the blog
I had to do that because I have reached the end of your code and you haven't provided any more
I don't know what the first 2 lines do yet ... your code doesn't have those functions
So I am picking it up from the second delay and currently I get to sdio_cmd(3, 0, &resp);
So what I am after is a valid rca.

Code: Select all

int rca;
sdio_cmd52(SD_FUNC_BUS, 0x06, 0, SD_RD, 0, 0);   
usdelay(20000);
sdio_cmd52(SD_FUNC_BUS, 0x06, 8, SD_WR, 0, 0);   
usdelay(20000);
sdio_cmd(0, 0, 0);
sdio_cmd(8, 0x1aa, 0);
// Enable I/O mode
sdio_cmd(5, 0, 0);
sdio_cmd(5, 0x200000, 0);
// Assert SD device
sdio_cmd(3, 0, &resp);
rca = SWAP16(resp.rsp3.rcax);
sdio_cmd7(rca, 0);

If you go to the next part on the blog the next thing we are going to do is download the binary to the wifi chip.

So at the moment we are following the linux driver but using your functions you got from U-boot and I fixed.

I think we are doing it wrong.

First of all

1. SDHOST at offset: #define SDHOSTREGS (PERIPHERAL_BASE + 0x202000)
Will be used for reading sd card, i.e. wifi binary driver will be read from FAT32 using this controller. We are playing with this controller and you are trying to configure this guy for WIFI which is wrong . Holy cow

2. EMMC Controller: at offset 0x300000
This will drive wifi. Now we already have your working driver which uses this controller but it is used to read the sd card.


I think we got it all wrong. We should start with your driver https://github.com/LdB-ECM/Raspberry-Pi ... 2/SDCard.c

a. Change the alt functionality of emmc pins to connect to WIFI
b. Somehow load the wifi binary (Now that we don't have another driver to read files from sdcard we can use ROMFS)
c. Refer linux brcmfmac driver to write ours.


---Update---

That's why uboot driver doesn't have cmd52 commands which are used only in IO mode. SDIO (MEM mode and IO mode). Wifi will be configured using IO functionality.

[LdB]

I don't think so .. I am reasonably sure you are wrong
https://hackaday.io/project/8678-rpi-wifi

The BCM283x SoCs at the heart of every Pi has two MMC controllers. One of these connects to the SD card slot that the Pi boots and runs its OS from. The other has largely been ignored, but comes out on the HAT connector as alternate functions on GPIOs 22-27. Recent kernel and boot blob changes have enabled these pins to be mapped to the MMC controller that also supports SDIO devices.

SDIO started out as an extension of the SD spec to allow for cards that have functionality beyond flash storage. Some PDAs could be expanded to have WiFi or cameras through SDIO. Although smartphones killed the market for SDIO cards by integrating these common features, the bus still lives on as a bridge between SoCs and WiFi modules.

At the time of this writing, the rpi-4.2.y branch of the Raspberry Pi supports the SDIO interface on the HAT connector well. Simply build and install the kernel and edit /boot/config.txt to include the following line:

I am pretty sure all they did is instead of making a hat they put the WIFI module down on the board that is basically what the code is acting like.

I am willing to be wrong but the more I read the code the more I am sure that is what it is doing.

The blogger on the next section ends up with the firmware blob on an EEPROM because he doesn't have the SDCard running and clocks it out that SDHost.

All that says the SDHost connects to the wifi chip and the wifi chip has the SDIO interface and so looks like a standard SD card which is what I think confused you. So there are multiple lines of evidence saying that is how it is and was my understanding.

We will know in a few commands time because I should be able to pull the WIFI chip silicon ID

I should say Initially don't bother reading the binary or doing what he did with eeeprom we will just bininc the binary into kernel8-32.img and so the VC4 will lift it into memory for us

[zeoneo]

I don't think so .. I am reasonably sure you are wrong
https://hackaday.io/project/8678-rpi-wifi

The BCM283x SoCs at the heart of every Pi has two MMC controllers. One of these connects to the SD card slot that the Pi boots and runs its OS from. The other has largely been ignored, but comes out on the HAT connector as alternate functions on GPIOs 22-27. Recent kernel and boot blob changes have enabled these pins to be mapped to the MMC controller that also supports SDIO devices.

SDIO started out as an extension of the SD spec to allow for cards that have functionality beyond flash storage. Some PDAs could be expanded to have WiFi or cameras through SDIO. Although smartphones killed the market for SDIO cards by integrating these common features, the bus still lives on as a bridge between SoCs and WiFi modules.

At the time of this writing, the rpi-4.2.y branch of the Raspberry Pi supports the SDIO interface on the HAT connector well. Simply build and install the kernel and edit /boot/config.txt to include the following line:

I am pretty sure all they did is instead of making a hat they put the WIFI module down on the board that is basically what the code is acting like.

I am willing to be wrong but the more I read the code the more I am sure that is what it is doing.

The blogger on the next section ends up with the firmware blob on an EEPROM because he doesn't have the SDCard running and clocks it out that SDHost.

We will know in a few commands time because I should be able to pull the WIFI chip silicon ID

If we can enable wifi using the SDHOST then it should be the best thing I have heard in while.

I have never read anywhere nor seen any code example which uses sdhost controller to drive wifi.

LInux:
bcm2835-sdhost: To read the sd card .
emmc: Full blown sdio controller used to drive wifi

Same goes for the Plan9 port by Richard Miller.

One more thing it has limitation and it doesn't follow standards. I believe it's customized for single use case hence everyone uses it for reading sd card. https://github.com/ms-iot/rpi-iotcore/t ... 36/rpisdhc

FreeBsd folks call it rubbish : https://reviews.freebsd.org/rS335779 Check the source code very similar to uboot's

Code: Select all

	// FOllowing lines connect EMMC controller to wifi
    for ( uint32_t i = 34; i <= 39; i++)
    {
        select_alt_func(i, Alt3);
        if (i == 34)
            disable_pulling(i); // Pull off
        else
            pullup_pin(i);
    }

	// This connects sdhost to sd card
	for (uint32_t i = 48; i <= 53; i++) {
		
		// select_alt_func(i, Alt0);
		if(i == 0x30) {
			disable_pulling(i);
			printf("Disable pulling \n");
		} else {
			pullup_pin(i);
		}

        select_alt_func(i, Alt0);
    }

So this code is connecting sd host to sd card which wouldn't work if we try sdio (IO) commands like cmd52 cmd53 etc.
Anyway there is no other code base to refer if we go by sdhost -> wifi. Only way possible I see is emmc-> wifi.

"We will know in a few commands time because I should be able to pull the WIFI chip silicon ID " If you do that then I don't know what to call you. The Teacher __/\__

[LdB]

The link you just gave I think tells you why it's hooked thru the emmc code
https://github.com/ms-iot/rpi-iotcore/t ... 36/rpisdhc

The driver works in conjunction with sdport.sys, which implements SD/SDIO/eMMC protocol and WDM interfaces.

It seems to be clear on different models there may be different things hanging off that 2nd MMC controller.
However literally every code I have looked at may call it EMMC but they have the wifi hanging off that Arasan MMC controller using the MMC interface which is some non standard SDHost. That is why I can't port the other SDHost because the Arasan one is weird.

Anyhow either a MOD will chime in hopefully or I will get the sucker talking

[zeoneo]

Anyhow either a MOD will chime in hopefully or I will get the sucker talking

Funny.
If you see something like cmd1 in sdhost.c then remove it and use cmd instead. After that rectification I tried to read the ocr and csd from the card. It's all 0xffffffff didn't work.

[LdB]

If it does that I don't know how you talk to the wifi module there simply is no connection. Show me some code that drives the wifi from an EMMC host because I have no idea how that layer sits on the second MMC and none of the code you have in your repo does that nor anything you have shown me.

I seriously think I have reached the end of the line because I don't get how you connect it. You get that an EMMC has to have a physical interface and I need to see code for it? You just took what I thought was the physical interface away and connected it to the SD card. You are saying I am firing commands on the Arasan MMC and they are going to the SD card. So where is my MMC controller for the Wifi interface? I need an MMC controller connected to the wifi and some code on how to do that because I can't just guess at it.

I am basically confused and with no documentation not willing to waste anymore time on this.

[zeoneo]

If it does that I don't know how you talk to the wifi module there simply is no connection. Show me some code that drives the wifi from an EMMC host because I have no idea how that layer sits on the second MMC and none of the code you have in your repo does that nor anything you have shown me.

I seriously think I have reached the end of the line because I don't get how you connect it.

Here is what @9Pi said

Not bare metal strictly speaking, but the Plan 9 driver is another alternative example you might want to look at for information. It's under 2400 lines of C, so it should be a bit easier to follow than the Linux brcmfmac driver. To write the Plan 9 driver without a device spec, I had to read all the brcmfmac code which is a 32,000+ line spaghetti of support for multiple chips and interface methods: not an experience I would recommend for pleasure.

Plan 9 driver source is at https://9p.io/sources/contrib/miller/9/bcm/ether4330.c, depends on the emmc driver (another 529 lines) in https://9p.io/sources/contrib/miller/9/bcm/emmc.c for sdio support.

I never said my code works or even close to working. I did try ether4330.c ported code it didn't work so I trashed it. I couldn't debug only with printfs. I started fresh again.

I have your sd_Fat32 driver working which is using EMMC I was hoping to use this for wifi later, it might need some changes like adding CMD52 support.

First step: I would make sdhost driver working and use it read Fat32 sd card (This helps in loading driver files from card to main memory. Even if I don't do it now then in future in case someone/me get the wifi working I will still need sdhost driver for file system).

2nd Step:
PINS 48-53 are connected to the sd card using SDIO . So by switching 48-53 to Alt0 we can make a connection : SD Card <-> SDHOST
PINS 34-39 are connected to wifi chip using SDIO: Switch 34-39 to Alt3 that will make a connection : WIFI <-> EMMMC

This code : https://9p.io/sources/contrib/miller/9/bcm/ether4330.c internally calls the MMC functions to talk to wifi.

Code present in this directory does the same: https://github.com/raspberrypi/linux/tr ... 1/brcmfmac It's not clearly visible that which SDIO controller they are using but by reading comments it;s clear they are indeed using EMMC to control wifi.

Check the pin confi here: https://github.com/raspberrypi/linux/bl ... b.dts#L101
https://github.com/raspberrypi/linux/bl ... -b.dts#L88

[LdB]

You don't need to do step one for now just bininc the wifi binary into your kernel8-32.img and the VC4 will load it along with your kernel image. So that steps is completely unneccessary and can be done down the track. You could have equally just used the existing SDcard reader code as is (so I don't get why the SDCard etc is even being discussed). Basically I don't get your step one at all (not even remotely ... you are taking running code that reads an SDcard and moving it to another controller .... why????)

So I will ignore that just incbin the binary and move on. If you want to do that I am not remotely interested because I simply don't get why you would do it. So I am interested in step 2 your on your own on step 1, personally I think it's crazy.

My problem is step 2 I have no idea what MMC you are connecting the wifi with.
The eMMC is just the name for an MMC controller that the device is not removable and it has no 1 wire mode.
https://electronics.stackexchange.com/q ... mc-storage

So are we are clear this is physical I need MMC controller hardware!!!!!!!
So if I am going to connect an eMMC to the wifi I need to know where the hell the wifi MMC controller is.

I assumed it was the second one and you are saying no your code connects that second MMC controller to the SD card. I have no idea why anyone would connect the second MMC back to the SD card which already has an MMC controller .

So moving on this macro will lift the wifi binary into kernel8-32 and it's position tagged so we know where it starts and ends. It uses the assembler command of including binary called ".incbin" which we call with inline assembler from the C compiler. So we are using the VC4 FAT reader to lift the image at the same time as the kernel and our kernel file will grow by the wifi binary size. So currently your binary is about 70K it will jump to 70K + size of wifi binary when you do this.

This is the macro place at top of your main.c file

Code: Select all

#if !defined(__STRINGIFY2)
#define __STRINGIFY2(__p) #__p
#define __STRINGIFY(__p) __STRINGIFY2(__p)
#endif

#define INCLUDE_BINARY_FILE(__variable, __fileName, __section)					 \
__asm__ (                                                                        \
    ".pushsection " __section                                          "\n\t"    \
    ".globl " __STRINGIFY(__variable) "_start;"                        "\n\t"    \
    ".balign 4"                                                        "\n\t"    \
    __STRINGIFY(__variable) "_start: .incbin \"" __fileName "\""       "\n\t"    \
    ".globl " __STRINGIFY(__variable) "_end;"		                   "\n\t"    \
    __STRINGIFY(__variable) "_end: .4byte 0;"                          "\n\t"    \
    ".balign 4"                                                        "\n\t"    \
    ".popsection"                                                      "\n\t"    \
);\
extern const uint8_t __variable ## _start;\
extern const  uint8_t __variable ## _end;

Now anywhere in your main code put the call of the macro it doesn't execute any code it is an instruction to the compiler at compile time to load the file into .rodata section data and mark some tags for us. So it can go anywhere after the "int main (void) {"

Code: Select all

INCLUDE_BINARY_FILE(wifibinary, "somewifibinary.bin", ".rodata.wifibinary"); // <== name of binary file include path if need
uint32_t binarysize = (uint32_t)&wifibinary_end - (uint32_t)&wifibinary_start; // This is just a check this size matches you binary

So that is step 1 completely dealt with with about 15 lines of code and I don't need to even talk about FAT reading and SD cards. So I have the wifi binary loaded and ready to go .. so if you are interested in doing step 2 with me can you tell me what you have worked out.

So step 2 ... I need to know where the MMC controller for the wifi is ... So I need address? Any code? SO if you can help with those let me know.

[zeoneo]

By eMMC I mean well documented Araasan controller which supports SD and SDIO standard implementation.

Base Address: PERIPHERAL_BASE + 0x300000


Cypress Wifi chip is connected to PIN 34-39. If you choose Alt3 alternate function for 34-39 it will be talking to Arasan Controller I mentioned above.

Step1. Choose Alt3 for 34-39
Step2: Initialize Arasan Controller and you already have the code which is used for Reading SD card using Arasan Controller. We need to modify that driver to remove SD read part OCR/CSD etc.
Step3: Throw sequence of SDIO commands to wifi chip using Arasan controller.

For the start we can look at below sequence or the

Code: Select all

0.000331 74 00 00 0c 00 39 * Cmd 52 00000C00 Rd BUS  00006
0.002759 74 80 00 0c 08 9f * Cmd 52 80000C08 Wr BUS  00006 08
0.025217 40 00 00 00 00 95 * Cmd  0 00000000
0.028130 48 00 00 01 aa 87 * Cmd  8 000001AA
0.028527 45 00 00 00 00 5b * Cmd  5 00000000
0.028660 3f 20 ff ff 00 ff ? Rsp 63 20FFFF00
0.028875 45 00 20 00 00 3d * Cmd  5 00200000
0.029007 3f a0 ff ff 00 ff ? Rsp 63 A0FFFF00
0.029228 43 00 00 00 00 21 * Cmd  3 00000000
0.029353 03 00 01 00 00 eb * Rsp  3 00010000
0.029690 47 00 01 00 00 dd * Cmd  7 00010000
0.029815 07 00 00 1e 00 a1 * Rsp  7 00001E00

Or checkout the Plan9's code. I believe it's working couldn;t verify though. It seems they ported it for Pi4 as well.

Code: Select all

static void
sdioinit(void)
{
	ulong ocr, rca;
	int i;

	/* disconnect emmc from SD card (connect sdhost instead) */
	for(i = 48; i <= 53; i++)
		gpiosel(i, Alt0);
	/* connect emmc to wifi */
	for(i = 34; i <= 39; i++){
		gpiosel(i, Alt3);
		if(i == 34)
			gpiopulloff(i);
		else
			gpiopullup(i);
	}
	sdio.init();
	sdio.enable();
	sdiocmd(GO_IDLE_STATE, 0);
	ocr = trysdiocmd(IO_SEND_OP_COND, 0);
	i = 0;
	while((ocr & (1<<31)) == 0){
		if(++i > 5){
			print("ether4330: no response to sdio access: ocr = %lux\n", ocr);
			error(Eio);
		}
		ocr = trysdiocmd(IO_SEND_OP_COND, V3_3);
		tsleep(&up->sleep, return0, nil, 100);
	}
	rca = sdiocmd(SEND_RELATIVE_ADDR, 0) >> Rcashift;
	sdiocmd(SELECT_CARD, rca << Rcashift);
	sdioset(Fn0, Highspeed, 2);
	sdioset(Fn0, Busifc, 2);	/* bus width 4 */
	sdiowr(Fn0, Fbr1+Blksize, 64);
	sdiowr(Fn0, Fbr1+Blksize+1, 64>>8);
	sdiowr(Fn0, Fbr2+Blksize, 512);
	sdiowr(Fn0, Fbr2+Blksize+1, 512>>8);
	sdioset(Fn0, Ioenable, 1<<Fn1);
	sdiowr(Fn0, Intenable, 0);
	for(i = 0; !(sdiord(Fn0, Ioready) & 1<<Fn1); i++){
		if(i == 10){
			print("ether4330: can't enable SDIO function\n");
			error(Eio);
		}
		tsleep(&up->sleep, return0, nil, 100);
	}
}

https://9p.io/sources/contrib/miller/9/bcm/ether4330.c

SDIO api referred in above snippet is implemented here.

https://9p.io/sources/contrib/miller/9/bcm/emmc.c

So for our step 1 we could compare the emmc.c and https://github.com/LdB-ECM/Raspberry-Pi ... 2/SDCard.c. Then remove the unused part of SDCard.c and add any new methods which may be related to CMD52 (IO).

I think ether4330.c is single file and we can understand the code flow.

This could be good starting point.

[LdB]

So for our step 1 we could compare the emmc.c and https://github.com/LdB-ECM/Raspberry-Pi ... 2/SDCard.c. Then remove the unused part of SDCard.c and add any new methods which may be related to CMD52 (IO).

Nope actually your code is better because it is running and already on the Araasan controller you just connected it to the SD card. My original SD code is for the other EMMC controller and it is very different.

I am cleaning up a new start point which I will throw up on github in an hour or so.

[zeoneo]

So for our step 1 we could compare the emmc.c and https://github.com/LdB-ECM/Raspberry-Pi ... 2/SDCard.c. Then remove the unused part of SDCard.c and add any new methods which may be related to CMD52 (IO).

Nope actually your code is better because it is running and already on the Araasan controller you just connected it to the SD card. My original SD code is for the other EMMC controller and it is very different.

I am cleaning up a new start point which I will throw up on github in an hour or so.

Your code is for same controller called Arasan(check the address) . You just were reading sd card with that now we will use it to communicate with wifi. I don't know why are you confused about it. We have only two controllers. The custom sdhost by broadcom which is not standard and other one is Arasan eMMMc controller which implements full specifications(so we need this) .

[LdB]

Why it seems to be a problem because you are calling the one at PERIPHERAL_BASE + 0x300000 the Arasan

So ever since 2014 we have called the other one the Arasan
viewtopic.php?t=246767

I already have the sdhost controller working fine and I will use that one to access the sd going further, but I'd like to try my luck on getting the wifi chip working in bare metal, so I need the arasan one to work.

So you were and still are confusing the hell out of me because you are the only one calling that an arasan.
I have no documentation for the arasan the same as this guy.

So the one at PERIPHERAL_BASE + 0x300000 is the one my code references and is the one that connects by default to the SD Card.
To me that isn't the arasan it's the one in datasheet BCM2835.pdf

Your code defines this in SDHost.c
#define SDHOSTREGS (PERIPHERAL_BASE + 0x202000UL)

So if you have a datasheet for (PERIPHERAL_BASE + 0x202000UL) can you link it please.


So in a nutshell that is why you are confusing me ... because you are going against what we have always called it. At the end of the day it's a name lets drop that name.

So how about we call them the SDHost on the BCM2835 datasheet and the one not on the BCM2835 datasheet.
So my code is for the one on the BCM2835 datsheet and every register in my code even details what page.

[rst]

FYI The Plan 9 ether4330.c and emmc.c drivers are working well on the RPi 3B, 3B+ and 4B with only slight modifications. I have built an emulation framework for the Plan 9 kernel environment with Circle and these drivers run successfully in it:

Code: Select all

logger: Circle 41.2 started on Raspberry Pi 3 Model B+
...
00:00:03.24 wifi: ether4330: chip 0x4345 rev 6 type 1
00:00:03.75 wifi: ether4330: firmware ready
00:00:03.95 wifi: ether4330: addr B8:27:EB:5F:...
00:00:07.25 kernel: Compile time: Mar 14 2020 10:22:14
00:00:07.25 wifi: channel: 0
00:00:07.25 wifi: essid: TEST
00:00:07.26 wifi: crypt: off
00:00:07.26 wifi: oq: 0
00:00:07.26 wifi: txwin: 68
00:00:07.26 wifi: txseq: 28
00:00:07.27 wifi: status: associated
00:00:07.31 dhcp: IP address is 192.168.179.23
Mar 14 10:23:35.27 ntpd: System time updated

The only problem is, that it is working without authentification only (open network) at the moment. WPA2 is not working at all and WPA seems to need an EAP over LAN protocol implementation, because I'm receiving a packet with EtherType 0x888E from the access point.

Despite of this the Plan 9 drivers are a great foundation for implementing bare metal Wi-Fi.

[zeoneo]

Why it seems to be a problem because you are calling the one at PERIPHERAL_BASE + 0x300000 the Arasan

So ever since 2014 we have called the other one the Arasan
viewtopic.php?t=246767

I already have the sdhost controller working fine and I will use that one to access the sd going further, but I'd like to try my luck on getting the wifi chip working in bare metal, so I need the arasan one to work.

So you were and still are confusing the hell out of me because you are the only one calling that an arasan.
I have no documentation for the arasan the same as this guy.

So the one at PERIPHERAL_BASE + 0x300000 is the one my code references and is the one that connects by default to the SD Card.
To me that isn't the arasan it's the one in datasheet BCM2835.pdf

Your code defines this in SDHost.c
#define SDHOSTREGS (PERIPHERAL_BASE + 0x202000UL)

So if you have a datasheet for (PERIPHERAL_BASE + 0x202000UL) can you link it please.


So in a nutshell that is why you are confusing me ... because you are going against what we have always called it. At the end of the day it's a name lets drop that name.

So how about we call them the SDHost on the BCM2835 datasheet and the one not on the BCM2835 datasheet.
So my code is for the one on the BCM2835 datsheet and every register in my code even details what page.

Check the page 65 it says Arasan Tm in the section introduction to external mass media controller.


Anyway we should go for the sdhost on the bcm2835 datasheet page 65. Everyone is using that to drove wifi. We will code have references. Definitely this one.


Other one is undocumented as you said and can be understood from Linux source. Unfortunately it's still difficult for me to understand that.

[zeoneo]

FYI The Plan 9 ether4330.c and emmc.c drivers are working well on the RPi 3B, 3B+ and 4B with only slight modifications. I have built an emulation framework for the Plan 9 kernel environment with Circle and these drivers run successfully in it:

Code: Select all

logger: Circle 41.2 started on Raspberry Pi 3 Model B+
...
00:00:03.24 wifi: ether4330: chip 0x4345 rev 6 type 1
00:00:03.75 wifi: ether4330: firmware ready
00:00:03.95 wifi: ether4330: addr B8:27:EB:5F:...
00:00:07.25 kernel: Compile time: Mar 14 2020 10:22:14
00:00:07.25 wifi: channel: 0
00:00:07.25 wifi: essid: TEST
00:00:07.26 wifi: crypt: off
00:00:07.26 wifi: oq: 0
00:00:07.26 wifi: txwin: 68
00:00:07.26 wifi: txseq: 28
00:00:07.27 wifi: status: associated
00:00:07.31 dhcp: IP address is 192.168.179.23
Mar 14 10:23:35.27 ntpd: System time updated

The only problem is, that it is working without authentification only (open network) at the moment. WPA2 is not working at all and WPA seems to need an EAP over LAN protocol implementation, because I'm receiving a packet with EtherType 0x888E from the access point.

Despite of this the Plan 9 drivers are a great foundation for implementing bare metal Wi-Fi.

Is this effort open source? It will be great help to compile and play with plan9 drivers

[rst]

Is this effort open source? It will be great help to compile and play with plan9 drivers

I will push the source code to a branch in the Circle repo in a few days. I have to clean-up the code a bit before. I will give a notice here, when it is done.

[LdB]

Just to clarify one last thing because this get even messier on the Pi4 and I will show you the comment I am questioning.

Check the page 65 it says Arasan Tm in the section introduction to external mass media controller.

Yes we know that and AFAIK so is the new 3rd one on the Pi4 ... just no-one ever called it that because it was always called the BCM one.
So we are dropping that name and now it gets really freaky on the Pi4 ... ready

So on the Pi 4 there is another SD controller that supports DDR50 it is the default SD card. The old BCM controller that used to be on the SD card is now used for the WiFi. The undocumented sdhost controller that was on WiFi by default is now spare.

So now when you say this below it can mean multiple things depending on Pi model. So on a Pi3 to do that they have changed the SD controllers around from default while on a Pi4 it would be in default.

Anyway we should go for the sdhost on the bcm2835 datasheet page 65. Everyone is using that to drove wifi. We will code have references. Definitely this one.

So there is nothing wrong just be aware this gets even worse on the Pi4 and AFAIK they are all Arasan controllers but two different people could make different things from that statement.

[zeoneo]

Just to clarify one last thing because this get even messier on the Pi4 and I will show you the comment I am questioning.

Check the page 65 it says Arasan Tm in the section introduction to external mass media controller.

Yes we know that and AFAIK so is the new 3rd one on the Pi4 ... just no-one ever called it that because it was always called the BCM one.
So we are dropping that name and now it gets really freaky on the Pi4 ... ready

So on the Pi 4 there is another SD controller that supports DDR50 it is the default SD card. The old BCM controller that used to be on the SD card is now used for the WiFi. The undocumented sdhost controller that was on WiFi by default is now spare.

So now when you say this below it can mean multiple things depending on Pi model. So on a Pi3 to do that they have changed the SD controllers around from default while on a Pi4 it would be in default.

Anyway we should go for the sdhost on the bcm2835 datasheet page 65. Everyone is using that to drove wifi. We will code have references. Definitely this one.

So there is nothing wrong just be aware this gets even worse on the Pi4 and AFAIK they are all Arasan controllers but two different people could make different things from that statement.

Let's follow something and get this thing started. It's confusing I agree. As rst said Plan9 works so we can get started with that.

[rst]

@zeoneo Quicker than expected I could push the development sources of the ported Plan 9 Wi-Fi driver to the wifi branch in the Circle repo. Please read this issue for details.

[zeoneo]

I was able to compile wifi /sample after toolchain upgrade but it does not send any uart response after booting.

I have enable_uart=1 and core_freq=250Mhz hard coded in config.txt

Even after commenting that it didn't work.

I compiled fot RASPI 3 32 bit

[rst]

I was able to compile wifi /sample after toolchain upgrade but it does not send any uart response after booting.

I have enable_uart=1 and core_freq=250Mhz hard coded in config.txt

Even after commenting that it didn't work.

I compiled fot RASPI 3 32 bit

The sample program needs a HDMI display by default. You have to create a file cmdline.txt with this contents to use the UART:

Code: Select all

logdev=ttyS1

You do not need a config.txt in 32-bit mode.

[zeoneo]

Thanks Rsta. I was still facing the issue with my bootloader and uploading kernel binary.


@LdB I am able to read the chip id using this

https://github.com/zeoneo/rpi-3b-wifi/b ... mmc-sdio.c
https://github.com/zeoneo/rpi-3b-wifi/b ... /wifi-io.c

Code: Select all

####################
Inside Bootloader
Boot Atags Addr: 2EFF9900 
####################
Requesting kernel
00001018 sending size in hex: a510 42256 
### sending kernel kernel8-32.img [42256 byte]
sending size: 10 ffffffa5 0 0 
receiving size: 1 2 3 4 5 6 7 8
receiving size: 0 0 0 0 A 5 1 0
### finished sending
Jumping token: JUMP��������������@�

----8 -------------Kernel Started Dude........................
timer_regs:3f003000registering GPU1 IRQ1 

 Kernel End: 0x182000 
EMMC: reset card.
EMMC: setting clock speed to 400000.
Divisor = 105, Freq Set = 396825
 Clock setup completeregistering GPU1 IRQ2 
 IRQ2: 0 
 After IRQ2: 40000000 
  Card reset complete 
returning from interrupt clearer. 
returning from interrupt handler. 
 Sent go idle command 
Found card OCR : 0x20ffff00
NEW OCR : 0xa0ffff00
rca: 0x1 
EMMC: setting clock speed to 25000000.
Divisor = 4, Freq Set = 10416666
 +++++Enabled SDIO IO functionality 
returning from interrupt clearer. 
returning from interrupt handler. 
registering GPU1 IRQ1 
returning from interrupt clearer. 
returning from interrupt handler. 
returning from interrupt clearer. 
returning from interrupt handler. 
cfgreadl 18000000: a6 a9 41 15
Chip Id a9a6 43430 
<---------------Wifi Started Successfully----------------->

[rst]

@zeoneo You're welcome. In the meantime my driver can associate and authenticate to a WPA2 enabled network. I have some issues, but it is working using the method to take the Plan 9 driver as it is (with some slight modifications) and build an environment around.

I have to say, that the author of the Plan 9 driver did a really impressive job. This driver is not perfect, but it works and is much easier to understand and to use than the Linux driver in bare metal.

Currently I'm porting the WPA Supplicant software to Circle. It's already working, WPA2 wouldn't work otherwise, but not finished. I currently do not know, what will be the result of this. The whole Wi-Fi stuff is very complex and the question is, if it is possible to get this stable enough to be really useful.

[zeoneo]

@zeoneo You're welcome. In the meantime my driver can associate and authenticate to a WPA2 enabled network. I have some issues, but it is working using the method to take the Plan 9 driver as it is (with some slight modifications) and build an environment around.

I have to say, that the author of the Plan 9 driver did a really impressive job. This driver is not perfect, but it works and is much easier to understand and to use than the Linux driver in bare metal.

Currently I'm porting the WPA Supplicant software to Circle. It's already working, WPA2 wouldn't work otherwise, but not finished. I currently do not know, what will be the result of this. The whole Wi-Fi stuff is very complex and the question is, if it is possible to get this stable enough to be really useful.

Yes, he is very experienced in this.

@9Pi thanks again