[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Petalinux v0.10-rc1, bug found
I am using Petalinux v0.10 rc1, using a Microblaze CPU on a Xilinx
ML401 board. Generally working very well, but I have found a bug
that prevents the CPU reset button working correctly.
Glad to hear it's working well for you.
Before uClinux boots (e.g. in fs-boot and u-boot), the ML401 CPU
reset button works correctly. After uClinux boots, the reset button
causes the system to crash.
This is because fs-boot has been partially overwritten by
The intention of the pingpong code is to allow a soft-reset to work -
when we copy the interrupt/exception vectors etc on early boot, the
original memory contents are simply swapped with the vectors. On a soft
reboot, we repeat the process, so any prior bootlaoder etc down there
should be untouched.
The issue you are seeing is coming from a hard reset (a button wired
directly to the reset signal), so the kernel gets no chance to undo the
When the interrupt vector table is replaced, memory addresses
between 0x4 and 0x68 are overwritten with the vectors. The highest
vector is dbtrap, which is installed at 0x60. Unfortunately, part of the
fs-boot loader is at 0x50:
(mb-objdump -d fs-boot/executable.elf)
So when I press reset, fs-boot jumps to 0x50, falls through to 0x60,
and then runs the kernel dbtrap routine. Perhaps part of fs-boot
could be moved to a higher address?
Well spotted. Moving FS boot a bit higher is probably the best solution
- unfortunately 0x50 is the default link location in EDK so we'll need
to add a custom link script of link option to the HW reference design
You've most likely sorted this out yourself, but an interim solution is
to manually edit the start address of FS-boot in XPS.
I'll file a bug report and make sure it's fixed in the next release.
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/