sanasrikar
Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

My doubts in understanding baremetal

Wed Oct 18, 2017 9:13 am

hi all,
i am learning to write baremetal code for the raspberry pi 3. actually i have started learning it.
and my confusion from the start it is there with mailboxes.

i have some few questions which are listed below could some please help me in clearing those

1. Are the mailboxes which dwelch is talking about in the below link are they GPU mailboxes ?
https://github.com/dwelch67/raspberrypi ... er/multi00

2. if we write the address where the desired code which we need our cores to execute is present in the address 0x4000009c etc.,. will the GPU make our cores to jump directly to those locations
our core 0 has written some address x in the address 0x4000009c so will the GPU will take the respective core to that location ? or is it we need to keep core 1 in loop where it continuously checks whether any thing has been written or not in that address or is it zero or non zero if it is nonzero then jump to that address and if it is zero continue checking it
3. After we power up our rpi how many cores are available only single core is available or all core starts executing the instructions from the address 0x8000

4. Assuming all our cores are released so say if i write a file called startup.s whose code is placed in the top and in that if i make all our cores expect core -0 to sit in a loop as i explained in question 2
here i used 0x40000090 -core 1 ,0x400000A0 -core 2, 0x400000B0-core3
1. i will ask my core to read the value present at the address i will ask core 1 to read at the address 0x40000090 etc.,.
2.if it is non zero i will ask that core to jump to that particular address and start executing from there
3. if it is zero then i will make my core to repeat from the step 1
will this method succeed ? will i be able to land my cores at the place i need to and can i make different cores execute different codes ?
and using those address will they bring me any conflicts ?

timanu90
Posts: 61
Joined: Sat Dec 24, 2016 11:54 am

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 11:10 am

Hello

1. No, those are not the GPU mailboxes, those mailboxes are used for inter core communication mainly.

All your other questions depend on the way you choose to boot your rpi. If you don't use the config.txt "trick", the GPU start the arm at address 0x00 that runs a piece of softare developed by the foundation that park the 3 other cores for you on those addresses you mentioned and make the core 0 jump to 0x8000, where you can take control. (Personally I don't like this method).

The other method is to creat a config.txt file with some parameters that tell the GPU to not load the foundation code, making you have full access of the 4 cores at address 0x00.

sanasrikar
Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 11:57 am

where do we need to write the address to where our cores need to parked to ? in the config.txt ?

so if we write the address in the config.txt then does the gpu makes the cores park at that address

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

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 12:10 pm

You have been told this multiple times except item 4 which probably has never been discussed because it's not often used.

1.) The ARM processor by default would start at 0x0000 go and look at the ARM processor datasheets

2.) So if the CPU is being given to you at 0x8000 (or 0x80000 on AARCH64) it has come thru some code which is documented and available in the Raspberry Pi foundation firmware directory

3.) The current armstubs park cores 1,2,3 in a holding loop which seems to have some underlying hardware/software feature.
The write address being
0x4000008C, 0x4000009C, 0x400000AC, 0x400000BC
The Read address is offset 0x40 to each core
0x400000CC, 0x400000DC, 0x400000EC, 0x400000FC respectively.
All of that is detailed in that QA7 datasheet

4.) You can get all 4 cores at 0x0000 by using config.txt with kernel_old = 1. However it is the old way it was done and may disappear and you have to take responsibility for doing the other special startup things the armstub does.

Now the area 0x4000xxxx is special it has all sorts of stuff as documented in QA7. It is setup BY THE GPU and many GPU control IRQ and functions are there but it isn't specifically part of the GPU. It is some sort of special area that the ARM and the GPU can access.
I know it does on occassion get called the GPU mailbox to differentiate it from the Normal Pi Mailbox system which just so happens to also
talk to the GPU but also every other peripheral. So yes it can get confusing but not once you know what you are doing you know which people are talking about, just by what they are doing. There are no repeat functions in both I know of.

So be clear there are two mailbox systems and they both can talk to the GPU and they both talk to many other things. You seem to be getting confused so how about you call the one at 0x40000xxxxx, QA47 mailbox after the datasheet to save confusion.
sanasrikar wrote:
Wed Oct 18, 2017 11:57 am
so if we write the address in the config.txt then does the gpu makes the cores park at that address
You don't see item 4 .... 0x0 or 0x8000 are only choices. There is no parking of anything at 0x0 you get the cores from boot as in cycle 1 after reset ... hence you are responsible to do the special register setup.

I also patched you code so it works correctly .. look at that.

sanasrikar
Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 12:36 pm

thanks for the reply deboer....
until now i thought every core comes to 0x8000 and we make them go our defined mailboxes.
Even though people told me this many times i got confused for the mailboxes that we used and in startup.s files and to the GPU mailboxes and totally ignored it.

i was not knowing first they will first loop over GPU mailboxes and then come to our defined mailboxes (if any present ) but guys where did you found this info that at the start armstub files will be there or GPU will park them at some address and will loop on continously.

i read the qA7 doc but i havent found. i think i have missed it . could some one please tell me where is this info located ?

like after powering GPU will take them to this addresses and only core0 is released etc.,.

But i am very glad that you people made me understand in proper way.
i am really grateful to you guys. until now i was in a wrong idea but now i am confident how it happens.

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

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 12:39 pm

In talking to sanasrikar there is something I don't specifically know so lets throw it out there because some of you guys have done a lot more with the core IPC.

https://www.raspberrypi.org/documentati ... rev3.4.pdf
Page 7 and 8

0x4000_008C Core 0 Mailbox 3 write - set (WO)
0x4000_00CC Core 0 Mailbox 3 read & write - high - to -clear

0x4000_009C Core 1 Mailbox 3 write - set (WO)
0x4000_00DC Core 1 Mailbox 3 read & write - high - to -clear

0x4000_00AC Core 2 Mailbox 3 write - set (WO)
0x4000_00EC Core 2 Mailbox 3 read & write - high - to -clear

0x4000_00BC Core 3 Mailbox 3 write - set (WO)
0x4000_00FC Core 3 Mailbox 3 read & write - high - to -clear

The datatsheet simply says "There is no difference between any of the four mailboxes assigned to a core. It is left to the programmer
to decide how to use them".

https://github.com/raspberrypi/tools/bl ... armstub7.S
mbox: .word 0x4000008C ???? .... A very specific magic number hard coded into the stub

What do QA7 Mailbox 0,1,2 do to each of the cores do ... linux thing?????
Seeking the answer why does the armstub specifically choose mailbox 3 for each core? If the other mailboxes are for different things I guess it self answers.

I guess pragmatically I am asking why didn't it go for mailbox0 AKA the first one?
Last edited by LdB on Wed Oct 18, 2017 12:52 pm, edited 1 time in total.

sanasrikar
Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 12:52 pm

And i would even propose this
some one to write some sticky post as one had done for baremetal resources ....

Me , a person who doesnot know many programming knowledge and much knowledge about multi core processors... that sticky notes will be very useful

i mean this is just a suggestion but if it is there it will help novice people like me
thank you all

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

Re: My doubts in understanding baremetal

Wed Oct 18, 2017 12:54 pm

Most start with single core programming ... multicore is an advanced topic :-)

I would also say we give you working samples to follow. You still have a couple of big issues to go you haven't got the FPU online at the moment a problem that will quickly bite if you try to do any maths ... big warning !!!!

Even on the Pi3 you get delivered only 1 core and 1 core is a lot easier than multicore. The old walk before you run :-)

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: My doubts in understanding baremetal

Thu Oct 19, 2017 9:48 am

LdB wrote: Now the area 0x4000xxxx is special it has all sorts of stuff as documented in QA7. It is setup BY THE GPU and many GPU control IRQ and functions are there but it isn't specifically part of the GPU. It is some sort of special area that the ARM and the GPU can access.
dwelch67 wrote:
Thu Oct 19, 2017 3:39 am
to me a mailbox is just a shared memory location and that is how it is used here. it is the same as the ones used with the GPU in that it is just a memory location, nothing fancy, the processors on both sides know where this location is and have agreed ahead of time on how to use it.
I think you are both incorrect!

The area at 0x40000000 is not part of the GPU it is the ARM control block and has mailboxes, interrupt routing, timer and counter.

The mailboxes are not memory, they are a piece of hardware, they have separate set and read/clear registers and can generate interrupts, not things that memory can do.

You could use memory for a mailbox but without an interrupt you will just poll the address over and over, a very bad thing to do when trying to create good designs.
LdB wrote: So be clear there are two mailbox systems and they both can talk to the GPU and they both talk to many other things
So you know for your future learning @LdB, there is no GPU on other side of mailbox at 0x40000000, take care when reading documents.

dwelch67
Posts: 845
Joined: Sat May 26, 2012 5:32 pm

Re: My doubts in understanding baremetal

Thu Oct 19, 2017 12:37 pm

That was my second draft, and should have just tossed it too. After sleeping on it was going to toss those replies anyway, didnt like how I had written them.

Well understood that some mailboxes are special hardware not just memory. But calling it a "mailbox" doesnt automatically make it special hardware in general and that was the point. If it does have special hardware then great, makes it that much easier to use (get an interrupt for example, rather than have to poll). And if that is why they built in four per core, great...Good for us. The interrupt is NOT used in the bootstrap code that the broadcom/pi folks left for us, or at least the code I examined, they can at any time change that code at will and the next time I/we update our sd cards we suck in that new code. But it should still function the same otherwise it will create some pain, have to get the linux distro and the bootstrap to match. Why didnt they setup an interrupt, go into a wfi and stop burning bus cycles?

The "mailbox"es in question were used initially as a shared memory that one side polled and the other wrote. What you do after that is up to you.

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

Re: My doubts in understanding baremetal

Thu Oct 19, 2017 3:33 pm

StevoD wrote:
Thu Oct 19, 2017 9:48 am
So you know for your future learning @LdB, there is no GPU on other side of mailbox at 0x40000000, take care when reading documents.
I understand what you are saying but you are splitting hairs it controls things like the IRQ's to the GPU. Are signal lines like the IRQ part of the GPU or part of peripherals or just general circuitry or something else you can argue until the cow come home it's a SOC we can't see the physical divisions and circuitry. I mean it could be a cross point switch, special circuitry writing thru to a register on the GPU, the GPU running thru and polling memory as a software register (David covers in last sentence)... the question is how would you know?

Like David I also initially considered 0x4000xxxx was just a special cache memory area . It was only when I saw the read/clear was offset 0x40 from the write and was high to clear, I realized it was probably hardware (but we can't exclude the other alternatives without seeing the circuit). The reality is it changes nothing and you gain nothing by knowing what you think may be a new truth, the operation is just the same for either system. The interesting part about the GPU is it isn't as clean a separation as people imagine or as described in the documentation, it's simplified I found that out bigtime playing around with the VC4 and GLES. Lots of these layers are deliberately abstracted away from us and presented simpler than reality so they can change the hardware in future revisions or firmware upgrades. I would also say there are a whole pile of what seem to be memory acting as software registers to the GPU on the GLES/MMAL system.

I am a bit like David however, lots of this is complication fluff that doesn't change anything. So happy to agree it's hardware with you because it's meaningless in terms of writing code for it.

There is one final problem for you to ponder in AARCH64 even the default stub doesn't use what you are calling hardware at 0x4000xxxx. You can also pick any normal area of memory and run your spinlock in AARCH32 other than what you are calling hardware and it will work. Just remove the 0x40 offset and write zero back when you read the value. So now the question becomes what does your hardware do?

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

Re: My doubts in understanding baremetal

Thu Oct 19, 2017 5:30 pm

To make the last point blunt
https://github.com/LdB-ECM/Exchange/tre ... /Multicore

One hyperthreading sample using some random data memory address as the spinlock mailbox
0000d1c4 d Core0Spin
0000d1c8 d Core1Spin
0000d1cc d Core2Spin
0000d1d0 d Core3Spin

I didn't even choose the address I just placed them in the data segment wherever they happen to fall.
So if there is hardware at 0x4000008C etc what exactly is it's function to the cores?
I am happy to have it as hardware but surely you can see it would be a lot of effort for nothing in this instance.
My thoughts are much like Davids this may be historic or something to do with linux.

My point to Sanasrikar was if you worry about hardware at 0x4000xxxx is you end up thinking that the hardware
is doing something or required for the operation ... which is totally wrong. That is why I tell him to ignore it.

Spinlock modifications to do the above .. just write a zero to clear address after you load it.

Code: Select all

SecondarySpin:
mrc     p15, 0, r0, c0, c0, 5
ands r0, r0, #0x3   // Make core 2 bit bitmask in R0
	
// Code for supposedly hardware mailbox
//ldr r5, =mbox		
//ldr r5, [r5] @ mbox
//add	r5, #(0x400000CC-0x4000008C)

mov	r3, #0 @ magic

// Just somewhere in plain normal memory
ldr r5, =Core0Spin

SecondarySpinLoop:
wfe

// Code for supposedly hardware mailbox
//ldr	r4, [r5, r0, lsl #4]

// Just somewhere in plain normal memory
ldr	r4, [r5, r0, lsl #2]               

cmp	r4, r3
beq	SecondarySpinLoop
@ clear mailbox
// Code for supposedly hardware mailbox
//str	r4, [r5, r0, lsl #4]

 // Zero spinlock somewhere in plain normal memory
str	r3, [r5, r0, lsl #2] 

mov	r0, #0
ldr r1, =machid		
ldr r1, [r1]
ldr r2, = atags		
ldr r2, [r2]
ldr lr, =SecondarySpin
bx	r4
b SecondarySpin
Hopefully you see why I am pragmatic and careful taking the cutdown, hacked datasheet which has a number of known errors at face value and even it doesn't tell you what it is hardware it just describes a "register" space :-)

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: My doubts in understanding baremetal

Sat Oct 21, 2017 10:26 am

dwelch67 wrote: Well understood that some mailboxes are special hardware not just memory. But calling it a "mailbox" doesnt automatically make it special hardware in general and that was the point.
LdB wrote: It was only when I saw the read/clear was offset 0x40 from the write and was high to clear, I realized it was probably hardware
LdB wrote: You can also pick any normal area of memory and run your spinlock in AARCH32 other than what you are calling hardware and it will work.
There is no point to discuss this with you any more, you both agree that ARM control and mailbox is hardware not memory, but still you continue to argue the case instead of to learn, accept and move on.
LdB wrote: One hyperthreading sample using some random data memory address as the spinlock mailbox
You can make a mailbox in memory, without interrupt you must loop and poll, while CPU polls no work is done!

Postscript: Please take care of your terminology – hyperthreading spinlock

User avatar
rpdom
Posts: 11838
Joined: Sun May 06, 2012 5:17 am
Location: Essex, UK

Re: My doubts in understanding baremetal

Sat Oct 21, 2017 10:35 am

Someone seems to be confusing "memory address" with physical memory. They are not the same. The mailboxes are access through an address on the memory bus. That doesn't mean they are using actual memory storage.

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

Re: My doubts in understanding baremetal

Sat Oct 21, 2017 4:20 pm

SteveD if you have feel we are missing something then explain away, I have simply shown you what I have learned about the ARM hyperthread behaviour. David has already stated the cores have a WFI instruction, which can be used to hook the cores up in interrupt mode. It is easy to setup that sample to activate cores on interrupt, I have samples that do that as well. That is all I know and I don't claim it is in any way complete and in some ways I am a newbie.

Now your link is mostly about Intel the only discussion of ARM is about using the technology but then deciding not to and use 2012 64-bit design(No idea what that means). I am no expert in this area, I am a simple coder monkey and nothing in there stands out as having relevance. You seem to be indicating it has relevance but I am not skilled enough to see it, so can you explain it to my much more basic level.

I also thought (perhaps incorrectly) the use of the WFE/WFI instructions took it from a polled spinlock (your 1st statement). In my samples just posting the address to the mailbox is not enough the core remains sleeping, you have to execute a SEV to wake them up after you post the new address. It's not a behaviour I would traditionally called polled, it's more what I would call event driven. I have examples where I set the address but I don't post a SEV until I want the execution. Moreover you talk about while it's doing polling it's not doing work but it's only "polling" because there is nothing to do and that is why I put the cores to sleep with WFE/WFI? If you or anyone has accurate terminology I would be keen to learn.

I do know at least the difference with SMP and AMP and have got a small code running on the GPU so I can use it in AMP with ARM cores which is a bit funky. I am currently working on a re-enterent library to try and do something useful with it. Again I am just a coder doing my best to learn this stuff by playing with it.

What you didn't explain is what you think the purpose of the hardware is? That is the bit most confusing to me it seems to serve no purpose. If you have any idea I am really interested in knowing. This area is obviously something you have experience in so please help a poor pleb out :-)

rpdom I am not sure who you were commenting to or about, in my sample above the "spinlock mailbox" is most definitely memory, I know I set it up (memory address 0x0000d1c4-0x0000d1d0) and would be memory on any model PI. However in general for my part I have stated all along there is no real way to know what we are actually hitting at any memory address. That really comes home in AARCH64 when everything is virtualized you simply have no way to know if you are writing to physical hardware or just some virtual memory space. So I go even more extreme than your statement, that unless you set it up it is never clear exactly what you are interfacing with on the ARM just treat it as a register space.

rst
Posts: 289
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: My doubts in understanding baremetal

Sat Oct 21, 2017 7:37 pm

LdB wrote:
Sat Oct 21, 2017 4:20 pm
What you didn't explain is what you think the purpose of the hardware is? That is the bit most confusing to me it seems to serve no purpose.
Local Mailbox 0 can be used in Linux to send an Inter-Processor-Interrupt (IPI) from one core to another. You can use this, if one core wants another core to do something else. This is implemented here, but I don't know if it is actively used in the kernel. I'm using this in Circle to halt all cores if a panic condition occurs on one core.

Local Mailbox 3 is used in the firmware stub to park the secondary cores after boot, as you know. This could probably be implemented using some location in main memory too, as it is done in the 64-bit stub.

I guess local mailbox 1 and 2 and are not used in Linux. Correct me, if I am wrong. This local register block at 0x40000000 has probably been designed in hardware, when it was not completely clear, what is needed for the software. So there are more features available than are really used.

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

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 7:20 am

rst wrote:
Sat Oct 21, 2017 7:37 pm
Local Mailbox 0 can be used in Linux to send an Inter-Processor-Interrupt (IPI) from one core to another. You can use this, if one core wants another core to do something else. This is implemented here, but I don't know if it is actively used in the kernel. I'm using this in Circle to halt all cores if a panic condition occurs on one core.
rst you are the man ... finally some detail.

I had looked thru the sources and never found that detail, because if I haven't made a mistake it is not in use in the current kernel. If I am reading the version numbers correctly it looks like it was in use in with the Pi2 but seems to have changed with the changes for the Pi3 when the bootstub changes.

I like your code more stuff to play with :-)
rst wrote:
Sat Oct 21, 2017 7:37 pm
Local Mailbox 3 is used in the firmware stub to park the secondary cores after boot, as you know. This could probably be implemented using some location in main memory too, as it is done in the 64-bit stub.
Yep I had worked all that from the Arm8 stub and actually gave an example using normal memory above, and hence my confusion.
rst wrote:
Sat Oct 21, 2017 7:37 pm
I guess local mailbox 1 and 2 and are not used in Linux. Correct me, if I am wrong. This local register block at 0x40000000 has probably been designed in hardware, when it was not completely clear, what is needed for the software. So there are more features available than are really used.
Ok so my guess that it was historic might not be far from the mark. I was guessing that the hardware may have been designed to stop race conditions, would that be the likely reason for the design of it?

Can I ask you, SteveD mentioned my terminology is wrong. So what is the correct terminology for the spinlock when we use WFE/WFI is it still a polled spinlock or something else?

Can I ask if you wouldn't mind looking at my SD/Wifi question you are one who is likely to know the answers. Having played with the VC4 and the shader compiler producing VC4 opcodes, I realized I should be able to setup an AMP cluster with the idle GPU cores and the ARM cores. The FFMPeg sample on userland retasks the GPU cores in a specific way I am wanting to do a more general AMP retasking. In baremtal I believe there are 8 GPU cores basically doing nothing.

Thankyou for your adding to my knowledge.

rst
Posts: 289
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 9:18 am

LdB wrote:
Sun Oct 22, 2017 7:20 am
I had looked thru the sources and never found that detail, because if I haven't made a mistake it is not in use in the current kernel. If I am reading the version numbers correctly it looks like it was in use in with the Pi2 but seems to have changed with the changes for the Pi3 when the bootstub changes.
I'm not very familiar with the Linux kernel versions. I took the default branch (rpi-4.9.y) from the raspberrypi/linux repo for searching and found that irq-bcm2836 driver there. I guess it is used for the RPi 3 too. At least there is that "sev" call included, which is required for recent firmwares. So this is not old stuff.
I was guessing that the hardware may have been designed to stop race conditions, would that be the likely reason for the design of it?
You mean, because the local mailboxes have a "set" and a "clear" register? Maybe.
Can I ask you, SteveD mentioned my terminology is wrong. So what is the correct terminology for the spinlock when we use WFE/WFI is it still a polled spinlock or something else?
Excuse me, I'm not sure, if I want to get involved in your (theoretical) discussion. ;)
Can I ask if you wouldn't mind looking at my SD/Wifi question you are one who is likely to know the answers.
I did read your questions, but I don't know the answers. I was dealing with the Linux mmc code as some time for the same reason, but I did not continue. Despite that implementing WiFi in bare metal is a huge task, it is also not clear to me, if it's legal. WiFi is regulated because it is using the radio spectrum. You also need crypto code, which is regulated in some countries. At least this makes the situation much more complicated.

See: https://wireless.wiki.kernel.org/en/dev ... regulatory

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

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 2:09 pm

rst wrote:
Sun Oct 22, 2017 9:18 am
"sev" call[/url] included, which is required for recent firmwares. So this is not old stuff.
The sev only wakes the core up it isn't related to using or not using the hardware register, so you sort of confused me there. I was talking about the mailbox hardware use in linux.
rst wrote:
Sun Oct 22, 2017 9:18 am
You mean, because the local mailboxes have a "set" and a "clear" register? Maybe.
Yes I assume they were thinking it would protect them from race conditions.
rst wrote:
Sun Oct 22, 2017 9:18 am
Excuse me, I'm not sure, if I want to get involved in your (theoretical) discussion. ;)
Umm okay but I still don't know if I am using the right term but you seem to understand me.
rst wrote:
Sun Oct 22, 2017 9:18 am
Despite that implementing WiFi in bare metal is a huge task, it is also not clear to me, if it's legal. WiFi is regulated because it is using the radio spectrum. You also need crypto code, which is regulated in some countries. At least this makes the situation much more complicated.
I have coded modules like this before so it's not so be will be fun compared to the VC4.

The emission etc is covered by Pi Foundation they have EMC approval (via Element14) and will have had to test with worse case
https://static.raspberrypi.org/files/co ... CC_DSS.pdf
https://static.raspberrypi.org/files/co ... CC_DTS.pdf

I have a number of products with FCC and Australian C-Tick approval.

My only responsibility will be to not select illegal bands if the chipset allows channel selection, which I wont know until I get there. Some modules do allow the extra channels, some don't but I suspect the Pi will do extras because it is multinational. The linux driver is opensource so it's fairly easy to follow. It also seems cypress has licensed the module and has a datasheet for it
http://www.cypress.com/file/298076/download
Should help with details it is saying BCM43438 = CYW43438 :-)

rst
Posts: 289
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 3:25 pm

LdB wrote:
Sun Oct 22, 2017 2:09 pm
My only responsibility will be to not select illegal bands if the chipset allows channel selection, which I wont know until I get there. Some modules do allow the extra channels, some don't but I suspect the Pi will do extras because it is multinational. The linux driver is opensource so it's fairly easy to follow.
I suppose the chipset of the RPi 3 allows channel selection, because you have to select your WiFi country in the Raspbian configuration tool. I found this database which should contain the required info. But regulatory data may change and you may be responsible to keep it up-to-date. There could also be programming errors which may cause the regulations to be injured.

For a commercial project I would probably rate this differently, but for a private (hobby) open-source project my chance/risk estimation is negative. Of course it may be different for you, with your experience in this field.

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

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 3:36 pm

rst wrote:
Sun Oct 22, 2017 3:25 pm
But regulatory data may change and you may be responsible to keep it up-to-date. There could also be programming errors which may cause the regulations to be injured.
Nope the module has a special mode where it throws out the maxium it can possibly do no matter code you send at it.

If you doubt my info feel free to ask Jamesh he has the details of even how to get it into the special mode if you need to do further EMC testing for a country not covered. It is compliant to CE, FCC and C-Tick which covers Europe, USA, Australia and New Zealand. I think he said they were doing Canada ICES-003 but that was just memory .. check with him.

FCC server is playing up atm but this is all the FCC approval documentation for the PI3. Those approvals are complete for any software running on the device.
https://apps.fcc.gov/oetcf/eas/reports/ ... ABCB-RPI32

The special mode is probably also described in the CYPRESS datasheet above (can't say I looked) .. nice to have a full datasheet for a change.

rst
Posts: 289
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: My doubts in understanding baremetal

Sun Oct 22, 2017 5:32 pm

OK. Thanks for info! Perhaps I have to re-think this, when I have some time.

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 3 guests