[U-Boot-Users] das u-boot and disc on chip
Hello list,
currently I try to bring up a LH7A404 board with a M-Systems G3 Disc on Chip as the boot device. Is it possible to modify das u-boot to be used in such an environment? Or has anyone already made an effort in this direction?
The device has a 2k xip area from where an initial loader could move the rest of das u-boot to ram to execute it from there.
Regards,
In message 42235801.5040600@esem.com you wrote:
currently I try to bring up a LH7A404 board with a M-Systems G3 Disc on Chip as the boot device. Is it possible to modify das u-boot to be used in such an environment? Or has anyone already made an effort in this direction?
I'm not exactly sure what you mean by "boot device". It is no problem to use DoC as boot device for an OS, for example to load a Linux kernel from it and/or use it as filesystem later.
The device has a 2k xip area from where an initial loader could move the rest of das u-boot to ram to execute it from there.
You would have to write your own separate bootstrap loader then. IMHO this is not woth the trouble.
Best regards,
Wolfgang Denk
Wolfgang Denk schrieb:
I'm not exactly sure what you mean by "boot device". It is no problem
In this case the part of the board design which appears at address 0x00 of lh7a404 after reset.
You would have to write your own separate bootstrap loader then. IMHO this is not woth the trouble.
Yes, shouldn't be. Initialise ram, move and jump.
I'm quite new to this arm and embedded linux stuff and played a bit with a kev7a400 board and a patched u-boot-0.45 and now I will use das u-boot with a 2.6-kernel on a small lh7a404-design with mentioned DoC and some sdram and several io's
Any hint or doc-pointer on adaption of das u-boot to this lh7a404 soc? As it is a SoC, there shouldn't be much board-specific stuff to be done for a boot-loader.
Regards,
In message 422424F5.1060908@esem.com you wrote:
You would have to write your own separate bootstrap loader then. IMHO this is not woth the trouble.
Yes, shouldn't be. Initialise ram, move and jump.
I didn't mean to say that, but if you feel like it - ok. Anyway: please see CanUBootBeConfiguredSuchThatItCanBeStartedInRAM.html [Read: don't expect support]
As it is a SoC, there shouldn't be much board-specific stuff to be done for a boot-loader.
Ummm... I'm afraid I have to destroy your illusions. This will be a full port like any other.
Best regards,
Wolfgang Denk
Excuse me if its going OT now. Maybe, you can point me, out of your embedded experience, to a better source.
Wolfgang Denk schrieb:
I didn't mean to say that, but if you feel like it - ok. Anyway: please see CanUBootBeConfiguredSuchThatItCanBeStartedInRAM.html [Read: don't expect support]
Ummm... I'm afraid I have to destroy your illusions. This will be a full port like any other.
no illusions, maybe it sounds like, yes. I'm just thrown into this project with an existing design and looking for solutions. The board consists of an lh7a404(arm922t-core),2x64MB SDRAM,64MB Flash DoC, Ethernet, USB, 2xUART and extension bus, nothing else. My preferred OS is, of course, Linux.
If I understood you right, U-Boot is maybe not the best choice for me, because there are only 2KB XIP Flash available at address 0x00000000 on startup.
Because of the several boot-modes, the lh7a404 offers, I'm thinking in the meantime about to ommit the loader completely and copy the kernel image directly from DoC to ram and jump there.
Regards,
In message 42248E52.8070109@esem.com you wrote:
If I understood you right, U-Boot is maybe not the best choice for me, because there are only 2KB XIP Flash available at address 0x00000000 on startup.
I wouldn't put it like that. IMO your hardware is not the best choice for you because it is missing a proper boot ROM (256 kB flash would be just perfect) to allow you using a decent boot loader without jumping in loops.
Because of the several boot-modes, the lh7a404 offers, I'm thinking in the meantime about to ommit the loader completely and copy the kernel image directly from DoC to ram and jump there.
And who will initialize the hardware for Linux? Who will tell the Linux kernel how much memory you have, and pass all the other bot arguments to it? And how will you get LInux into the DoC in the first place?
It's software, so all things are possible. But not all things are reasonable.
Best regards,
Wolfgang Denk
Dear Wolfgang,
Wolfgang Denk wrote:
In message 42248E52.8070109@esem.com you wrote:
If I understood you right, U-Boot is maybe not the best choice for me, because there are only 2KB XIP Flash available at address 0x00000000 on startup.
I wouldn't put it like that. IMO your hardware is not the best choice for you because it is missing a proper boot ROM (256 kB flash would be just perfect) to allow you using a decent boot loader without jumping in loops.
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.
IMHO instead of denying this reality, perhaps we (as U-Boot developers/users) should make some enhancements to deal with this situation in a formal supported way before too many forks occur.
After all it is supposed to be **Universal** boot loader. ;)
Best regards, Tolunay
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
Wolfgang Denk wrote:
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
Perhaps, there could be a U-Boot project sanctioned primary boot loader framework. Much of the code to do that is already in U-Boot anyway (like common CPU initialization code). Some of the board level initialization code and any board specific code for retrieving U-Boot image would need to be there as well.
Alternatively if you do not like that idea, U-Boot project would formally define the guidelines of operation in a system where primary boot loader is required and state the requirements (state of DRAM, relocation etc) expected from such primary bootloader.
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.
Yes, the developer is expected to know _exactly_ what they are doing in any case with or without a primary boot loader. Porting requires complete understanding of the hardware and software architecture. Much of the same concerns of developing such primary bootloader applies to the board level startup code anyway. There is no substitute...
Defining the guidelines, requirements and the interface would significantly help steer the development in the right direction. It is better than saying not supported but developer has to do it anyway. At least, such formalism would help the process.
Best regards, Tolunay
In message 422641B0.50602@orkun.us you wrote:
Perhaps, there could be a U-Boot project sanctioned primary boot loader framework. Much of the code to do that is already in U-Boot anyway (like common CPU initialization code). Some of the board level initialization code and any board specific code for retrieving U-Boot image would need to be there as well.
I seriously doubt that the existing code could be used. It's build around the central assumption that ease debugging is most important, so for example a serial console port is provided as early as possible, long before even attempting to initialize any system memory (RAM or flash). This pulls in a serial driver, and printf, and ...
Alternatively if you do not like that idea, U-Boot project would formally define the guidelines of operation in a system where primary boot loader is required and state the requirements (state of DRAM, relocation etc) expected from such primary bootloader.
...
Defining the guidelines, requirements and the interface would significantly help steer the development in the right direction. It is better than saying not supported but developer has to do it anyway. At least, such formalism would help the process.
Please feel free to submit such a definition of guidelines, require- ments and interfaces.
Best regards,
Wolfgang Denk
participants (3)
-
Eckhard Doll -
Tolunay Orkun -
Wolfgang Denk