Dear Tolunay,
in message 42262F9B.7030509@orkun.us you wrote:
I 100% agree that dealing with a separate NOR boot ROM is so much more easier. However, I also see booting from NAND data flash with a small boot readable sector is quickly becoming popular in lower cost/smaller footprint/less power consumption equipment.
Yes - and you shift 90% of the problems that U-Boot is supposed to solve (like easy debugging of the low level initialization sequence) into this "small primary bootstrap loader".
IMHO instead of denying this reality, perhaps we (as U-Boot
I don't deny it. I just tend to ignore it - like I ignore systems running (or crashing) those Windoze "software" ;-)
developers/users) should make some enhancements to deal with this situation in a formal supported way before too many forks occur.
Actually NO enhancements are needed. All is ready and in place, it's just that you don't get any support here for creating the primary bootstrap loader. This is a different issue, which is unrelated to U-Boot. U-Boot can live with suh a situation fine - of course you have to know _exactly_ what you are doing. See for examplethe Atmel AT91RM9200 configuration where all you need to change is the CONFIG_BOOTBINFUNC definition to either use an external bootstrap loader or to have a real self-contained U-Boot image.
U-Boot was defined to solve certain problems that are typical for board bringup; this worked pretty well - just see how many relatively unexperienced developers were able to port U-Boot to their hardware. If you force U-Boot into a hostile environment, the same old problems will have to be solved again - there is nothing U-Boot can do to prevent this. So if you go that route, please don't expect to find much help here on this list.
Best regards,
Wolfgang Denk