[Buildroot] issue with Linux ARM start_kernel

[Buildroot] issue with Linux ARM start_kernel

[Robert Smigielski]

Hi everyone,

I am a long time Linux device driver writer (about 16 years) and now for 3
years creating BSP's using Buildroot.

I am working on a Buildroot project with much back porting on the following
combination of old hardware and old software. The board has a BSP created
by a vendor who no longer supports any of this stuff so now it is in my
hands to make this work so I can add security updates to this pile.

Digi NS9215 ARM 926ejs single core
Linux 2.6.34
CodeSourcery ARM 2010 09 tool chain
GLibC
UBoot

I have been adding packages to this platform and testing each software
image after each package I add. The board is booting and running nicely up
until I added the required old version of NetworkManager at 0.8.1. I am
stuck with the hardware and software versions for this back port.

When I build using "make clean" then "make" - without NetworkManager in the
.config the board boots and runs for days. Great.
When I build using "make clean", reconfigure Buildroot to enable my custom
added NetworkManager=y, the build succeeds, the image is loaded on the
board, and I get the problem:

"Uncompressing Linux... done, booting the kernel."

and then silence. I have this issue repeatedly after doing code clean
up, multiple rounds of make clean and then rebuilding. It is not a
console issue. It is not a machine ID issue. Both of these values are
not altered in this process of building and in bringing up the board
since I am using one single set of sources with and without
NetworkManager. UBoot remains un changed and is in flash on the board.

I am using a JTAG Debugger - the BDI 3000, on the JTAG port to load
the uImage. I followed the BDI 3000 document on how to debug the Linux
Kernel.

Step 1 - verify I can us the BDI to stop the Linux boot, single step,
then release it to boot to a user prompt.

I go through the process of adding a BDI breakpoint at "start_kernel"
address 0xc0008734 via the BDI 3000 on the known good uImage, the
board boots, the BDI stops the ARM, and I can single step the kernel
and then watch the kernel boot to a user prompt. So the process of
breaking, stepping, and then releasing the kernel is a working
process. Great.

When I do the same process on the problematic uImage, the BDI 3000
does NOT STOP at the "start_kernel" entry point at address 0xc00088b4
(different from the known good uImage). I issue the BDI "halt" command
to see what is going on in the ARM. The ARM is stuck looping in this
state:

Current PC 0x00000004

Current CPSR 0xdb (Undefined)

Current PC 0x00000008

Current CPSR 0xdb (Undefined)

Current PC 0x0000000C

Current CPSR 0xdb (Undefined)

Current PC 0x00000010

Current CPSR 0xd7 (Abort)

Current PC 0x00000014

Current CPSR 0xd7 (Abort)

Current PC 0x00000018

Current CPSR 0xd7 (Abort)

Then it loops around back to address 0x4, and the cycle seems to be
repeating forever, which is consistent with what I observe on the console.

I have no idea what this is about nor where to look for solutions. I need
your great wisdom to get me looking at what is going wrong to complete this
porting effort. Thanks very much everyone.

-- 

Robert Smigielski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170407/62e030ab/attachment.html>

[Buildroot] issue with Linux ARM start_kernel

[Peter Korsgaard]

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

 > Hi everyone,
 > I am a long time Linux device driver writer (about 16 years) and now for 3
 > years creating BSP's using Buildroot.

 > When I build using "make clean" then "make" - without NetworkManager in the
 > .config the board boots and runs for days. Great.
 > When I build using "make clean", reconfigure Buildroot to enable my custom
 > added NetworkManager=y, the build succeeds, the image is loaded on the
 > board, and I get the problem:

 > "Uncompressing Linux... done, booting the kernel."

From this and the description about loading uImage with a bdi, I take it
that your filesystem is an initramfs embedded in the uImage?

It would be interesting to check if your problem relates to the uImage
growing to a specific size (E.G. add some data files to the working
build instead).

What address are you loading the uImage to? It sounds like the
decompressor perhaps ends up overwriting itself.

-- 
Bye, Peter Korsgaard

[Buildroot] issue with Linux ARM start_kernel

[Robert Smigielski]

On Fri, Apr 7, 2017 at 3:27 PM, Peter Korsgaard <peter@korsgaard.com> wrote:

> >>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:
>
>  > Hi everyone,
>  > I am a long time Linux device driver writer (about 16 years) and now
> for 3
>  > years creating BSP's using Buildroot.
>
>  > When I build using "make clean" then "make" - without NetworkManager in
> the
>  > .config the board boots and runs for days. Great.
>  > When I build using "make clean", reconfigure Buildroot to enable my
> custom
>  > added NetworkManager=y, the build succeeds, the image is loaded on the
>  > board, and I get the problem:
>
>  > "Uncompressing Linux... done, booting the kernel."
>
> From this and the description about loading uImage with a bdi, I take it
> that your filesystem is an initramfs embedded in the uImage?
>
> Yes the file system is embedded in the uImage.


> It would be interesting to check if your problem relates to the uImage
> growing to a specific size (E.G. add some data files to the working
> build instead).
>
> What address are you loading the uImage to? It sounds like the
> decompressor perhaps ends up overwriting itself.
>

I load the uImage to address 0x2000000 and uboot reports loading it from
0x2000040.
The working uImage is approximately 14.7 MB and the non working uImage is
15.4 MB
The address 0x2000000 is a legacy value that has just been used in the past.

Since I am not familiar with the details of this part of the process can I
change the address to a larger value or to a smaller value? Which one makes
sense?

>
> --
> Bye, Peter Korsgaard
>



-- 
Robert Smigielski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170407/53861da9/attachment.html>

[Buildroot] issue with Linux ARM start_kernel

[Robert Smigielski]

Thank you sir! I did some experiments and found that altering the load
address to 0x1800000 corrects the problem and the board boots to a user
prompt!
A million thanks!

On Fri, Apr 7, 2017 at 3:42 PM, Robert Smigielski <ptdropper@gmail.com>
wrote:

>
> On Fri, Apr 7, 2017 at 3:27 PM, Peter Korsgaard <peter@korsgaard.com>
> wrote:
>
>> >>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:
>>
>>  > Hi everyone,
>>  > I am a long time Linux device driver writer (about 16 years) and now
>> for 3
>>  > years creating BSP's using Buildroot.
>>
>>  > When I build using "make clean" then "make" - without NetworkManager
>> in the
>>  > .config the board boots and runs for days. Great.
>>  > When I build using "make clean", reconfigure Buildroot to enable my
>> custom
>>  > added NetworkManager=y, the build succeeds, the image is loaded on the
>>  > board, and I get the problem:
>>
>>  > "Uncompressing Linux... done, booting the kernel."
>>
>> From this and the description about loading uImage with a bdi, I take it
>> that your filesystem is an initramfs embedded in the uImage?
>>
>> Yes the file system is embedded in the uImage.
>
>
>> It would be interesting to check if your problem relates to the uImage
>> growing to a specific size (E.G. add some data files to the working
>> build instead).
>>
>> What address are you loading the uImage to? It sounds like the
>> decompressor perhaps ends up overwriting itself.
>>
>
> I load the uImage to address 0x2000000 and uboot reports loading it from
> 0x2000040.
> The working uImage is approximately 14.7 MB and the non working uImage is
> 15.4 MB
> The address 0x2000000 is a legacy value that has just been used in the
> past.
>
> Since I am not familiar with the details of this part of the process can I
> change the address to a larger value or to a smaller value? Which one makes
> sense?
>
>>
>> --
>> Bye, Peter Korsgaard
>>
>
>
>
> --
> Robert Smigielski
>



-- 
Robert Smigielski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170407/43bb0273/attachment.html>

[Buildroot] issue with Linux ARM start_kernel

[Peter Korsgaard]

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

 > Thank you sir! I did some experiments and found that altering the load
 > address to 0x1800000 corrects the problem and the board boots to a user
 > prompt!

Ok, great!

 > A million thanks!

You're welcome!

-- 
Bye, Peter Korsgaard