On Wednesday, 10 May 2023 10:52:59 CEST Philipp Eppelt wrote: > > I did some unsuccessful poking around in the manual and the MIPS code. I > just stumbled across the following: > > > I can only presume that some machines have bootloaders that clear ERL > > before the bootstrap code is invoked. > > Judging from this sentence in the Status.ERL description of the manual: > "The operation of the processor is UNDEFINED if the ERL bit is set while > the processor is executing instructions from kuseg."
That is rather interesting. The code should be running from KSEG0, though, since the program counter (instruction pointer) is operating in the region from 0x80000000 to 0xafffffff. The bootstrap code does access data in KUSEG, but this region also supposedly employs an identity mapping to physical addresses when ERL is set, as noted in an earlier remark. I have read that in the earliest part of bringing up a system, code should be running in the uncached, unmapped KSEG1 area and it should set up the caches before branches are taken elsewhere. Indeed, this is effectively what happens when the bootstrap vectors are used, and so the processor will run code from 0xbfc00000 or thereabouts - it's in on-board ROM in the Ingenic SoCs - and then dispatch to another address. With the CI20, as with many other boards of this nature, U-Boot performs some initialisation before passing control to things like L4Re's bootstrap module. Indeed, it tends to set ERL in order to avoid causing exceptions in any such initialisation code. When searching for discussion about ERL, I also found a patch for Linux that deferred the clearing of ERL within the kernel to a later point for precisely this reason. > I say that this bit should be cleared. The two 256MB regions also point > to the intention that Status.ERL is clear and thus there is no > unchached+unmapped useg. I agree. I'll try and see if this can be done, but there did seem to be something preventing it when I tried before. > I'm sorry to not have more helpful comments. I appreciate your comments, anyway! Thank you for reading and replying, Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
