[PATCH 3/9] Minimal S5PV210 + Tiny210 support (2nd stage only)

Juergen Beisert jbe at pengutronix.de
Mon May 14 09:07:33 EDT 2012

Hi Alexey,

Alexey Galakhov wrote:
> >> Using iROM to boot is generally a bad idea, but there's no alternative
> >> right now.
> >
> > For you there might be no alternative right now. But for Barebox its all
> > right if only a basic support for this new CPU is available.
> Even if it's not bootable?

At least it can act as a second stage bootloader (network boot for example). 
This is also the stage at which my S3C6410 currently is.

> Ok, there's better plan. Instead of adding iROM in a separate file, I'll
> just call its magic address in board's lowlevel init. So this will be
> for tiny210 only.
> > Skip the iROM entirely in your patch series if you want to remove it
> > later on. What sense would it make to include it and then remove it
> > again?
> It depends on what one means "remove again". This may happen after a
> year or so. While I think I can implement NAND quite fast, I'm not so
> optimistic about MMC.

In this case MMC boot support just not exists. If it will work with an ugly 
solution there is no more pressure to develop a correct solution for it...and 
it will stay forever.
Keep it in your repository if you need it for your work.

> >> However, there's one bad thing: it's better to add at least one board to
> >> Kconfig with the new arch.
> >
> > ?
> If there are no BOARDINFO and board-y defined, barebox cannot be built.
> So one cannot compile barebox with CONFIG_ARCH_something if there are no
> boards utilizing it, right? How to test the compilation then? Is it Ok?

But you can't first add the consumer of a new API (=board file) and after that 
the API itself!


Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

More information about the barebox mailing list