Minimal Boot Loader

google.1.nburkitt · February 27, 2017, 11:52pm

Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.

I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader

Release 2016.1 Feb 27 2017-12:16:06

Devcfg driver initialized

Silicon Version 3.1

Boot mode is SD

SD: rc= 0

SD Init Done

Flash Base Address: 0xE0100000

Reboot status register: 0x60400000

Multiboot Register: 0x0000C000

Image Start Address: 0x00000000

Partition Header Offset:0x00000C80

Partition Count: 2

Partition Number: 1

Header Dump

Image Word Len: 0x0001D093

Data Word Len: 0x0001D093

Partition Word Len:0x0001D093

Load Addr: 0x04000000

Exec Addr: 0x04000000

Partition Start: 0x000065D0

Partition Attr: 0x00000010

Partition Checksum Offset: 0x00000000

Section Count: 0x00000001

Checksum: 0xF7FA2615

Application

Handoff Address: 0x04000000

In FsblHookBeforeHandoff function

SUCCESSFUL_HANDOFF

FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.

I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.

Any ideas?

Thanks,

-Nick

bush · February 28, 2017, 1:05am

U-Boot has the devicetree built into it for the purpose of it's own execution. A minimal FSBL/U-Boot pair would still have a devicetree built in but will only have essential on-board peripherals/devices enabled (no USB or ENET). Your uEnv.txt file contains the scripts for loading a devicetree from a separate file along with the kernel. Your FSBL is reporting a successful handoff which means that your issue is likely with U-Boot. Did you compile U-Boot from source at https://github.com/krtkl/snickerdoodle-u-boot?

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:

Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

weatherbee · February 28, 2017, 1:12am

Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:

Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

google.1.nburkitt · February 28, 2017, 2:57am

Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.

Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.

I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:

Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

google.1.nburkitt · February 28, 2017, 10:32pm

Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.

The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.

What procedure do you guys use to build u-boot?

Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:

Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

bush · February 28, 2017, 10:47pm

Here are some instructions for building U-Boot on a Linux machine with the Xilinx SDK/toolchain installed.

1. Clone source from GitHub

$ git clone https://github.com/krtkl/snickerdoodle-u-boot.git

2. Set session variables for build

$ export ARCH=arm
$ export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

3. Configure for your board

$ make zynq_snickerdoodle_defconfig

or

$ make zynq_snickerdoodle_black_defconfig

4. Build

$ make

You will end up with a binary named 'u-boot' to which you will need to add a '.elf' extension and you can use to build your bootloader.

To build your bootloader, your boot.bif file should look something like:

image : {
[bootloader]fsbl.elf
u-boot.elf
}

and generating your boot.bin file with

$ bootgen -image boot.bif -o i boot.bin

Let me know if this makes sense with respect to what you're trying to accomplish. I will be updating the prebuilt images and SD card images very soon which may help shortcut some of these issues.

On Tuesday, February 28, 2017 at 2:32:56 PM UTC-8, Nick Burkitt wrote:

Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.
The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.
What procedure do you guys use to build u-boot?
Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:
Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

google.1.nburkitt · March 1, 2017, 12:04am

Hi Bush.

This is (almost) exactly the procedure I've been following, with no luck. Just to be sure, I tried again using exactly the steps as you gave them, and got the same results as before, namely, no serial port output (FSBL debug output isn't turned on at the moment), and no other signs of (Zynq) life from the board.

If I switch back to my mystery, downloaded-from-somewhere version of u-boot, it works.

I ran git status in snickerdoodle-u-boot, and got "Your branch is up to date with 'origin/master'."

Any ideas on what to try next?

Thanks,

-Nick

On Tuesday, February 28, 2017 at 2:47:45 PM UTC-8, Bush wrote:

Here are some instructions for building U-Boot on a Linux machine with the Xilinx SDK/toolchain installed.

1. Clone source from GitHub

$ git clone https://github.com/krtkl/snickerdoodle-u-boot.git

2. Set session variables for build

$ export ARCH=arm
$ export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

3. Configure for your board

$ make zynq_snickerdoodle_defconfig

or

$ make zynq_snickerdoodle_black_defconfig

4. Build

$ make

You will end up with a binary named 'u-boot' to which you will need to add a '.elf' extension and you can use to build your bootloader.

To build your bootloader, your boot.bif file should look something like:

image : {
[bootloader]fsbl.elf
u-boot.elf
}

and generating your boot.bin file with

$ bootgen -image boot.bif -o i boot.bin

Let me know if this makes sense with respect to what you're trying to accomplish. I will be updating the prebuilt images and SD card images very soon which may help shortcut some of these issues.

On Tuesday, February 28, 2017 at 2:32:56 PM UTC-8, Nick Burkitt wrote:
Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.
The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.
What procedure do you guys use to build u-boot?
Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:
Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

bush · March 1, 2017, 12:12am

Running git status by itself will not tell you whether you are up to date with the GitHub repo. Do 'git fetch origin' before running 'git status' to double check that you are synchronized. There was an issue recently with the U-Boot configurations that caused failure to boot so you'll want to make sure your using the latest configs. Are you using snickerdoodle black?

On Tuesday, February 28, 2017 at 4:04:12 PM UTC-8, Nick Burkitt wrote:

Hi Bush.

This is (almost) exactly the procedure I've been following, with no luck. Just to be sure, I tried again using exactly the steps as you gave them, and got the same results as before, namely, no serial port output (FSBL debug output isn't turned on at the moment), and no other signs of (Zynq) life from the board.
If I switch back to my mystery, downloaded-from-somewhere version of u-boot, it works.
I ran git status in snickerdoodle-u-boot, and got "Your branch is up to date with 'origin/master'."
Any ideas on what to try next?
Thanks,

-Nick

On Tuesday, February 28, 2017 at 2:47:45 PM UTC-8, Bush wrote:
Here are some instructions for building U-Boot on a Linux machine with the Xilinx SDK/toolchain installed.

1. Clone source from GitHub

$ git clone https://github.com/krtkl/snickerdoodle-u-boot.git

2. Set session variables for build

$ export ARCH=arm
$ export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

3. Configure for your board

$ make zynq_snickerdoodle_defconfig

or

$ make zynq_snickerdoodle_black_defconfig

4. Build

$ make

You will end up with a binary named 'u-boot' to which you will need to add a '.elf' extension and you can use to build your bootloader.

To build your bootloader, your boot.bif file should look something like:

image : {
[bootloader]fsbl.elf
u-boot.elf
}

and generating your boot.bin file with

$ bootgen -image boot.bif -o i boot.bin

Let me know if this makes sense with respect to what you're trying to accomplish. I will be updating the prebuilt images and SD card images very soon which may help shortcut some of these issues.

On Tuesday, February 28, 2017 at 2:32:56 PM UTC-8, Nick Burkitt wrote:
Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.
The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.
What procedure do you guys use to build u-boot?
Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:
Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

google.1.nburkitt · March 1, 2017, 1:03am

It was worth a try, but still no joy. I'm using a plain-old, colorless snickerdoodle (rev. 3).

On Tuesday, February 28, 2017 at 4:12:17 PM UTC-8, Bush wrote:

Running git status by itself will not tell you whether you are up to date with the GitHub repo. Do 'git fetch origin' before running 'git status' to double check that you are synchronized. There was an issue recently with the U-Boot configurations that caused failure to boot so you'll want to make sure your using the latest configs. Are you using snickerdoodle black?

On Tuesday, February 28, 2017 at 4:04:12 PM UTC-8, Nick Burkitt wrote:
Hi Bush.

This is (almost) exactly the procedure I've been following, with no luck. Just to be sure, I tried again using exactly the steps as you gave them, and got the same results as before, namely, no serial port output (FSBL debug output isn't turned on at the moment), and no other signs of (Zynq) life from the board.
If I switch back to my mystery, downloaded-from-somewhere version of u-boot, it works.
I ran git status in snickerdoodle-u-boot, and got "Your branch is up to date with 'origin/master'."
Any ideas on what to try next?
Thanks,

-Nick

On Tuesday, February 28, 2017 at 2:47:45 PM UTC-8, Bush wrote:
Here are some instructions for building U-Boot on a Linux machine with the Xilinx SDK/toolchain installed.

1. Clone source from GitHub

$ git clone https://github.com/krtkl/snickerdoodle-u-boot.git

2. Set session variables for build

$ export ARCH=arm
$ export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

3. Configure for your board

$ make zynq_snickerdoodle_defconfig

or

$ make zynq_snickerdoodle_black_defconfig

4. Build

$ make

You will end up with a binary named 'u-boot' to which you will need to add a '.elf' extension and you can use to build your bootloader.

To build your bootloader, your boot.bif file should look something like:

image : {
[bootloader]fsbl.elf
u-boot.elf
}

and generating your boot.bin file with

$ bootgen -image boot.bif -o i boot.bin

Let me know if this makes sense with respect to what you're trying to accomplish. I will be updating the prebuilt images and SD card images very soon which may help shortcut some of these issues.

On Tuesday, February 28, 2017 at 2:32:56 PM UTC-8, Nick Burkitt wrote:
Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.
The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.
What procedure do you guys use to build u-boot?
Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:
Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick

bush · March 1, 2017, 9:06am

Can you try this U-Boot binary? It is a fresh build for snickerdoodle tested on a Rev 3.0 today.

MD5: fe666b73a51e1c94e8c3b63d8f3f338e

On Tuesday, February 28, 2017 at 5:03:05 PM UTC-8, Nick Burkitt wrote:

It was worth a try, but still no joy. I'm using a plain-old, colorless snickerdoodle (rev. 3).

On Tuesday, February 28, 2017 at 4:12:17 PM UTC-8, Bush wrote:
Running git status by itself will not tell you whether you are up to date with the GitHub repo. Do 'git fetch origin' before running 'git status' to double check that you are synchronized. There was an issue recently with the U-Boot configurations that caused failure to boot so you'll want to make sure your using the latest configs. Are you using snickerdoodle black?

On Tuesday, February 28, 2017 at 4:04:12 PM UTC-8, Nick Burkitt wrote:
Hi Bush.

This is (almost) exactly the procedure I've been following, with no luck. Just to be sure, I tried again using exactly the steps as you gave them, and got the same results as before, namely, no serial port output (FSBL debug output isn't turned on at the moment), and no other signs of (Zynq) life from the board.
If I switch back to my mystery, downloaded-from-somewhere version of u-boot, it works.
I ran git status in snickerdoodle-u-boot, and got "Your branch is up to date with 'origin/master'."
Any ideas on what to try next?
Thanks,

-Nick

On Tuesday, February 28, 2017 at 2:47:45 PM UTC-8, Bush wrote:
Here are some instructions for building U-Boot on a Linux machine with the Xilinx SDK/toolchain installed.

1. Clone source from GitHub

$ git clone https://github.com/krtkl/snickerdoodle-u-boot.git

2. Set session variables for build

$ export ARCH=arm
$ export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

3. Configure for your board

$ make zynq_snickerdoodle_defconfig

or

$ make zynq_snickerdoodle_black_defconfig

4. Build

$ make

You will end up with a binary named 'u-boot' to which you will need to add a '.elf' extension and you can use to build your bootloader.

To build your bootloader, your boot.bif file should look something like:

image : {
[bootloader]fsbl.elf
u-boot.elf
}

and generating your boot.bin file with

$ bootgen -image boot.bif -o i boot.bin

Let me know if this makes sense with respect to what you're trying to accomplish. I will be updating the prebuilt images and SD card images very soon which may help shortcut some of these issues.

On Tuesday, February 28, 2017 at 2:32:56 PM UTC-8, Nick Burkitt wrote:
Latest update - I was wrong about being able to build u-boot on snickerdoodle. I used the wrong file when building BOOT.bin - if I use the snickerdoodle-built file I get nothing post-handoff.
The good news is that I can build a minimal BOOT.bin that works, and I no longer have to use the "magic" BOOT.bin. The bad news is that I still have to use a prebuilt u-boot.elf, whose source is also in question.
What procedure do you guys use to build u-boot?
Thanks,

-Nick

On Monday, February 27, 2017 at 6:57:28 PM UTC-8, Nick Burkitt wrote:
Thanks - I did build u-boot from source, but cross-compiled on my Intel/Linux development system. As a shot in the dark, I just tried compiling on snickerdoodle, and got a functional bootloader out of it. What could cause cross-compiling u-boot to make it not work? As long as I don't have to do that very often, I can live with it, but building on my development machine is about 60x snickerdoodle speed.
Working from a position of serious ignorance, my goal is to have a hardware-neutral bootloader, and have complete control over the device-tree and FPGA bitstream via the filesystem. I understand that that's what uEnv.txt promises - and I have made good use of the feature, but I find myself in the awkward position of having a "magic" BOOT.bin, of unknown provenance, that makes Ethernet work (and USB fail). No boot loader I've been able to produce myself allows Ethernet to work - it appears I get no interrupts, although every other indication says everything is working.
I'm confused by the proliferation of device-tree blobs. U-boot has a device-tree, but the FSBL can be built with another one, and uEnv will load yet a third. I had hoped to limit my confusion by limiting the number of different device-tree blobs to just one.

-Nick

On Monday, February 27, 2017 at 5:12:46 PM UTC-8, weath...@krtkl.com wrote:
Hi Nick, I'm wondering what the purpose of just running the FSBL and U-boot would be?

Are you just wanting to boot up and develop "bare metal"?

-Jamil

On Monday, February 27, 2017 at 3:52:52 PM UTC-8, Nick Burkitt wrote:
Has anyone succeeded in building and running a minimal boot loader - just a FSBL and u-boot? I've tried everything I can think of, which admittedly may not be much.
I enabled debug output in the FSBL project, so I can see I'm getting as far as this:

Xilinx First Stage Boot Loader
Release 2016.1 Feb 27 2017-12:16:06
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x0001D093
Data Word Len: 0x0001D093
Partition Word Len:0x0001D093
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7FA2615
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1

And that's (literally) all she wrote. It took adding the ".elf" extension to the u-boot executable to change the Handoff Address from 0x00000000 to 0x4000000, but that's about all the progress I've made.
I want u-boot to load the device-tree info from the filesystem, rather than having it compiled into BOOT.bin.
Any ideas?
Thanks,

-Nick