Okay I get it now, it really wants you to start your program at 0x8000. Or lets say it wont load under that, wont load at 0x000 in arms space even with the config.txt setting (will accept addresses larger than that), perhaps because that is the gpu space and at least on boot it is using that space. Who knows. I thought I was loading at 0, was doing absolute addressed data access into my binary, and what I was expecting wasnt there, because it was at address 0x8000+expectation. This means that to build an arm exception table, say to handle interrupts for example you have to build or at least place the instructions after the arm boots, not compiled in the bin at the proper place. Unless there are yet more raspi config.txt tricks I have not found (and dont have much interest in, prefer to use as few backdoor tricks as possible)
dwelch67, you could of saved yourself a lot of work by listening to me, first the config.txt file and now the 0x8000 offset
One word of note, if you do not disable in the config file "disable_commandline_tags" or have no config.txt something is written above 0x8000 not sure what yet, as i have only just got my print code working.
I only found this out because it wrote it to where my background image was stored, if i replace the image with code it crashes.
I will dump it to screen to see what it is.
If you disable "disable_commandline_tags" in the config.txt its not written there.
Also have you played with these setting in the config.txt
disable arm access to GPU's L2 cache. Needs corresponding L2 disabled kernel. Default is 0.
I wish those things had registered in my mind, I would have saved some time. Learned a bit though, wasnt all pain there is fun to figuring stuff out.
My concern about using config.txt is if I end up with a handful of different config.txt settings I need depending on what program I want to run then either I have to just adopt a policy of 1)always carry a config.txt with a kernel.img or 2) never carry a config.txt with a kernel.img or 3) create one config.txt that I use with every kernel.img I make and load that one one time.
The most distasteful is that their gpu bootloader has all of these knobs to turn, keep it simple, let the programmers build binaries the way they normally build embedded binaries. We dont normally have some pre-processor-boot hardware that wanders about reading ascii files and making changes. We build our binaries the way we want them with atags in the right place the bootloader doing what it is supposed to do, correct addresses, etc. The more closed code they have the more risk for bugs, more risk they are going to muck with things every version, etc, I wish they had taken a keep it simple stupid approach to booting the arm.
ATAGs, yes, they get shoved in somewhere relative to the start (32 kbytes? 64 kbytes, some nice boundary like that if I remember), my programs have been fairly small I must have been lucky. Maybe I should just do what I was planning to do and get it over with, write a program whose kernel.img is big, fills up ram, then have a program sweep ram looking for anything that got modified. (then try this config.txt thing to see if it disables that).
I did not play with the l2 cache disable, I have been avoiding the config.txt file as much as possible. Since I have a couple of benchmark programs might be interesting to just turn it off and see how much worse it gets.