uClinux version 3.7 boot problem related to: mm bootmem.c:352 mark_bootmem()

[Altera_Forum]

Hi, I hope all is well and i thank you in advance for your time. In bold you find the relevant information to try and save you time reading this thread (i hope you don't find the bold lettering to be rude). Feel free to read in between to get more info.  

  i have been able to make images of uclinux version 3.1 for the mmu nios2 processor (Cyclone III FPGA) and have been able to boot without problems for a couple of months. However, the more that i attempted to enable new features such as ethernet and MMC/SD support, the more i realized that this version of the kernel and its drivers needed lots of work to become stable. i decided to update to the latest version of uclinux for the nios2 processor that is available through the git repositories. I did this by performing the "./update" command and by using the "nios2" branch instead of "unstable-nios2mmu". After performing the update and getting over a small hurdle of having to remove "mconf" binary file that did not allow me to get to "menuconfig", i was able to generate my first image using version 3.7 of uclinux. the system starts to boot and then i get the following error printout:   linux version 3.7.0-01377-g1061bd7-dirty (ja2-bld) (gcc version 4.1.2)#757 wed jan 23 14:28:22 est 2013 bootconsole [early0] enabled early_console initialized at 0x34003968 bug: failure at /home/ja2/fresh_build_mmu/nios2-linux/linux-2.6/mm/bootmem.c352/mark_bootmem()! kernel panic -not syncing: bug!   These are the things i have attempted to fix this issue: - I can rule out any hardware or FPGA configuration issues since i am able to run my previous images based on uClinux 3.1.    - I enabled devicetree and provided the right path to the ".dts" file on the "make menuconfig" option. I also compare the settings on the previous 3.1 kernel with the new 3.7 to make sure that the same initial features were enabled   - I looked into the "bootmem.c" file and was able to at least determine that this has to do with boot-time memory allocation. I tried to understand why the function mark_bootmem() fails but all i can guess is that the system is having a hard time either accessing memory or reserving the memory specified by "start" and "end" parameters to this function. I did not even want to attempt to modify this file since i expect this release to be much more stable.   - I double checked that i am providing the proper hardware description through the .dts file to the system and re-run the previous 3.1 kernel image with no problems on same hardware settup board.   My only guess is that there is some setting in "make menuconfig" that needs to be enabled or modified but after looking through all the settings i could think of, i could not find anything to help with problem.   I greatly appreciate any help that you can provide.

[Altera_Forum]

Hi all,  

 WOW, what a curve ball! Once again i have "bolded" the important parts.   So it turns out that from uClinux 3.1 kernel to uClinux 3.7 kernel, among the many changes implemented, i found that there is no longer a hidden nios2.h file that has the ram memory address hardcoded in it. It turns out that the RAM in the custom board i am working with is set starting at address 0x00000000, which happened to coincide with this hardcoded address (or maybe the engineer who designed the board knew what he was doing...). This board was designed around uClinux 2.6.. kernel which did not even use devicetree at all so my guess is that it is good practice to set RAM at this address.   To make things more interesting, on the uclinux 3.1 kernel that i was working with, changing this hardcoded address in nios2.h to match any changes in SOPC builder to the location of RAM does affect the booting process so if by any chance ram gets moved from address 0x00000000 then the system will not boot. This happened to me as i tried to automatically regenerate base addresses in SOPC builder after adding some modules and did not lock RAM's address.   Finally, once i moved to uClinux 3.7 kernel, my system would not boot because this hardcoded base address of RAM is nowhere to be found by the system unlike in the previous version. i then had to revisit the ".dts" file and had to create a custom xml file to describe the location of ram that was missing.   Hope this helps somebody out there as i wished this info had been out there for me.   Thanks to all that at least attempted to provide help.

[Altera_Forum]

Hi, It sounds familiar to my early problem "bootconsole [early0] enabled early_console initialized at 0x34003968" but I still using uClinux 3.1. To fix this, I have to go back to my QSYS design and enable the hardware div which wasn't mentioned in the wiki. I hope this help. 

 You mentioned the uClinux 3.1 works for you. Can you tell me what you did? I keep getting "kernel panic - not syncing: no init found. try passing init= option to kernel." Any help is greatly appreciated.

[Altera_Forum]

Hi,  

I am no expert so bear with me. Based on the things i have been reading, the "Kernel panic - not syncing ...etc..." is a very general error message that relates mostly to bootloaders or booting problems (obvious since it happens at the beginning of the boot sequence) but it usually is related to the processor not accessing the right memory locations either because your instructions are in the wrong place (you moved base address of memory containing instructions for example) or because you told the processor to look in a place different to where the instructions actually are (through the kernel configuration).   In my case, with version 3.1 MMU, i had issues at the beginning of development because of the address range used by the tightly coupled memory used for the TLB. I had to move the on-chip memory to a base address (0x09000000) located way after my reset and exception vector addresses (0x04000000 , and 0x00000020) and also had to move my ram module base address to 0x00000000. Moving these modules fixed the problem but I do not know if it was just luck -- I still don't fully understand how these addresses need to be setup, i just tried to match the setup of the NEEK project. In hindsight, I think that the address that really mattered in my case was the Exception Vector that is at a base of 0x00000000 with offset of 0x20. The reason that i think this is important is that in the nios.h file i mentioned before, the base address for ram is hardcoded at base 0x0.   Nobody ever mentioned this file for version 3.1 because you are now using devicetree so this was a real pain to figure out. That is what happens when you work with version of kernel that are release candidates and not stable versions... But then again, you cannot complain about the great effort put by the community, ergo, I try to contribute to the cause :)  There is also a setting in the "make menuconfig" of the kernel for the base address where your instructions are located but i never had to touch that. Hope this helps or at least points you in the right direction.

[Altera_Forum]

Thank you very much for your respond. I did manage to bypass my last problem by going into Advance Setup-> and change the "Set custom kernel MMU region base address", and the "Set custom kernel region base address", since my MMU base address is "0x000" and DDR2 RAM base address is "0x06000000" (with virtual memory, this base address is 0xC6000000).  

 It started to move along until I get this bug/failure message: Unhandled exception# 12 in kernel mode r1: c6000cc0 r2:00000000 r3: 00000b1c r4: 80000000 r5: 2aac70c0 r6: 00000f40 r7: ffffe0000 r8: c7049c88 r13: c704ede0 r14: c655cbb4 r15: 00000001 ra: c60b553c fp: c7c06ad4 sp: c7c17d5c gp: 00000000 ea: c60b512c estatus: 00000001 BUG: failure at /root/Desktop/nios2-linux/linux-2.6/mm/slab.c:501/page_get_cashe()! Kernel panic - not syncing: BUG!  Have you seem this before? Any help is greatly appreciated.

[Altera_Forum]

Hi,  

No, i have not seen this message but it definitely has to do with ram -- slab.c takes care of memory allocation. I would suggest leaving your kernel settings in the original values first and move change the value for DDR2 in linux-2.6/arch/nios2/include/asm/nios.h file to 0x06000000. Try to boot and see what happens. If you still have the issues then you may have to play with the settings in SOPC builder or Qsys of your nios2 processor and your memory module.   Other than that, i would not know how to attack the problem. Maybe from the kernel settings you can make some progress.

[Altera_Forum]

Thank you very much. I took your advice and did a make mrproper to reset my uClinux. I didn't modify my base address in the make menuconfig, and instead, I updated the nios.h. Everything is working now. However, I did enable the MUL and DIV. If not, it does hang doing the bootup. Thanks again.

[Altera_Forum]

No problem, glad I could help.:cool:

[Altera_Forum]

hi jamun001, 

 can u tell me how did u create XML File to describe the location of ram? i am using the NIOS_II_Standard from Altera and having the same problem above

[Altera_Forum]

Hi z0033z1y,  

 I work with a custom board (not a development board) so i do not know if this is the same for you but in my case i added the following to a custom XML i created. To create the custom XML, just open any other XML file in your deviceTree tools folder (where you have your java tool to create .dts/.dtb files), rename it, add your own fields, and recompile the tool. There is a whole guide in the kernel that tells you everything about deviceTree. Hope this helps.     <S2DComponent classname="micron_cellularram_x16x2" group="memory" compatDevice="sram">  <compatible name="sram"></compatible>  </S2DComponent>

[Altera_Forum]

thanx jamun001 for your feedback