It’s an ELF. Entry point is not at the start of the file.
Please review u-boot documentation for adequate way to start ELF kernels, and let us know what worked while at it. (I have no idea from the top of my head)
It’s odd to get an exception on the very first opcode. You should look at the other registers like MCAUSE to see what the exception is. I’d also dump memory from segment start to a few bytes after the opcode and verify that the bytes at address …0e8 match the opcode you THINK is at …0e8.
Also, “custom operating system” has red flags all over it. Maybe the binary isn’t getting generated the way you think it is. Verify this works with some other OS image.
It seems very odd for the loader to know enough about ELF to map the right sections into pages built with the correct mapping and yet not be able to read the 8 bytes from the e_start header. That’s low-hanging fruit for a program loader.
I also don’t know what Code is, but I know from memory that 45 46 and 4c are ‘fXle’ which is “other endian” for ascii ELF followed by a non-ASCII character and THAT sets off yet more red flags.
Maybe I’m reading the information you have provided wrong, but it looks to me like you have uploaded a binary file of size 1168 bytes into memory from 0x80100000 to 0x8010048f and then you are telling the CPU to start executing machine code at 0x801100e8. I could be wrong but it looks like it is beyond where the machine code was loaded into RAM.
The output from the following three commands might be useful for people trying to help you.
$ file main.elf
$ ls -l main.elf
$ hexdump -C main.elf | head -40
@mzs, you’re looking too low. So was I. We both assumed the developer had done their homework.
The loader is looking for a format that isn’t ELF at all. (This makes a bit of sense for cases like netboot where you may want the loaded image to also contain a filesystem…and a module to uncompress it or otherwise have more than just an exe to start.) I linked to relevant doc.
The E24 is accessed via a bus, it is separate from the fully-coherent U74MC+S7 cores inside the JH7110. Anyhow there is one RV32 core inside the JH7110. But with the default dts/dtb (currently) used, it is not normally accessible.
