#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Joined per suggestion by Bertl

hello JasonEE!

Other IRC window locked up - was in background compiling/coding earlier when I was addressed.

hi Bertl

yep

i am wasting about 10GB of my SSD

can't be vivado, as it uses way more than 10GB :)

I am attempting something which I wonder could work

basically the bootpart in combination with something *undefined* else ;)

but the board complains: ** Unable to read file xillydemo.bit **

MicroZed over minicom

yes

hmm, maybe capture the console output from the beginning and upload it somewhere? (pastebin)

i am doing something that is not recommended

ah, that looks more like you have already booted a kernel

this can fail for many reasons, one being the format of the file, another the permissions

and i am mixing two distributions

boot.bin, devicetree.dtb

so i copied those from the xillinux stuff

and used an uImage from somewhere else

but basically the point is, is there a discription somewhere how you could make the boot.bin and devicetree.dtb

only up to the alternative booting methods using either uboot (on the console) and the dipswitches on the board itself

okay, so the basic boot sequence is like this:

at this stage the jumpers (config inputs) are sampled and stored

the zero level bootloader is something that does not change?

once that is finished, control is handed over to the loaded fsbl (first stage boot loader)

which has to either configure the chip and external hardware or find some way to load/get more stuff

no, actually uboot is the second stage bootloader

the first stage bootloader is typically a binary blob generated by the xilinx tools

the elphel folks are working on a 'free and open' fsbl for some zynq platforms, so you might want to look into that

the core memory is 128k (IIRC), so the fsbl has to fit there

note that while the FSBL usually includes a bitstream, it is not strictly necessary, although it makes sense to start with a sane default

the device tree can also be generated with the tools, but I crafted my own device tree for the alpha, and it probably makes sense to do the same for the beta (which shouldn't be that different)

have you used the xilinx tools for this?

you are using vi to alter a binary file?

the dts, which can be 'compiled' into a dtb

once a generic FSBL has been built, you can combine it with arbitrary uBoot versions, so there was no need yet to regenerate it (yet)

so basically you are saying: if you want to know the boot process, you should follow the Xilinx wiki steps

either that or use/adapt the FSBL from the elphel folks

the boot.bin is generated from the FSBL (elf) plus an optional bitstream plus the uboot (elf)

i want to get this part to work :)

so my suggestion for you is the following:

once that works, try to replace it with a modified version of the elphel FSBL

http://pastebin.com/gGUJn0S6

the u-boot.elf is the 'u-boot' file generated when building u-boot

the that is whatever you want to run on cpu1 (if there is anything)

cpu0 will run the fsbl and later u-boot

typically you want to keep the second core stopped or something like that if you want to go for smp later

if you use one cpu for bare metal for example

like two linux kernels, one for android and one for linux

if you have a bare metal program you may just want to have everything taken care for you

it also makes a lot of sense for our case to have a sane default

the files amp_fsbl and you app_cpu1.elf

are they generated by the xilinx tools, or do you have them somewhere laying around?

can you also imagine a situation where we go for a bare metal camera?

lets say the elphel fsbl basically stated in the readme that they don't support bitstream loading at this moment

yes, which isn't that critical atm :)

for uboot to be useable to boot linux, you need some DDR setup already in place

that's why I think that for a start it's probably the simplest to build one (or maybe two) xilinx FSBLs for the two microzeds we might encounter in the wild

and simply provide them 'as is' for combining with other elf files via bootgen

for uboot, I think the important config areas are: networking, dhcp/bootp, tftp, simple access to all the flash and memory, fat read/write access for changing the boot files via uboot

note that I went with the digilent version of uboot because the xilinx and mainstream version had terrible network performance

because it can be accessed from linux, mac and windows easily

ok thanks :)

btw, since you suggested 'nothing could go wrong'

and indeed when the flashing fails of the internal memory fails, you can still boot from SD

this is a great distinction between the embedded boards i was using before

jtag is not fun ;)

ah thats a nice featur

(for the microzed, I mean)

I can recommend this one: http://dangerousprototypes.com/wp-content/media/2011/12/jtag3.jpg

(with the xilinx/altera tools that is :)

note that you still need a 'special' cable for the fine pitch (2mm) conenctor on the microzed

yep, should work fine as well I guess

so i rather have something from farnell where i know what i pay, then all kind of costs afterwards

i'll let you know my progress probably before tuesday

will do :) good night

off to bed now ... have a good one everyone!