Message ID | 1441369343-4638-5-git-send-email-thomas@wytron.com.tw |
---|---|
State | Superseded |
Delegated to: | Thomas Chou |
Headers | show |
On Friday, September 04, 2015 at 02:22:19 PM, Thomas Chou wrote: > As we will use u-boot-dtb.bin, the code relocation range > should be adjusted to accommodate the additional dtb. > It might be overkilled to look into dtb header to find the > dtb size, so we will simply use CONFIG_SYS_MONITOR_LEN. > > Signed-off-by: Thomas Chou <thomas@wytron.com.tw> > --- > arch/nios2/cpu/start.S | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S > index 971bde8..0b16633 100644 > --- a/arch/nios2/cpu/start.S > +++ b/arch/nios2/cpu/start.S > @@ -73,8 +73,9 @@ _cur: movhi r5, %hi(_cur - _start) > ori r5, r5, %lo(_start) /* r5 <- linked _start */ > beq r4, r5, 3f > > - movhi r6, %hi(_edata) > - ori r6, r6, %lo(_edata) > + movhi r6, %hi(CONFIG_SYS_MONITOR_LEN) > + ori r6, r6, %lo(CONFIG_SYS_MONITOR_LEN) > + add r6, r6, r5 > 2: ldwio r7, 0(r4) > addi r4, r4, 4 > stwio r7, 0(r5) Can't you just call relocate_code the same way arm does it in arch/arm/lib/crt0.S ? Best regards, Marek Vasut
Hi Marek, On 09/04/2015 09:59 PM, Marek Vasut wrote: > Can't you just call relocate_code the same way arm does it in > arch/arm/lib/crt0.S ? We didn't include relocation records in nios2 binary image, so there is no real relocation like that of ARM. Altera provides small boot loaders for cfi/sf along with their nios2 jtag flash programmer, which will load the image to the linked address in sdram. The relocating loop in start.S works only if such Altera boot loader is not used, ie, booting directly from cfi flash. Best regards, Thomas Chou
On Saturday, September 05, 2015 at 04:17:05 AM, Thomas Chou wrote: > Hi Marek, Hi, > On 09/04/2015 09:59 PM, Marek Vasut wrote: > > Can't you just call relocate_code the same way arm does it in > > arch/arm/lib/crt0.S ? > > We didn't include relocation records in nios2 binary image, so there is > no real relocation like that of ARM. Can we add them instead ? > Altera provides small boot loaders for cfi/sf along with their nios2 > jtag flash programmer, which will load the image to the linked address > in sdram. The relocating loop in start.S works only if such Altera boot > loader is not used, ie, booting directly from cfi flash. Hm, Im not using the Altera loader :) Best regards, Marek Vasut
HI Marek, On 09/05/2015 08:50 PM, Marek Vasut wrote: >> We didn't include relocation records in nios2 binary image, so there is >> no real relocation like that of ARM. > > Can we add them instead ? I think it is possible. I recalled that we have an old flat image format with elf2flt to run nonmmu uclinux, which does a similar relocation. But I would suggest that we should keep thing simple and small in a boot loader like U-Boot. > >> Altera provides small boot loaders for cfi/sf along with their nios2 >> jtag flash programmer, which will load the image to the linked address >> in sdram. The relocating loop in start.S works only if such Altera boot >> loader is not used, ie, booting directly from cfi flash. > > Hm, Im not using the Altera loader :) > Neither am I. Look like we all use custom boot copiers, and we don't need the relocation in the patch above. It doesn't make sense to copy the code twice. Right? :) Best regards Thomas Chou
On Sunday, September 06, 2015 at 01:28:08 PM, Thomas Chou wrote: > HI Marek, Hi! > On 09/05/2015 08:50 PM, Marek Vasut wrote: > >> We didn't include relocation records in nios2 binary image, so there is > >> no real relocation like that of ARM. > > > > Can we add them instead ? > > I think it is possible. I recalled that we have an old flat image format > with elf2flt to run nonmmu uclinux, which does a similar relocation. But > I would suggest that we should keep thing simple and small in a boot > loader like U-Boot. We already do it on ARM though and the reason for this is to place U-Boot at the end of the DRAM, so that most of the DRAM can be used by the user. > >> Altera provides small boot loaders for cfi/sf along with their nios2 > >> jtag flash programmer, which will load the image to the linked address > >> in sdram. The relocating loop in start.S works only if such Altera boot > >> loader is not used, ie, booting directly from cfi flash. > > > > Hm, Im not using the Altera loader :) > > Neither am I. Look like we all use custom boot copiers, and we don't > need the relocation in the patch above. It doesn't make sense to copy > the code twice. Right? :) In fact, I am loading U-Boot with GDB thus far, so I am only copying it once ;-) Where is the second copying coming from ? Best regards, Marek Vasut
Hi Marek, On 09/06/2015 08:29 PM, Marek Vasut wrote: > We already do it on ARM though and the reason for this is to place U-Boot > at the end of the DRAM, so that most of the DRAM can be used by the user. We place U-Boot at the end of the DRAM on nios2, too. :) I will look into the relocation on nios2 next time. But for now, I would suggest that we skip this and move on to driver model. > In fact, I am loading U-Boot with GDB thus far, so I am only copying it > once ;-) Where is the second copying coming from ? That was true for gdb. But when you need to try out u-boot-dtb.bin on EPCS/sf, it will be another story.. Best regards, Thomas Chou
On Sunday, September 06, 2015 at 03:12:44 PM, Thomas Chou wrote: > Hi Marek, Hi, > On 09/06/2015 08:29 PM, Marek Vasut wrote: > > We already do it on ARM though and the reason for this is to place U-Boot > > at the end of the DRAM, so that most of the DRAM can be used by the user. > > We place U-Boot at the end of the DRAM on nios2, too. :) > > I will look into the relocation on nios2 next time. But for now, I would > suggest that we skip this and move on to driver model. These two things are orthogonal, so no problem :) > > In fact, I am loading U-Boot with GDB thus far, so I am only copying it > > once ;-) Where is the second copying coming from ? > > That was true for gdb. But when you need to try out u-boot-dtb.bin on > EPCS/sf, it will be another story.. Why so? The EPCS is memory mapped and U-Boot starts from it, right ? So U-Boot can relocate itself to the end of DRAM , right ? Best regards, Marek Vasut
Hi Marek, On 09/06/2015 09:18 PM, Marek Vasut wrote: > Why so? The EPCS is memory mapped and U-Boot starts from it, right ? So > U-Boot can relocate itself to the end of DRAM , right ? No. EPCS contains a default boot copier which I said earlier. Please take a look at this, https://www.altera.com/support/support-resources/design-examples/intellectual-property/embedded/nios-ii/exm-alt-boot-methods.html Though the default EPCS boot copier works, it is not easy to update u-boot(-dtb).bin image with u-boot sf command. So I used a modified version, which copies the u-boot image from a fixed location on EPCS/sf to the end of DRAM. Best regards, Thomas Chou
On Sunday, September 06, 2015 at 03:49:20 PM, Thomas Chou wrote: > Hi Marek, Hi, > On 09/06/2015 09:18 PM, Marek Vasut wrote: > > Why so? The EPCS is memory mapped and U-Boot starts from it, right ? So > > U-Boot can relocate itself to the end of DRAM , right ? > > No. EPCS contains a default boot copier which I said earlier. > > Please take a look at this, > > https://www.altera.com/support/support-resources/design-examples/intellectu > al-property/embedded/nios-ii/exm-alt-boot-methods.html > > Though the default EPCS boot copier works, it is not easy to update > u-boot(-dtb).bin image with u-boot sf command. So I used a modified > version, which copies the u-boot image from a fixed location on EPCS/sf > to the end of DRAM. Uh oh, is this copying something the U-Boot SPL cannot do for us ? Sorry, I might be a bit lost in the "official" ways because I'm too used to mainline ;-) Best regards, Marek Vasut
Hi Marek,
On 09/06/2015 11:23 PM, Marek Vasut wrote:
> Uh oh, is this copying something the U-Boot SPL cannot do for us ?
Though U-Boot SPL can do, it will need 64KB onchip memory. While the
EPCS controller needs only 512B onchip memory. So we didn't ever
consider SPL for nios2.
Best regards,
Thomas Chou
On Monday, September 07, 2015 at 02:22:52 AM, Thomas Chou wrote: > Hi Marek, Hi! > On 09/06/2015 11:23 PM, Marek Vasut wrote: > > Uh oh, is this copying something the U-Boot SPL cannot do for us ? > > Though U-Boot SPL can do, it will need 64KB onchip memory. While the > EPCS controller needs only 512B onchip memory. So we didn't ever > consider SPL for nios2. Where did that 64KB figure come from ? :O I assume the simple loader is just a copy loop, huh ? And you synthesise a small RAM or ROM into the FPGA and point NIOS to boot from that, right? What about U-Boot TPL, can that cook the loader ? (yes, I'd like to be as independent of the external code as possible). Best regards, Marek Vasut
Hi Marek, On 09/07/2015 08:53 AM, Marek Vasut wrote: > Where did that 64KB figure come from ? :O This is estimated from 41KB of the SPL of socfpga. The code density of nios2 is worse than ARM. > I assume the simple loader is just a copy loop, huh ? And you synthesise > a small RAM or ROM into the FPGA and point NIOS to boot from that, right? Right. It is hidden from the user in qsys. You will need to dig into the code to find out. The EPCS boot copier is coded in nios2 ASM. > What about U-Boot TPL, can that cook the loader ? (yes, I'd like to be as > independent of the external code as possible). I'd like to be independent of the external code, too. In the past, I have my own SPI core (now the oc_tiny_spi) to control EPCS, which is actually SPI flash, and my own boot copier with/out decompression. It is possible to add an TPL support for nios2 EPCS. If someone want to work on it.. :) Best regards, Thomas Chou
On Monday, September 07, 2015 at 03:47:46 AM, Thomas Chou wrote: > Hi Marek, Hi! > On 09/07/2015 08:53 AM, Marek Vasut wrote: > > Where did that 64KB figure come from ? :O > > This is estimated from 41KB of the SPL of socfpga. The code density of > nios2 is worse than ARM. > > > I assume the simple loader is just a copy loop, huh ? And you synthesise > > a small RAM or ROM into the FPGA and point NIOS to boot from that, right? > > Right. It is hidden from the user in qsys. You will need to dig into the > code to find out. The EPCS boot copier is coded in nios2 ASM. Oh, I see. > > What about U-Boot TPL, can that cook the loader ? (yes, I'd like to be as > > independent of the external code as possible). > > I'd like to be independent of the external code, too. In the past, I > have my own SPI core (now the oc_tiny_spi) to control EPCS, which is > actually SPI flash, and my own boot copier with/out decompression. > > It is possible to add an TPL support for nios2 EPCS. If someone want to > work on it.. :) I'll keep this in mind, thanks :) Best regards, Marek Vasut
diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S index 971bde8..0b16633 100644 --- a/arch/nios2/cpu/start.S +++ b/arch/nios2/cpu/start.S @@ -73,8 +73,9 @@ _cur: movhi r5, %hi(_cur - _start) ori r5, r5, %lo(_start) /* r5 <- linked _start */ beq r4, r5, 3f - movhi r6, %hi(_edata) - ori r6, r6, %lo(_edata) + movhi r6, %hi(CONFIG_SYS_MONITOR_LEN) + ori r6, r6, %lo(CONFIG_SYS_MONITOR_LEN) + add r6, r6, r5 2: ldwio r7, 0(r4) addi r4, r4, 4 stwio r7, 0(r5)
As we will use u-boot-dtb.bin, the code relocation range should be adjusted to accommodate the additional dtb. It might be overkilled to look into dtb header to find the dtb size, so we will simply use CONFIG_SYS_MONITOR_LEN. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> --- arch/nios2/cpu/start.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)