RE: [uClinux-dev] RE: page_offset.h incorrect for M5208EVB
Quoth Martin Voss : I agree that useable SDRAM starts at 0x4002 since dBUG uses the first 0x2. The physical end address of the SDRAM is 0x4200 (32MB). [...] Since the first 0x2 is used by dBUG, why is MEM_BASE 0x4000 and not 0x4002 ? Any shouldn't MEM_SIZE be adjusted down with 0x2 accordingly? While I'm not familiar with the 5208, isn't dBUG in Flash, not SDRAM? Once it stops running (by passing control to Linux) then any RAM it was using should be fair game, provided that all its hooks (interrupt vectors etc) are removed (which they should be). ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] RE: page_offset.h incorrect for M5208EVB
Hi martin, Martin Voss wrote: Thanks all for the feedback. I don’t feel that this gives any other severe side effects either, besides incorrect values at boot and in /proc/meminfo (and free command). But we will of course change to the correct setting. A couple of other details I have been thinking about (M5208EVB): In the “ram.ld” file: It says ORIGIN = 0x4002 and LENGTH = 0x01e0 . I agree that useable SDRAM starts at 0x4002 since dBUG uses the first 0x2. The physical end address of the SDRAM is 0x4200 (32MB). But shouldn’t the LENGTH in ram.ld be 0x4200 – 0x4002 = 0x01fe ? Yes, it should be that to be precisely correct. Fixed in CVS now. This is all done in a much more configurable/flexible fashion in the 2.6 kernel. I guess this is just a minor issue since the used RAM in all practical situations at link time is not even near the maximum available. Yeah, exactly. This lenght is only used as an end marker for the kernel linking step. For the larger RAM boards it can be pretty much any large numner, the kernel will always fit in the available RAM. In the “crt0_ram.S” file: Since the first 0x2 is used by dBUG, why is MEM_BASE 0x4000 and not 0x4002 ? Any shouldn’t MEM_SIZE be adjusted down with 0x2 accordingly? Well, no, MEM_BASE is designed to hold the real base of physical RAM. For one thing this is also used as the base for the vectors. In 2.4 kernels the kernels base link address is taken as the first usable address in RAM for uClinux. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] RE: page_offset.h incorrect for M5208EVB
While I'm not familiar with the 5208, isn't dBUG in Flash, not SDRAM? Once it stops running (by passing control to Linux) then any RAM it was using should be fair game, provided that all its hooks (interrupt vectors etc) are removed (which they should be). My first reaction was Duh! Why didn't I ever question this. I believe that amongst other things, the dBUG stack is near the bottom of SDRAM. So, it becomes a bit of a philosophical question: What do we want to happen when uClinux is shut down? Return to the dBUG prompt? Perhaps if uClinux could trigger a soft reset on exit, this would result in dBUG booting without the need of values/context stored in SDRAM from prior to booting uClinux. RF ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] RE: page_offset.h incorrect for M5208EVB
Quoth Bob Furber [EMAIL PROTECTED]: I believe that amongst other things, the dBUG stack is near the bottom of SDRAM. So, it becomes a bit of a philosophical question: What do we want to happen when uClinux is shut down? Return to the dBUG prompt? Perhaps if uClinux could trigger a soft reset on exit, this would result in dBUG booting without the need of values/context stored in SDRAM from prior to booting uClinux. That's how things normally work. Usually the only way to 'exit' uClinux is to do a soft reset (eg. by calling the reboot command), which will usually simply jump back to the flash boot address and the bootloader will then start running and reconfigure all the hardware as if it was a normal poweron. This should include resetting the RAM and pointing the interrupt vectors back at its own code, so everything should just magically work after that. Having said that, on my board (MOD5272) executing the reboot command reboots ok (and boots back into uClinux without problems) but for some strange reason it won't let me hit the key in the serial console to break into the bootloader. But I suspect that's something the bootloader is doing incorrectly. (Unfortunately I don't have the source for that.) ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] RE: page_offset.h incorrect for M5208EVB
Hi Bob, Bob Furber wrote: While I'm not familiar with the 5208, isn't dBUG in Flash, not SDRAM? Once it stops running (by passing control to Linux) then any RAM it was using should be fair game, provided that all its hooks (interrupt vectors etc) are removed (which they should be). My first reaction was Duh! Why didn't I ever question this. I believe that amongst other things, the dBUG stack is near the bottom of SDRAM. So, it becomes a bit of a philosophical question: What do we want to happen when uClinux is shut down? Return to the dBUG prompt? In the early days of uClinux on ColdFire that is exactly what you could do. But that functionality is long gone now. The 0x2 gap leaving the dBUG ram intact is a left over from that though. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
