ml300 boot loader question

ml300 boot loader question

[Lou Rickard]

I'm having a hard time figuring out how to boot our
kernel/filesystem on the ml300.  I suspect it's a
problem with the bootloader, but not 100% sure.

We're able to generate a file to program the FPGA with
that will allow us to use the BDI2000 to boot the
system.  From trial and error, I've gotten the
impression that the FPGA file includes a bootloader of
some kind: when we didn't include some of the binary
firmware with the FPGA file we couldn't even get the
BDI2000 to boot the system.  When we started including
the binary firmware stuff (which I don't quite
understand yet), the system came up to a state where
we could boot with the BDI2000.

So, based on that, I'm guessing that the systemace
chip fills the bram with some sort of bootloader
sometime around when it programs the FPGA.

However, I haven't been able to build a FPGA file that
would actually boot to a linux filesystem on the flash
card.  The FPGA programs, but then nothing happens
(this is with the BDI2000 unplugged, I don't think any
software can be run with the BDI2000 plugged in unless
it's downloaded via the BDI2000, but I could very well
be incorrect).

I've looked at the Monta Vista partitions that came
with the kit.  I don't see any kind of stand alone
boot loader, so I'm guessing that they have included
their bootloader with the FPGA file.  I don't know if
this is a modification of the bootloading binaries
that come with the Xilinx development kit.

Could anyone clue me in?

Thanks,

~lr


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Peter Ryser]

Lou,

there are two parts involved in booting a Linux system on the Virtex-II
Pro FPGA on the ML300:

1. a bitstream that programs the FPGA. The bitstream is created with the
EDK kit from scratch or based on the EDK reference design for ML300
available at
http://www.xilinx.com/ise/embedded/edk_examples.htm (design # 6)
2. a Linux kernel created

Then, there are two main methods on how to bring up Linux.

a. With Impact and a SW debugger (BDI2000)
b. With System ACE CF.

In both cases first the bitstream is loaded to program the FPGA and the
then Linux kernel is loaded through the processor into main memory.
If  you use method a) you first program the FPGA with Impact and then
use the BDI2000 to download the Linux kernel into main memory. The
BDI2000 will then also set the PC to the start address of the Linux
kernel and on your command start executing the code.

If you use method b) you use EDK to generate an ACE file for example in
an EDK shell type
xmd genace.tcl -jprog -board ml300 -hw implementation/download.bit -elf
<path to linux kernel> -ace top.ace
See the EDK documentation for more details.

Now, copy the resulting top.ace file onto the MicroDrive shipping with
ML300, for example, into xilinx/myace. Set the rotary dial that selects
which configuration is loaded by the System ACE chip to the correct
number. When you hit the System ACE reset button the System ACE CF chip
starts loading the ACE file and as part of the process loads the FPGA
bitstream, downloads the Linux kernel into main memory, and boots Linux.

- Peter


Lou Rickard wrote:

>I'm having a hard time figuring out how to boot our
>kernel/filesystem on the ml300.  I suspect it's a
>problem with the bootloader, but not 100% sure.
>
>We're able to generate a file to program the FPGA with
>that will allow us to use the BDI2000 to boot the
>system.  From trial and error, I've gotten the
>impression that the FPGA file includes a bootloader of
>some kind: when we didn't include some of the binary
>firmware with the FPGA file we couldn't even get the
>BDI2000 to boot the system.  When we started including
>the binary firmware stuff (which I don't quite
>understand yet), the system came up to a state where
>we could boot with the BDI2000.
>
>So, based on that, I'm guessing that the systemace
>chip fills the bram with some sort of bootloader
>sometime around when it programs the FPGA.
>
>However, I haven't been able to build a FPGA file that
>would actually boot to a linux filesystem on the flash
>card.  The FPGA programs, but then nothing happens
>(this is with the BDI2000 unplugged, I don't think any
>software can be run with the BDI2000 plugged in unless
>it's downloaded via the BDI2000, but I could very well
>be incorrect).
>
>I've looked at the Monta Vista partitions that came
>with the kit.  I don't see any kind of stand alone
>boot loader, so I'm guessing that they have included
>their bootloader with the FPGA file.  I don't know if
>this is a modification of the bootloading binaries
>that come with the Xilinx development kit.
>
>Could anyone clue me in?
>
>Thanks,
>
>~lr
>
>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Jon Masters]

Peter Ryser wrote:

| downloads the Linux kernel into main memory, and boots Linux.

Has anyone here had problems with designs that work fine when built with
EDK 3.2 subsequently falling over completely with EDK 6.1?

At the moment I am debugging a possible issue with memory controller
logic and would love to hear these are known issues with fixes.

Cheers,

Jon.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Mike Wellington]

All I know is that Xilinx customer support told me that EDK 3.2 and
EDK 6.1 are incompatible with each other.   Also be sure to get the
service packs for EDK 6.1 and ISE 6.1.   Inside the service packs
was a utility called "revup" which I used to convert my "pre-service pack"
designs to run under 6.1+Service Pack.  I think there are instructions
on the Xilinx website where you find the Service Pack telling you how
to upgrade your designs.

-mike wellington
  wellington@lucent.com



Jon Masters wrote:

>
>
> Peter Ryser wrote:
>
> | downloads the Linux kernel into main memory, and boots Linux.
>
> Has anyone here had problems with designs that work fine when built with
> EDK 3.2 subsequently falling over completely with EDK 6.1?
>
> At the moment I am debugging a possible issue with memory controller
> logic and would love to hear these are known issues with fixes.
>
> Cheers,
>
> Jon.
>
>



--

=mike wellington
wellington@lucent.com
303.920.6412  Desk
720.434.7559  Cell


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Jon Masters]

Mike Wellington wrote:

| All I know is that Xilinx customer support told me that EDK 3.2 and
| EDK 6.1 are incompatible with each other.

Oh this I know.

Everything should in theory work but right now I am having to run my own
Linux port with cacheing disabled under 6.1 and am tracing some weird
alignment issues or somesuch other problem with certain accesses through
the memory controller to SDRAM. I will get it this week I hope.

Spent most of last week manually tracing the Linux startup process,
validating every TLB entry by hand[0] and patching instructions with
hexedit/gdb since hardware breakpoints still do not seem to be working
correctly through xmd in that you cannot con after stopping properly.

Sometimes I have seen potential cacheline corruption but I am not sure
where the problem is yet and whether it is hardware flakiness or
software not doing something it should be doing. However I have now
created a consistent crash scenario where a particular structure used by
the glibc rtld is being courrupted on the way up and am hopeful that I
can this week track down exactly what causes it to get fscked.

Jon.

[0] So I now understand the ppc405 TLB handling code far more than I did
even a week ago. I love doing this kind of thing sometimes.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Jon Masters]

Hi there,

The breakage is happening inside an mmap call when using dynamically
linked binaries and only when not tracing the process running.

Offset in r8 is broken and I am not sure yet whether this is purely a
hardware corruption of the kernel stack or a subtle kernel bug.

Jon.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ml300 boot loader question

[Jon Masters]

Jon Masters wrote:

> Offset in r8 is broken and I am not sure yet whether this is purely a
> hardware corruption of the kernel stack or a subtle kernel bug.

Ho hum... *whistles to self quietly*. Let me clarify stuff.

I am working on an internal project based on my own Virtex II Pro port
and firmware (no redboot or ppcboot) which runs on the Insight Memec rev
3. V2PFG456 board - for those not familiar then this basically is an
FPGA with an IBM 405D processor inside. Something similar to Mind.

Now the problem I am seeing for those who are interested or might have
seen similar problems with EDK6.1 generated hardware:

The port has been working fine running busybox, webservers, a userland
based upon ptxdist and so on et al. This is based upon a hardware
generated using Xilinx EDK3.2 with some custom modules for ethernet and
in house hardware stuff. The system boots from SystemACE etc.

An upgrade to Xilinx EDK6.1 resulted in generated hardware which can no
longer boot a stable Linux environment which does not fall over randomly
in strange and non-deterministic ways which makes debugging difficult.
The Xilinx XMD/EDK software slightly compounds the debugging anyway.

Suspicion lead me to disable the cacheing on the 405D as it was and is
still suspected that there is a problem with the hardware (currently I
am using an automatically generated really simple cut down hardware from
EDK6.1 using its autogeneration tool so that if/when I find this fault I
can make various ascertions about where it might lie). Recent posting
suggesting a problem with mmap was down to me however (see below) but I
am hopefully now back on track with cacheing properly off so I can
continue to look for the original problem again.

Cheers,

Jon.

--- Red faced explanation of mmap r8 issue mentioned ---

Seems I shoved in something along the lines of:

	li	r8,0			/* Load zero */
	iccci	r8,r8
	dccci	r8,r8

This happens during the SystemCall execution path because I am running
with cacheing disabled and I am paranoid so want to force the caches to
be flushed even though I have explicitly modified the iccr and dccr and
page protection bits in _PAGE_BASE to not use cacheing for kernel or
userland ID page frames (but not enough to have seen that I was trashing
the register for mmap). Anyway this means that finally I might be
running as per my original posting and can get back to looking for a
potential memory controller problem.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/