# Boot overlay or bit load after power up

**URL:** <https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178>\
**Category:** Support\
**Created:** [May 10, 2022, 11:42am UTC](https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178 "2022-05-10T11:42:33Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![briansune](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.pynq.io/briansune/32/3087_2.png) [@briansune](https://discuss.pynq.io/u/briansune)\
**Post date:** [May 10, 2022, 11:42am UTC](https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178/1 "2022-05-10T11:42:33Z")

</div>

I may be getting this wrong or I missed the detail a bit.  
As I had tried from:

> **[PYNQ SD Card image — Python productivity for Zynq (Pynq)](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?

---

<div class="post-metadata">

**Author:** ![briansune](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.pynq.io/briansune/32/3087_2.png) [@briansune](https://discuss.pynq.io/u/briansune)\
**Post date:** [May 10, 2022, 11:19pm UTC](https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178/2 "2022-05-10T23:19:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cathalmccabe](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.pynq.io/cathalmccabe/32/3348_2.png) [@cathalmccabe](https://discuss.pynq.io/u/cathalmccabe)\
**Post date:** [May 11, 2022, 7:33am UTC](https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178/3 "2022-05-11T07:33:02Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![briansune](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.pynq.io/briansune/32/3087_2.png) [@briansune](https://discuss.pynq.io/u/briansune)\
**Post date:** [May 11, 2022, 8:11am UTC](https://discuss.pynq.io/t/boot-overlay-or-bit-load-after-power-up/4178/4 "2022-05-11T08:11:02Z")

</div>

> [@cathalmccabe](#):
>
> Cathal

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.
