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! jbe -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox