[SOLVED] BSP porting Question from 2.6.17 to 2.6.39

Hi,

The hardware forum is probably better suited for my question than the software forum.


My current task is to port a working non-mainline Board Support Package based on an ARM CPU (Embedded System) from the kernel 2.6.17 to 2.6.39. Do you have any documentation available which can help me achieving that task as there were major kernel changes regarding BSPs?

As of now, the init routines for the machine, IRQs and timer seem to work (or at least don't result in a kernel panic, debugged via JTAG), but I am not able to get the UART running (8250serial). I'm smelling issues with virtual/physical memory... Does anyone have experience in this regard and give me some hints?

Thanks in advance.

Originally Posted by prophEt666 My current task is to port a working non-mainline Board Support Package based on an ARM CPU (Embedded System) from the kernel 2.6.17 to 2.6.39.

The first thing I would do is create a patch file of all differences between mainline and the custom kernel.
Those changes (probably) need to be ported, as a new patch file for the 2.6.39 mainline kernel.

For each custom code module (that didn't exist in mainline), e.g. the board file and device drivers, I would look for the most similar file in mainline 2.6.17 to provide a baseline. The evolution of such a file from 2.6.17 to 2.6.39 is the guide for updating the custom module.

Other than the release notes for each kernel version, you're not going to find a guide for all the changes in internal kernel interfaces.

Originally Posted by prophEt666 ...but I am not able to get the UART running (8250serial). I'm smelling issues with virtual/physical memory.

In the Linux kernel the only intersection of physical and virtual memory is in the MMU and DMA.
If you suspect DMA issues, then switch to PIO mode as a test.

Regards

Thank you for your ideas.

Originally Posted by blue_z The first thing I would do is create a patch file of all differences between mainline and the custom kernel.

According to the patch file, the only differences are the BSP I have to port (the arm/mach folder) and a few drivers. As the 2.6.17 kernel was built using cygwin, a few makefiles also differ. In 2.6.17 the include directory for a BSP (containing hardware.h, memory.h, ...) was not part of the arch/mach folder, but that should not be of a problem.

I have compared the BSPs of 2.6.17/2.6.39 from other machines/architectures (like OMAP1/2). There were major changes regarding hardware timers (the concepts of clockevents/clocksources have been introduced in the meantime). To be honest, I do not yet completely understand those "new" concepts. Do I have to adapt them or will the old way (configuring hw timer, setting up IRQ, timer_tick for kernel, ...) without clockevents/sources work too?

Originally Posted by blue_z In the Linux kernel the only intersection of physical and virtual memory is in the MMU and DMA.

As far as I have seen, the original BSP does not contain any DMA code. I probably have to integrate that piece at a later stage (primarily for eMMC performance) when the kernel is successfully booting. The support of newer eMMC cards is the main reason for switching to the newer kernel. Which leaves the MMU as a possible source of issues.

I have tried to enable KERNEL_DEBUG_LL and EARLY_PRINTK in the hopes of getting UART output, but I haven't had any luck so far. The asm macro "addruart" ((contained in mach/debug_macro.S) which is responsible for DEBUG_LL output) did get a new parameter added between 2.6.17 and 2.6.39 as the check for active MMU has been moved to debug.S in the kernel. As far as I understand, the first parameter stores the physical, the second one the virtual address. So hardcoding those UART addresses within the asm macro should suffice for a test. The other macros senduart, waituart, buyuart should be the same as in the original kernel. Nevertheless, I don't see any output yet. I assume that the calculation physical address to virtual address stays the same between kernels as this should be a CPU specific thing?

Best regards

Originally Posted by prophEt666 According to the patch file, the only differences are the BSP I have to port (the arm/mach folder) and a few drivers.

(Real kernel developers don't use GUI terms like "folders" in place of proper filesystem terms.)
What is this mystery BSP?
Is this for a proprietary board design, or a board based on a reference design, or is there a complete arch/arm/mach-xxx directory that's not in mainline?

Regards

Originally Posted by blue_z (Real kernel developers don't use GUI terms like "folders" in place of proper filesystem terms.)

Hehe, well I originally was a Java developer. I switched to embedded systems after my studies because it's way cooler . So probably thats why I'm prone to mixing up terms. So, porting BSPs between different kernels is kinda new to me as you can tell.

Originally Posted by blue_z Is this for a proprietary board design ...

Yes, you have guessed it. Also, the CPU is an old ARM922T(v4t) which is not produced anymore. My task is to do some performance optimizations for the existing design.

Best regards.

Originally Posted by prophEt666 >Is this for a proprietary board design ... Yes, you have guessed it. Also, the CPU is an old ARM922T(v4t) which is not produced anymore.

That's not the information I'm looking for.
Is this processor in an SoC?
And isn't there already an arch/arm/mach-xxx directory in mainline, and that this BSP provides a board file plus header files?
Did you customize the BSP board file?

Originally Posted by prophEt666 Which leaves the MMU as a possible source of issues.

You're trying to catch the wind.
The ARM922T has been supported in the mainline Linux kernel.
You're probably using mainline code for all the processor and MMU functionality.
That's mature code, and you're using it in a conventional manner, so the likelihood of you encountering an "issue" is very remote.

Originally Posted by prophEt666 There were major changes regarding hardware timers .... Do I have to adapt them .

Yes. Certainly before you start "debugging" and speculating where the issues are.
IIRC management of clock resources was introduced in early 2.6.2x, and UARTs need a clock source for the baudrate generator.


Regards

Originally Posted by blue_z Is this processor in an SoC? And isn't there already an arch/arm/mach-xxx directory in mainline, and that this BSP provides a board file plus header files? Did you customize the BSP board file?

The arch/arm/mach-xxx (in my understanding this is the BSP, excluding drivers, please correct me if I'm wrong) is only part of my customized 2.6.17. I moved the mach-xxx (with the board file/header files) from the customized 2.6.17 to 2.6.39. The BSP also contains code for IRQ handling, GPIOs and hardware timer support. There are 2 additional drivers associated with this machine: an SPI and MTD map driver.

I customized the Kconfig files for ARM to be able to build the BSP/the drivers for ARM922T like it was done in my custom 2.6.17. I also had to add the machine type into mach-types.h. After fixing a few minor syntax errors because of API changes, removed header files (like linux/config.h), ... the kernel built successfully for my machine. The basic boot process also "seems to work": map_io, init_irq, init_machine are all executed ("debugged" via JTAG).

Now I'm gradually looking at the various components of the BSP by comparing existing ARM architectures from 2.6.17 to 2.6.39 and how they have changed over time, so that I can adapt them for my machine if needed. The first thing I wanted to get working is the UART for obvious reasons.

Originally Posted by blue_z The ARM922T has been supported in the mainline Linux kernel. You're probably using mainline code for all the processor and MMU functionality.

Yes, there is no CPU-specific setup code in the BSP. Reading the CP15 registers via JTAG also revealed that the MMU is active.

Originally Posted by blue_z IIRC management of clock resources was introduced in early 2.6.2x, and UARTs need a clock source for the baudrate generator.

Is this also true for EARLY_PRINTK? AFAIK, this functionality is realized by the ASM routines defined in debug.S (which includes debug_macro.S from the BSP). How is the baud rate generated in this case?

Thanks for the hint to integrate the clock source/events.

Best regards.

I finally managed to get the UART running and the 2.6.39 kernel booting on the embedded device. In the end, it was easier than expected. I did not know that EARLY_PRINTK has to be configured via the kernel boot parameters to use the UART. After I added the parameter and changed the addruart asm macro, I was able to see the boot messages.

Those messages revealed that both 8250 UART ports did not register successfully with the kernel (EINVAL was returned). After some debugging it was clear that the uartclk struct member of the ports contained a strange value. This value should have been the hclk of the device derived from the PLL register set by doing some calculations, so I was reading garbage from those registers. It turned out that I actually wasn't reading from the PLL register because during my port procedure the address got changed somehow (probably my own fault, anyways I checked the rest of the I/O addresses, they are all correct). After this got fixed the kernel bootet up successfully and I was able to interact with the shell via UART.

Best regards.