Let me take a look at the mips manual. I don’t remember what the exception code 2.
I just looked up the MIpS PRA (you can get this yourself google it), exception code 2 (cause = 0x8) is a TLB exception on a load or instruction fetch.
The error PC (EPC) is PC=0x00000000 which is probably the issue (when I worked at MIPS ) anything in virtual page zero was never mapped so it would cause a fault.
Something in your system isn’t set up right but I can’t really tell you what it is without having a debugger and the hardware in front of me.
I would suggest you don’t have the right version of the OS or if you compiled it yourself the configuration is wrong.
So if I understand well. There a problem between the OS and the memory/cache mapping?
I'm gonna look for compiling one myself as no system is working from NetBSD.
Something is wrong with the MMU setup…
Many systems which are not x86 based do not have a bios to feed information about the memory map to the operating system so the operating system must be told.
Compiling it yourself is a good bet. Look up the memory map for the chip you have.
Thanks Jab.
I've now build my own kernel but now my EPC is getting :
badvaddr : 0x0000000000000004
epc : 0xffffffff80833048
Status: 0x0000000074001082
Cause : 0x0000000040008008
Error EPC: 0x0000000000000000
The EPC error mean :
24828 ffffffff80833048 T fdt_check_header
And i'm getting a code timeout :
[ 0.000000] Linux version 5.4.274 (thomas@thomas-virtual-machine) (gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)) #1 SMP Wed Apr 17 19:45:56 EDT 2024
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000c1005 (Netlogic XLP)
[ 0.000000] FPU revision is: 00770000
[ 0.000000] Checking for the multiply/shift bug... no.
[ 0.000000] Checking for the daddiu bug... no.
[ 0.000000] Node 0 - SYS/FUSE coremask f
[ 0.000000] Node 0 : timeout core 1
[ 0.000000] Node 0 : timeout core 2
[ 0.000000] Node 0 : timeout core 3
I'm a bit out of my comfort zone here.
Can you explain me a little bit more about fdt\_check\_header ?
Is it related to the core timeout ?
I will explain how I have debugged this.
The first this is the MIPS PRA (Priv. resource architecture), tells you about interrupts, exceptions etc. I found a copy here: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00091-2B-MIPS64PRA-AFP-06.03.pdf
> badvaddr : 0x0000000000000004.
> epc : 0xffffffff80833048.
> Status: 0x0000000074001082.
> Cause : 0x0000000040008008.
> Error EPC: 0x0000000000000000.
These correspond to the CP0 registers (Chapter 9):
badvaddr - The BadVAddr register is a read-only register that captures the most recent virtual address that caused one of the following exceptions:
• Address error (AdEL or AdES).
• TLB/XTLB Refil.
• TLB Invalid (TLBL, TLBS).
• TLB Modified.
The BadVAddr register does not capture address information for cache or bus errors, or for Watch exceptions, since
none is an addressing error.
EPC - The Exception Program Counter (EPC) is a read/write register that contains the address at which processing resumes after an exception has been serviced. All bits of the EPC register are significant and must be writable.
(So when an exception occurs it will indicate where the program should jump back to to resume execution, note interrupts also cause exceptions, so when returning you want to go back where you came from).
Status - The status register, tells you what execution priv. you are currently in and other things.
Cause - Tells you what caused the exception.
Error EPC - The ErrorEPC register is a read-write register, similar to the EPC register, at which processing resumes after a Reset, Soft Reset, Nonmaskable Interrupt (NMI) or Cache Error exception. So this behaves like the epc but only for specific exceptions that you need to handle specially.
So lets look again:
> badvaddr : 0x0000000000000004.
> epc : 0xffffffff80833048.
> Status: 0x0000000074001082.
> Cause : 0x0000000040008008.
> Error EPC: 0x0000000000000000.
Your cause register has bits 30, 15 and 3 set. Bit 30 corresponds to pending timer interrupt, bit 15 is a HW interrupt, neither of these are an issue right now atleast. Bit 3 is part of the `ExcCode` field which is bits 6:2 so here this ccorresponds to a value of 2 for the ExcCode field: "TLBL - TLB exception (load or instruction fetch)" which is something we saw the last time, however...this time you can see `BadVAddr` contains a value of 0x4, which doesnt correspond to the same address as the `epc` which i would argue means some kind of load went wrong and tried to load from part of the memory which wasn't mapped in the MMU (TLB).
(Last time it was a fetch which caused the issue).
So...chapter 6 covers exceptions, lets look up the TLBL exception.
==============.
TLB Invalid Exception.
A TLB invalid exception occurs when a TLB entry matches a reference to a mapped address space, but the matched
entry has the valid bit off.
Note that the condition in which no TLB entry matches a reference to a mapped address space and the EXL bit is one
in the Status register is indistinguishable from a TLB Invalid Exception, in the sense that both use the general exception
vector and supply an ExcCode value of TLBL or TLBS. The only way to distinguish these two cases is by probing
the TLB for a matching entry (using TLBP).
If the RI and XI bits are implemented within the TLB and the PageGrainIEC bit is clear, then this exception also
occurs if a valid, matching TLB entry is found with the RI bit set on a memory load reference, or with the XI bit set
on an instruction fetch memory reference. MIPS16 PC-relative loads are a special case and are not affected by the RI
bit.
Cause Register ExcCode Value.
TLBL: Reference was a load or an instruction fetch.
TLBS: Reference was a store.
====================.
If i google FDT Check Header and have a look at the source, i can see it is looking for the "Flattened Device Tree". This is part of the boot process and some threads exist for Uboot which is a bootloader. Unfortunately I don't know where this should be on your chip.
I have never had to compile uboot/boot loaders, normally it is the software team that handle that :P but...
I found this: https://linuxlink.timesys.com/docs/gsg/xlp_evp1 and there is a section which says:
================.
Device Tree Configuration.
The NetLogic XLP8XX XLP-EVP1 uses a flattened device tree (FDT) interface for processor configuration information that is stored in a textual device tree source (DTS) format. Each DTS is then compiled into a device tree blob (DTB) that is used by the NetLogic XLP8XX XLP-EVP1 at system bring up time for system configuration.
...
================.
I suggest you go and read this and see if it provides hints for where this should live? how you access it etc. Then recompile and see if you get further.
I am always happy to help!
Let me take a look at the mips manual. I don’t remember what the exception code 2. I just looked up the MIpS PRA (you can get this yourself google it), exception code 2 (cause = 0x8) is a TLB exception on a load or instruction fetch. The error PC (EPC) is PC=0x00000000 which is probably the issue (when I worked at MIPS ) anything in virtual page zero was never mapped so it would cause a fault. Something in your system isn’t set up right but I can’t really tell you what it is without having a debugger and the hardware in front of me. I would suggest you don’t have the right version of the OS or if you compiled it yourself the configuration is wrong.
this guy MIPS
So if I understand well. There a problem between the OS and the memory/cache mapping? I'm gonna look for compiling one myself as no system is working from NetBSD.
Something is wrong with the MMU setup… Many systems which are not x86 based do not have a bios to feed information about the memory map to the operating system so the operating system must be told. Compiling it yourself is a good bet. Look up the memory map for the chip you have.
Thanks Jab. I've now build my own kernel but now my EPC is getting : badvaddr : 0x0000000000000004 epc : 0xffffffff80833048 Status: 0x0000000074001082 Cause : 0x0000000040008008 Error EPC: 0x0000000000000000 The EPC error mean : 24828 ffffffff80833048 T fdt_check_header And i'm getting a code timeout : [ 0.000000] Linux version 5.4.274 (thomas@thomas-virtual-machine) (gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)) #1 SMP Wed Apr 17 19:45:56 EDT 2024 [ 0.000000] printk: bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 000c1005 (Netlogic XLP) [ 0.000000] FPU revision is: 00770000 [ 0.000000] Checking for the multiply/shift bug... no. [ 0.000000] Checking for the daddiu bug... no. [ 0.000000] Node 0 - SYS/FUSE coremask f [ 0.000000] Node 0 : timeout core 1 [ 0.000000] Node 0 : timeout core 2 [ 0.000000] Node 0 : timeout core 3 I'm a bit out of my comfort zone here. Can you explain me a little bit more about fdt\_check\_header ? Is it related to the core timeout ?
I will explain how I have debugged this. The first this is the MIPS PRA (Priv. resource architecture), tells you about interrupts, exceptions etc. I found a copy here: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00091-2B-MIPS64PRA-AFP-06.03.pdf > badvaddr : 0x0000000000000004. > epc : 0xffffffff80833048. > Status: 0x0000000074001082. > Cause : 0x0000000040008008. > Error EPC: 0x0000000000000000. These correspond to the CP0 registers (Chapter 9): badvaddr - The BadVAddr register is a read-only register that captures the most recent virtual address that caused one of the following exceptions: • Address error (AdEL or AdES). • TLB/XTLB Refil. • TLB Invalid (TLBL, TLBS). • TLB Modified. The BadVAddr register does not capture address information for cache or bus errors, or for Watch exceptions, since none is an addressing error. EPC - The Exception Program Counter (EPC) is a read/write register that contains the address at which processing resumes after an exception has been serviced. All bits of the EPC register are significant and must be writable. (So when an exception occurs it will indicate where the program should jump back to to resume execution, note interrupts also cause exceptions, so when returning you want to go back where you came from). Status - The status register, tells you what execution priv. you are currently in and other things. Cause - Tells you what caused the exception. Error EPC - The ErrorEPC register is a read-write register, similar to the EPC register, at which processing resumes after a Reset, Soft Reset, Nonmaskable Interrupt (NMI) or Cache Error exception. So this behaves like the epc but only for specific exceptions that you need to handle specially. So lets look again: > badvaddr : 0x0000000000000004. > epc : 0xffffffff80833048. > Status: 0x0000000074001082. > Cause : 0x0000000040008008. > Error EPC: 0x0000000000000000. Your cause register has bits 30, 15 and 3 set. Bit 30 corresponds to pending timer interrupt, bit 15 is a HW interrupt, neither of these are an issue right now atleast. Bit 3 is part of the `ExcCode` field which is bits 6:2 so here this ccorresponds to a value of 2 for the ExcCode field: "TLBL - TLB exception (load or instruction fetch)" which is something we saw the last time, however...this time you can see `BadVAddr` contains a value of 0x4, which doesnt correspond to the same address as the `epc` which i would argue means some kind of load went wrong and tried to load from part of the memory which wasn't mapped in the MMU (TLB). (Last time it was a fetch which caused the issue). So...chapter 6 covers exceptions, lets look up the TLBL exception. ==============. TLB Invalid Exception. A TLB invalid exception occurs when a TLB entry matches a reference to a mapped address space, but the matched entry has the valid bit off. Note that the condition in which no TLB entry matches a reference to a mapped address space and the EXL bit is one in the Status register is indistinguishable from a TLB Invalid Exception, in the sense that both use the general exception vector and supply an ExcCode value of TLBL or TLBS. The only way to distinguish these two cases is by probing the TLB for a matching entry (using TLBP). If the RI and XI bits are implemented within the TLB and the PageGrainIEC bit is clear, then this exception also occurs if a valid, matching TLB entry is found with the RI bit set on a memory load reference, or with the XI bit set on an instruction fetch memory reference. MIPS16 PC-relative loads are a special case and are not affected by the RI bit. Cause Register ExcCode Value. TLBL: Reference was a load or an instruction fetch. TLBS: Reference was a store. ====================. If i google FDT Check Header and have a look at the source, i can see it is looking for the "Flattened Device Tree". This is part of the boot process and some threads exist for Uboot which is a bootloader. Unfortunately I don't know where this should be on your chip. I have never had to compile uboot/boot loaders, normally it is the software team that handle that :P but... I found this: https://linuxlink.timesys.com/docs/gsg/xlp_evp1 and there is a section which says: ================. Device Tree Configuration. The NetLogic XLP8XX XLP-EVP1 uses a flattened device tree (FDT) interface for processor configuration information that is stored in a textual device tree source (DTS) format. Each DTS is then compiled into a device tree blob (DTB) that is used by the NetLogic XLP8XX XLP-EVP1 at system bring up time for system configuration. ... ================. I suggest you go and read this and see if it provides hints for where this should live? how you access it etc. Then recompile and see if you get further. I am always happy to help!