Raspberry-Pi | My public Baremetal Raspberry Pi code

You can achieve this with Service Bus Explorer. The name might suggest it's only for Service Bus, but it has Event Hub and IoT Hub support as well. To see the data for the last hour, do the following:

Copy the Event Hub compatible endpoint from the Azure Portal and strip off the EntityPath. Example: Endpoint=sb://REDACTED.servicebus.windows.net/;SharedAccessKeyName=iothubowner;SharedAccessKey=REDACTED=;EntityPath=hub-name

becomes: Endpoint=sb://REDACTED.servicebus.windows.net/;SharedAccessKeyName=iothubowner;SharedAccessKey=REDACTED=

Open Service Bus Explorer and create a new IoT Hub Listener.

Add the connection string without the entity path and add the entity path as the Endpoint.

This will open a new listener window. In the window, you can select a start time. Select a time one hour back. The minimum retention period is a day, but if you decide to choose a time further in the past, that time should be within the retention period of the endpoint. If you select a time before the retention period, you will see events from the beginning of the retention period.

If you want to inspect the events, you can go to the Events tab and have a look at the data.

GDB is placing breakpoints based on where the ELF file says the code is. You can see that in your transcript it thinks the _start function in boot.S is at address 0x0. However, when you tell QEMU to load your binary file, you are not doing that in a way that matches what the ELF file says. So the actual code being executed is at an entirely different address, and the breakpoints are not in addresses that match the executing code, so they don't hit. Since you're not compiling the code to be position-independent, when it runs from this address it is working mostly by luck (because even non-position-independent aarch64 code often doesn't have position-dependent instructions in it).

The reason the addresses don't match up is because your ELF file is saying code starts at address 0x0, but you're passing QEMU a binary file to the -kernel option, which means "I am a Linux kernel, boot me the way the Linux kernel boot protocol says to do that" (see https://www.kernel.org/doc/Documentation/arm64/booting.txt). This means a number of things, including that (for the current QEMU implementation -- this isn't strictly mandated by the booting protocol) we load the image to the address 0x80000, and run a bit of stub code generated by QEMU which sets up some registers and jumps to that location. That is why when you set your linker script to link the image to that address it happens to start working.

The solution to this is to make a choice about how you want to boot your guest code:

• You can make it honour the various requirements of the Linux kernel boot protocol, and pass it as a binary file to -kernel
• You can write it to be a pure bare-metal image that includes a vector table at address 0x0, and load it with the QEMU "generic loader", which will take an ELF file and load all its segments as the ELF headers specify. (It is also possible to pass an ELF file to -kernel, but the generic loader makes more sense in this situation.)

QEMU does not support "load this ELF file and start it in the way that the Raspberry Pi firmware supports running an ELF file that it loads from an SD card". So you may need to make some adjustments to bare-metal code tutorials that were designed only for running on real hardware.

(For more info on the various QEMU options for loading guest code, see this answer.)

fixed this by editing the qmake.conf

used linux_device_post instead of linux_arm_device_post

Interesting, I don't have a quick fix for you but I did notice the partition that is over sized is the uboot partition. The uboot is a smaller separate binary installed on the machine. It looks as if your uboot build is over 512k and the partition is set for 512k. Your flash size is massize FLASH_SIZE = 9437184" that is more then a gig, (because FLASH_SIZE is in K)

If I were you I would first try to build an older version of openbmc for raspberry pi. (It used to work so you just need to find the commit before uboot grew to big). Use git to move back a month until you find it works.

If that does not work I would try to modify the partition table. here is where you failing

• this looks fine building the uboot image looks fine
• increasing the kernel offset make if build, but the other targets in openbmc will not be happy with this solution. So maybe meta-raspberry-pi will have to override the partition table (if uboot can not be shrunk)

What ever you do, open an issue on the github and share you changes. Also use the discord, and gerrit.

I just replicated this issue. We should fix it

The JRE is a subset of the JDK. It's possible that you need the whole JDK in order for PyCharm to work.

Try this:

I found out the simple answer. just reinstall the Raspbian OS to reset the SPI configuration (which was set for 3.5 inch LCD) so RFID writing and reading work well and everything goes correct.

For ubuntu the boot partition is mounted under /boot/firmware with 3 files: config.txt, syscfg.txt, and usercfg.txt. The usercfg.txt is included by config.txt and is recommended to bearing user customized configuration. So saving your lines in usercfg.txt instead should make it works

usercfg.txt

ifconfig

candump by can-utils

First of all, try removing your current python version:

To know your version: