Boot overlay or bit load after power up

Support
1

I may be getting this wrong or I missed the detail a bit.
As I had tried from:
https://pynq.readthedocs.io/en/latest/pynq_sd_card.html?&_ga=2.118423182.629833020.1651139285-1104757757.1650982329#leveraging-boot-py-to-modify-sd-card-boot-behavior
The instruction said adding boot.py aka
packages/
└── boot_leds
├── boot.py
└── pre.sh

While what I observe is the base bit and boot.py is run after

PYNQ Linux, based on Ubuntu 20.04 pynq ttyPS0
pynq login: xilinx (automatic login)
Welcome to PYNQ Linux, based on Ubuntu 20.04 (GNU/Linux 5.4.0-xilinx-v2020.2 armv7l)
xilinx@pynq:~$

So what if I would like to load the bit after it is power up and still able to reload other overlay after bootup?

Is there any way to achieve it?

1 Like
2

Okay, it looks like the guidelines are misleading a bit.
// ==================
we allow users to disable FPGA manager by setting FPGA_MANAGER_${BOARD} to 0. This may have many use cases. For example, users may want the bitstream to be downloaded at boot to enable some board components as early as possible. Another use case is that users want to enable interrupt for XRT. The side effect of this, is that users may not be able to reload a bitstream after boot.
// ==================
The overlay can still be reload even setting the flag to 0.
So maybe experienced engineer can share a bit more what case will this not able to reload the bit.

3

boot.py or running a custom script to load the bitstream during the Linux boot is the easiest way to do this.
Why do you need to load the Overlay after power up?

If you disable FPGA Manager then it should not be included. Can you check if it is included or not in your image build?

You can find some other posts on this.
https://discuss.pynq.io/t/for-v2-5-is-there-a-way-to-have-it-load-a-bitstream-during-power-up-like-it-did-in-prior-versions-of-pynq/572/7

You should check any code that you add to boot.py in a notebook first to make sure it works before adding to boot.py.

Cathal

1 Like
4

Cathal I humbly thank you but 1st I am not sure why you using 2.5 old revision here .
2nd had you tried the 2.7 boot.py and the differences between the flag is set or not?

I already generate both w and wo the FPGA_MANAGER_${BOARD} flag case.
And the result already discussed on above.
There are so many case that the initial boot bit needed in example HDMI or RTOS applications.
Meantime how slow the after boot load time it is? (if you had experience on 2.7 boot.py overlay)
What I see from the boot.py service to be activate and complete is that it will wait until pl and jutyer service is initialized.
So even the console is ready to be accept user commands it does not mean the boot.py is done it is just not the case. (Correct me if I am doing it wrongly)
At least from the console I can check the service is complete of the bootpy.sh and system/boot…

So in that case the response time is even slower than you think.

1 Like