From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jian Luo Date: Tue, 19 Jul 2016 18:44:44 +0200 Subject: [U-Boot] u-boot: x86: interrupt mapping In-Reply-To: References: <578DDEE9.3060803@boschrexroth.de> Message-ID: <578E58FC.9040409@boschrexroth.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Christian, I took some time to recall what I did by patching FSP: - search in every PE32 and TE image section for binary sequence 81c9000100008908c6460e01 and change to 81c9000102008908c6460e00 - then replace them in-place The difference can be better understand if disassemblies are compared, eg: Disassembly of section .data: @@ -3367,9 +3367,9 @@ 25fc: 05 00 05 00 00 add $0x500,%eax 2601: 8b 08 mov (%eax),%ecx 2603: 81 e1 ff ff f8 ff and $0xfff8ffff,%ecx - 2609: 81 c9 00 01 00 00 or $0x100,%ecx + 2609: 81 c9 00 01 02 00 or $0x20100,%ecx What I did here is setting BAUDSEL to SYS_25MHz. 260f: 89 08 mov %ecx,(%eax) - 2611: c6 46 0e 01 movb $0x1,0xe(%esi) + 2611: c6 46 0e 00 movb $0x0,0xe(%esi) Can't recall why I did this, maybe bypassing PLL altogether? 2615: c6 46 0f 00 movb $0x0,0xf(%esi) 2619: c6 46 03 83 movb $0x83,0x3(%esi) 261d: c6 46 01 00 movb $0x0,0x1(%esi) Since I don't rely on Topcliff UART for output, the baud rate recalculation is all skipped. Best regards, *Jian Luo DC-IA/EAH2* Tel. +49(9352)18-4266 *Be**QIK * On 19.07.2016 17:21, Christian Gmeiner wrote: > Hi Jian, > >> For the moment I have no answer to this question. I need to dive into >> the vxworks code, which >> is not what I like to do now (but needs to be done)- >> >> Yes, please do track it down. The interrupt line register configured >> by U-Boot should be enough for VxWorks to function under PIC mode. >> >> I have an other (wired) question you may could help out. >> >> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf >> (page 124) >> >> On my development board the uart_clk is connected to a oscillator and >> everything works as expected. >> But on the production devices the uart_clk is not connected and fsp >> hangs with post code 0x2e. >> >> I am not sure about the meaning of post code 0x2e. Jian has some >> working experience on Atom E6xx with U-Boot. Adding him. >> >> 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h) >> >> Now I would like to change the initial mux settings to use usb_48mhz >> but I am quite sure that I need >> to have the pci bus and its devices initialised already in order to >> change the CLKCFG register. Do you >> think there is an other way of accessing this register like fixed >> memory address etc? >> >> Which register do you want to program for this uart_clk? If it's on >> the PCI configuration space, you can use PCI config APIs to program. >> >> There a handful of registers I would need to program but all of them are >> accessible via pic config space. E.g CLKCFG: >> >> Size: 32-bit Default: 20000C00 Power Well: Core >> Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h >> Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h >> >> >> As I need to program those registers before fsp_init I must setup the pci >> bus by myself, change the register values and call fsb_init routine. >> Correct? >> >> My board had this problem too. I however toke a different approach >> by patching the original FSP. The waiting for Topcliff UART ready is >> completely >> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in >> the attached FSP for comparison. >> > Sooo... I did use the UEFITool to compare your fsp with mine and yeah... > some files are different. > > File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin > Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin > Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin > Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin > Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin > Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin > Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin > Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin > Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin > Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin > Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin > File_PEI_module_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt > File_PEI_module_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt > File_PEI_module_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt > Section_Compressed_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt > Section_Compressed_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt > Section_Compressed_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt > Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt > Section_PEI_dependency_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt > Section_PEI_dependency_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt > > Any hint at what to look for? Sadly I am not an UEFI guy. > > greets > -- > Christian Gmeiner, MSc > > https://soundcloud.com/christian-gmeiner