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. |
Quote:
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. Quote:
If you suspect DMA issues, then switch to PIO mode as a test. Regards |
Thank you for your ideas.
Quote:
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? Quote:
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 |
Quote:
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 |
Quote:
Quote:
Best regards. |
Quote:
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? Quote:
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. Quote:
IIRC management of clock resources was introduced in early 2.6.2x, and UARTs need a clock source for the baudrate generator. Regards |
Quote:
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. Quote:
Quote:
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. |
All times are GMT -5. The time now is 08:11 AM. |