The timer also should be initialised properly and ticking along.
#Allwinner h3 soc code
I think the GIC code should be working, but can’t really prove it as yet. I don’t know why but I’m having a mental block with it. The UART base addresses are &400 apart in memory. UART please? It’s referencing 4 sequential 4 byte entries in StaticWS, with a 0 byte entry above it so it can serve as being accessed by name or offset. If anyone is in the mood, could they please have a look at the BaseAddress macro in s. it looks like I need to focus hard on the MMU and cache disabling again. I don’t know if it’s an odd implementation thing with OMAP5 or a bug. HAL/OMAP5/hdr/Interrupts?rev=1.1.1.1 content-type=text%2Fx-cvsweb-markup#l54Īccording to the GIC400 TRM, GICD_SPENDSGIR should have a value of &F20. Speaking of which, I noticed something a little odd in the OMAP5 gic code. Although I have chopped things around a little, The iM圆, and OMAP3/4/5 Interrupts.s could be just about dropped in. I’m truly surprised you didn’t pick on all my StaticWS entries with 0 length and all the aliased definitions in headers. You probably saw all the hacked about and commented code. Everything I have found on it has been different. The included ones are untouched Hdr2h ones. There are currently no modules in C being built besides CLib, which isn’t even being used right now. I know it complains about shifts eg ( 3 << 2 ). I mean, yes there are things that Hdr2H can’t cope with. One problem is that you seem to have encountered a situation which Hdr2H can’t cope with… But making sure you disable & flush the caches before disabling the MMU would probably be a good place to start. I was thinking of pointing you towards the code in the softload tool, but the code there isn’t exactly what I was expecting to see so maybe some of my assumptions are wrong. You also need an ISB after the MRC that disables the MMU, to make sure it actually turns off before the other instructions are executed. Next problem: Your code for disabling the MMU looks a bit suspect – you’re flushing the TLB & branch predictors but not cleaning/invalidating (or even disabling) the cache. Which makes things even more dangerous.Įither way, your C workspace structs (and potentially other things like register layouts) are bogus, so until you get those fixed your C code isn’t going to work properly. I think at one point I was also toying with the idea of using C & objasm macros to produce a data definition language that could be processed directly – but that may be a bit tricky since C wants parentheses around macro parameters while objasm doesn’t.Īlso I’m not seeing any makefile rules to cause Hdr2H to automatically run. Perhaps, since parsing C can be as involved as parsing assembler, maybe it would make sense to introduce start from a third data definition language which is much easier to deal with. Unfortunately I don’t think anything ever came of that.
#Allwinner h3 soc manual
It also looks like it struggles with the padding entries which use : INDEX.Ī while ago I did suggest in an email to someone that a “H2Hdr” tool would be nice, since that would allow C code to use native C structs instead of messing around applying manual offsets to untyped pointers. So instead of IO_BaseAddr being given an offset of zero, the C header has it at an offset of 84. One problem is that you seem to have encountered a situation which Hdr2H can’t cope with – it looks like it doesn’t work properly with files that contain multiple structure definitions/storage maps. You regret that I’ll be able to help you by reviewing the code? :-) I’m certain I’ll regret this, but I put what I have in a GitHub Repository I have enough of a functional system to allow me to go back and work on the early boot with the knowledge that it will load a functioning system if correctly set up. There are a lot of basics that need to be filled in. The boot process is currently extremely crash prone due entirely to myself. Current status: Functional in supervisor mode with no hardware support beyond the basics required to get it running.