From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Mon, 26 Mar 2007 00:10:35 +0200 Subject: [U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users In-Reply-To: <20070325220126.3466F353C9A@atlas.denx.de> References: <20070325220126.3466F353C9A@atlas.denx.de> Message-ID: <4606F35B.70603@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk skrev: >> Reason for not putting this inside the U-Boot is that due to H/W >> restrictions (internal SRAM size), the max size of the program is 4 kB. > > I'm sorry, but I cannot understand this argument. Because the code is > so small you cannot put it into the U-Boot tree? That makes no sense > to me. It can be put in the u-boot tree, but it needs to be a separate binary OR someone needs to figure out how to make a multi-image binary out of u-boot, and fit the complete at91-bootstrap functionality into the first 4 kB AND make sure that multi-image binary starts with a valid ARM exception table in the first 32 bytes of the binary (this is how the presence of the at91-bootstrap is detected by the AT91 bootROM) All in all, I think it may be a lot easier to keep it as a separate binary. > > To code used for NAND booting for example on PPC 4xx systems has size > limitations, too, but we keep this all in nand_spl/ Where would you suggest it should be? Don't forget that the code supports dataflash as well. The same source will cover several boards, all using chips based on ARM926EJS (At the moment). There is a variant for the AT91RM9200 using I2C EEPROM but it is not using the same code base. Maybe in the future, AVR32 chips will use the same code. Maybe "board/atmel/at91-bootstrap" is a good location. Maybe a completely new directory "boot/atmel/at91-bootstrap". > Maybe you could merge your code into this common infrastructure, too? > Please feel free to discuss details with the NAND custodian. Yes, but there are other things which has priority, like adding existing patches for the SAM926x chips/boards. Pls note, that there is no room for bloating this specific code. >> There is a lot of AT91/U-Boot users, having >> problems with having to have a special compiler >> for this little application, so I thought they would be interested. > > Why do you need a special compiler? > Because the guys writing the original package did not include memset, memcpy, div routines, and thus needs to link with the C library. The C compiler used, must have a statically linked C-library. The "normal" compiler recommended by Atmel, is the LinuxLink toolsets from TimeSys, which cannot compile this. Quite a lot of users, also use a compiler built when making "buildroot". For this purpose I consider everything else "special" I am not implying that having a static C library is esoteric in itself. My goal is to have a single toolset which can build the complete functionality of a Linux Board. This can be the compilers above, ELDK or whatever. The TimeSys compilers cannot build U-Boot as well, since -msoftfloat is hard-coded. I have this as a configuration item in my private u-boot so I can use a "normal" compiler. >> It could of course be in the tools directory. > > No, that would be definitely the wrong place. > > Best regards, > > Wolfgang Denk > -- Best Regards, Ulf Samuelsson -------------- next part -------------- A non-text attachment was scrubbed... Name: ulf.vcf Type: text/x-vcard Size: 313 bytes Desc: not available Url : http://lists.denx.de/pipermail/u-boot/attachments/20070326/97614e79/attachment.vcf