none
Retailmsg in Kernel During Startup RRS feed

  • Question

  • Hi all,

    I am currently looking into an issue where occasionally we have boards that do not boot and are getting stuck immediately after OEMInit() completes. It looks like there are some useful RETAILMSG around this code but I do not see them on my serial port.

    While looking through the source code and NKStartup() in mdarm.c I can see that OEMInitDebugSerial() is called and shortly after there is an OEMWriteDebugString with the NKSignon message that appears on my debug serial port ok. However within the same function there are some RETAILMSG that would be useful to see, however they are not being output.

    Subsequently in OEMInit various OALMSG are being called and printed successfully via the debug serial. I believe this resolves to OEMWriteDebugString.

    From what I can tell by searching the source the RETAILMSG will should also resolve to OEMWriteDebugString so I am not sure why these messages within the kernel code are not being output. I must be missing something in the route to OEMWriteDebugString from RETAILMSG / NKDbgPrintfW.

    There is a RETAILMSG after OEMInit that starts "Booting Windows CE version...". I have searched online for this debug and see others have it in their debug output.

    I wondered if any of the experts on this forum might be able to help shed some light on what I am missing here as getting these RETAILMSG out of the debug port would help my investigations. From what I have read I shouldn't attempt to rebuild the kernel source with debugging modifications!

    Thank you in advance, Mark

    Wednesday, May 2, 2018 5:31 PM

All replies

  • What condition do you have in RETAILMSG? It's the first parameter. Set it to TRUE to always output.

    Of course any debug output will only appear on the serial debug port AFTER the call to OEMInitDebugSerial!


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6


    Wednesday, May 2, 2018 8:14 PM
    Moderator
  • Hi Michel,

    Thank you for your reply. The odd thing here is it is set to true! Order of code in mdarm.c (without sharing the full code for licensing reasons!):

    OEMInitDebugSerial ();

    ...

    OEMWriteDebugString ((LPWSTR)NKSignon); <- This is output on the serial port

    ...

    RETAILMSG (1, (L"Processor... <- Not output
    RETAILMSG (1, (L"OEMAddressTable... <- Not output

    ...

    OEMInit()

    -> OALMSG in OEMInit() <- All output

    Further RETAILMSG(1,... <- Not output

    Once drivers start loading RETAILMSG(1, are output.

    It seems odd that in the same function OEMWriteDebugString works but then a few lines down RETAILMSG(1, does not. I believe I have traced through from RETAILMSG but I am clearly missing something!

    Could it be that the private source does not match the kernel for latest updates?

    For reference one of the retail message I would expect to be printed is:

    Booting Windows CE version 6.00 for (ARM)...


    Mark



    • Edited by mwill195 Thursday, May 3, 2018 7:35 AM
    Thursday, May 3, 2018 7:24 AM
  • It's not odd. You're in the OAL, don't use RETAILMSG, use OALMSG (to debug channel, either serial or over KITL) or OALMSGS (always to serial).


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Thursday, May 3, 2018 7:30 AM
    Moderator
  • Michel,

    In this case it is not me using RETAILMSG but Microsoft in their own Kernel code.

    C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\mdarm.c (NKstartup)

    C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\loader.c (KernelFindMemory)

    In the meantime I managed to trace my issue a bit closer by adding OALMSG to OEMCacheRangeFlush as this is called at numerous points during the above two files and is source I can safely edit and build. Then counting the number of times it is output I can see where I am getting stuck in KernelFindMemory.

    However if the RETAILMSG(1,... Microsoft has put in that function worked then I would be able to hone the issue further.

    Mark

    Thursday, May 3, 2018 2:56 PM
  • Mark

    Are you using KITL at all?  If so, then RETAILMSG and DEBUGMSG will be output via KITL, not serial.


    Bruce Eitman
    Senior Enginer
    Bruce.Eitman AT Synopsys DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for
    Synopsys

    Thursday, May 3, 2018 5:54 PM
    Moderator
  • Hi Bruce,

    KITL is in the image but disabled. Actually a couple of these RETAILMSG are before KITL initialisation. Also subsequent RETAILMSG are output ok as drivers start up.

    I have managed to track my issue a bit closer. I am not used to trying to debug that early in startup. I am not sure if I can rebuild the kernel code if I were to modify it? I have read a few posts (from yourself, and Michel) that suggest that Microsoft does not provide the full source so this may not compile. I have the code on a VM that is snapshot so for the sake of debugging this issue I could have a go and always revert back.

    Mark

    Tuesday, May 8, 2018 7:28 AM