ARM Discussions?

Is there a Usenet news group for discussing ARM in general?

I've looked at comp.sys.arm but it looks moribund, only 5 posts over the past year (from Eternal September anyway)

Reply to
Areligious Republican
Loading thread data ...

More online web based fora.

But here is no bad place.

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act. 

- George Orwell
Reply to
The Natural Philosopher

OK, I'll try you as it's really an RPi4 consideration ...

  1. Out of interest, were there to be a 32 bit application running under a 64 bit OS, what actually happens when an interrupt comes along, andinterrupt that might have system-wide importance?

Is it dealt with by the 32 bit IRQ / FIRQ mechanism or does it switch back to the 64 bit?

  1. And this is really an RPi4 consideration. Are the graphics controled by messages left in the postbox, and if so, the full grapics package, normally for the 32 vit Raspbian, would actually be available to 64 bit code?
Reply to
Areligious Republican

On Wed, 13 Nov 2019 12:11:02 +0000, Areligious Republican declaimed the following:

Which OS, out of curiosity -- since Raspbian is only being built as a

32-bit OS in order to be compatible with all hardware variations.

However... Interrupts are normally handled by the kernel, and the kernel would be whatever the OS native width is. To my knowledge, interrupts do not run under user/application context.

Now you are talking the protocol between separate processors. That protocol defines the size of data transfers. I would expect any drivers would have been rebuilt in such a way as to handle any size mismatches between the two processors. If the transfer goes through memory -- well, even a 64-bit processor can write 32/16/8-bit transfers; or it writes a

64-bit transfer and the other processor performs, say, two 32-bit transfers to obtain the same data.

Broadcom has been secretive about the graphics core, but I'd still recommend trying to find the spec sheet (what a misnomer -- I've some that run 1000 pages) for the SoC which may describe the bus widths between ARM and graphics cores, etc.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

Have you tried the raspberrypi.org forums?

Reply to
ray carter

It wouldn't be terrible to crosspost to comp.sys.arm, in the hope of generating some on-topic traffic (and possibly waking up some lurkers).

PS What do you mean about 'ARM in general'? The company? The instruction set? The toolchain? ARM cores (like Cortex A72)?

Theo (added crosspost to c.s.arm)

Reply to
Theo

The interrupt (or any other exception) causes a 64 bit privileged mode to be entered, and is handled by the 64 bit OS. On exit it may return to the 32 bit non-privileged mode the application is running in.

Incidentally, it is also possible on the A53 to run 32 bit OS along side a 64 bit OS using a 64 bit hypervisor. In that case the hypervisor decides which OS the interrupt or exception should be handled by, and either passes it to the 64 bit OS, or invokes the 32 bit mode's IRQ/FIRQ handlers.

---druck

Reply to
druck

That's what I thought which was why I could not see any need for the 32 bit IRQ/FIRQ processing (Actually, answering my own question, it's for when the whole caboodle is running in 32 bit mode)

Yes, and I've yet to read up on the GIC distributing the interrupts.

Reply to
Areligious Republican

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.