Strange reaction from netbook (memcpy)

[BASICFreak]

The hardware in question is an "HP Mini 110", 2GB ram, atom N455 @ 1.66GHz.

I am running a PXE / TFTP server which my systems are booting from.

All other systems boot with no problem, but this netbook freezes during a memory copy on the second module (at about 0x00390000 Bytes)

According to the Official Manual from HP the memory map should have holes exactly where all other x86/PC have there holes (so over 1MB the hole should be at 15MBish?)

My memcpy function switches the processor to 16-bit protected (unreal) mode with full address range 0-4GB and runs "rep movsb" to copy from ESI to EDI times ECX, then it switches back to 16-bit real mode to continue boot code operations.

My kernel loads in fine (I load it in at 0x00300000 and the ELFs size is 0x00010DF0) then we process the ELF, loading it into memory where it wants to be - in this case 0x00100000 with a size of 0x0028C058.

The first module loads in at the first (4KB) page after the end of the Kernel data (so 0x0038D000) - this first mod is a binary file (the ELF loader for the kernel) its size is exactly 8KB so it ends at 0x0038F000

Then the next mod (my standard IO dll) loads at 0x0038F000 and on the first packet (size 0x200) we call memcpy and never return.

The netbook boots the kernel (if it doesn't get stuck in memcpy - which I have managed once to get it to boot with the mods, just by rebooting and trying again and again (haven't been able to get past once though)

Every other PC in my possession will load all the mods in and run without even the slightest sign of issues.




So, I have read from many of you that netbook programming is "evil" (my word), but I am wondering if anyone has any experience here. This has been one of the hardest boot codes I have ever written (mostly do to Bochs and Qemu NetBoot BIOSes not working properly - not just tested with my code but with ubuntu's netboot also.)

I do not know which (if any) pieces of code you may need (want), just ask if you want to see something. (Have not updated GIT yet, and will not until I have my SVGA code in the boot loader)



NOTE: memcpy is called after every packet (so every 512 Bytes received from TFTP) and also during the ELF processing (called per section with filesz) so it is not like the function just doesn't work, I have called it many times before the freeze.

[kzinti]

Might be worth running some memory tests on that netbook...

[BASICFreak]

Might be worth running some memory tests on that netbook...

If only...

I'm running memtest86+ (on the first 16MB) ATM with currently 22 passes 0 errors

I did run 3 passes on all 2GB, but decided I rather only test the 16MB (as even fully loaded and running I use only 6MB of ram - and during boot I only use 4-5MB)

Also Lubuntu runs flawlessly (other than the HW issue with the KB [the '/' key is stuck])

And yes I started memtest86+ with the PXE / TFTP server.

[BASICFreak]

Well, it turns out the netbook started without the lower memory cleaned... I 0'ed out the mod table and everything is as expected now

I know, I know, never use RAM without clearing it...

Sorry for wasting everyone's time...

[kzinti]

=)

[Ready4Dis]

Well, it turns out the netbook started without the lower memory cleaned... I 0'ed out the mod table and everything is as expected now

I know, I know, never use RAM without clearing it...

Sorry for wasting everyone's time...

Good lesson learned, thanks for coming back and letting us know what it was!
/me runs off to check my boot code.