Barebox newbie questions : arch/arm/{plat,mach} split and interrupts
Hi,
As I'm a bit new to barebone, and after reading a bit the code for the ARM architectures, I have questions :
(1) Why is there not anywhere a arch/arm/plat-xxx ?
My understanding is that normally, platform generic code (like gpio handling for XScale processors) should go there.
The machine specific code (ie. PXA27x, PXA25x, etc ...) would still go to arch/arm/mach-pxa.
(2) In arch/arm, I understand that interruptions are never used (do_irq() implementation is quite clear about that). Is that a design decision and why ?
If so, I suppose that active polling for each device is required. Am I right here ?
(3) MMU: one can enable or not the MMU. AFAIR, the MMU is required to enable both I-Cache and D-Cache on ARM achitectures. Are there any other obvious advantages I'm missing in the case of a bootloader ?
(4) Is it possible to have 2 outputs as result of compilation of barebox for a board ?
Let me be clearer. My board, mioa701, has a disk-on-chip on which it can boot. Barebox will be the SPL (written from barebox.bin). The IPL, which is limited to 2048 bytes, will only initialize RAM, GPIOs, and load the SPL. Is there a way for me to add the generation of a 'mioa701_ipl.bin' out of a 'mioa701_ipl.S' ?
Cheers.
Signature · 6 lines
Robert _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Hi Robert,
Quoted 10 lines · Robert Jarzmik
Hi,
As I'm a bit new to barebone, and after reading a bit the code for the ARM architectures, I have questions :
(1) Why is there not anywhere a
arch/arm/plat-xxx?
My understanding is that normally, platform generic code (like gpio handling for XScale processors) should go there.
The machine specific code (ie. PXA27x, PXA25x, etc ...) would still go toarch/arm/mach-pxa.
We put platform generic code to mach-*. The board files are not under mach-* anyway, so these directories do not grow too big. No need for plat-*
Quoted 4 lines
(2) In
arch/arm, I understand that interruptions are never used (do_irq()implementation is quite clear about that). Is that a design decision and why ?
'Design decision' is a strong word, I wouldn't use that here. It's more the way we derived the code from U-Boot. Anyway, I haven't ever really felt the need to implement interrupts. Without interrupts the code becomes simple, no locking needed.
Quoted 2 lines
If so, I suppose that active polling for each device is required. Am I right here ?
Yes, you're right.
Quoted 4 lines
(3) MMU: one can enable or not the MMU. AFAIR, the MMU is required to enable both I-Cache and D-Cache on ARM achitectures. Are there any other obvious advantages I'm missing in the case of a bootloader ?
The I-cache works without MMU, but enabling the D-Cache was the main motivation to turn on the MMU. Another side affect which is not so obvious but nice to have is that with the MMU you can map SDRAM to the vector page and can trap exceptions.
Quoted 8 lines
(4) Is it possible to have 2 outputs as result of compilation of barebox for a board ?
Let me be clearer. My board, mioa701, has a disk-on-chip on which it can boot. Barebox will be the SPL (written from barebox.bin). The IPL, which is limited to 2048 bytes, will only initialize RAM, GPIOs, and load the SPL. Is there a way for me to add the generation of a 'mioa701_ipl.bin' out of a 'mioa701_ipl.S' ?
Currently not, no. Maybe it's worth having a look at the i.MX Nand boot implementation. We have a similar situation there: The initial blob the ROM Code loads to SRAM is 2k. These 2k are responsible for loading the rest of the bootloader. On i.MX we use a single binary for this. The code in arch/arm/mach-imx/internal-nand-boot.c contains the first stage bootcode and the linker puts this at the start of the image using a special section (__bare_init). This code is a bit tricky because it must be written position independent which means that you can't use statically initialized variables. Another thing worth noting is the get_pc() function which returns the current program counter on ARM. With this it's possible to figure out whether we run from SDRAM (so skip SDRAM setup, do not copy from NAND) or from some place outside the SDRAM (so setup SDRAM, copy from NAND). As said, it's a bit tricky, but it makes it possible to start the same image from NOR flash, NAND flash or even as second stage loader from SDRAM.
Sascha
Signature · 9 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Re: Barebox newbie questions : arch/arm/{plat, mach} split and interrupts
In reply to Robert JarzmikQuoted 11 lines · Robert Jarzmik
As I'm a bit new to barebone, and after reading a bit the code for the ARM architectures, I have questions :
...
(2) In
arch/arm, I understand that interruptions are never used (do_irq()implementation is quite clear about that). Is that a design decision and why ?
If so, I suppose that active polling for each device is required. Am I right here ?
Barebox is a firmware. So there are two main requirements for firmware:
* easy adaptation for new board (new board revision);
* small RAM/ROM footprint.
No interrupt support will help you to fulfill the both requirements.
Moreover, if you have a board with some interrupt damage (e.g. PCI interrupt pin broken or
erroneously routed) you can start firmware and easy find the problem.
But if your firmware use the interrupts and your board have broken
PCI interrupts
and console on RS232 connected via PCI when ... you will have very funny hardware quest :)))
Signature · 7 lines
Best regards, Antony Pavlov _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox