Barebox newbie questions : arch/arm/{plat,mach} split and interrupts

Barebox newbie questions : arch/arm/{plat,mach} split and interrupts

[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 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.

-- 
Robert

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox newbie questions : arch/arm/{plat,mach} split and interrupts

[Sascha Hauer]

Hi Robert,

On Sun, Nov 13, 2011 at 07:29:32PM +0100, Robert Jarzmik wrote:
> 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.

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-*

> 
>  (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.

>      If so, I suppose that active polling for each device is required. Am I
>      right here ?

Yes, you're right.

> 
>  (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.

> 
>  (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

-- 
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
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox newbie questions : arch/arm/{plat, mach} split and interrupts

[Antony Pavlov]

On 13 November 2011 22:29, Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> 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 :)))

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox