Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme, On Thu, Mar 22, 2012 at 4:41 PM, Graeme Russ wrote: > Hi Simon, > > On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass wrote: > >> I am going to have a similar problem in the SPL soon - how to deal >> with panic(). Advice gratefully accepted. > > Take a leaf out of the Linux x86 source > > arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code > which is entered by the boot loader (so it's like SPL - IPL being the > BIOS/Bootloader combo) > > void main(void) > { > /* First, copy the boot header into the "zeropage" */ > copy_boot_params(); > > /* Initialize the early-boot console */ > console_init(); > ... > > > arch/x86/boot/early_serial_console.c > > void console_init(void) > { > parse_earlyprintk(); > > if (!early_serial_base) > parse_console_uart8250(); > } > > early_serial_base is a global defined in boot.h: > > extern int early_serial_base; > > You can do the same in SPL, but you are not going to have the luxury of > having it configurable unless you can do so in some non-volatile memory > or hardware configuration (dedicated GPIO pins etc) > > It's a chicken and egg scenario - If you want your default console port to > be configurable, you need code to determine the configuration. But you > cannot spew out debug messages for the code which determines the console > configuration. Linux x86 has the same problem, there is no way to ouput > debug messages in copy_boot_params() or console_init() > > In U-Boot we kind of 'cheat' - We define a board specific default console > in the board config (hard coded in the U-Boot binary) which we use unitl > environment variables are available. Linux x86 could do the same - have > compile time options which allow the serial console to be enabled before > copy_boot_params(), but the amount of code which is 'dark' is so small > it's not worth it. > > U-Boot is different, the amount of code that is 'dark' before the > environment variables are available is rather large. And pre console > buffer covers the 'dark' code just prior to the hard-coded console being > available (but of course pre console buffer does not help if there is a > hang or crash before the hard-coded console is available) Thanks very much for your comments. Yes it is this dark period that bothers me. I think for now the solution is to ignore it and hope that nothing goes wrong, particularly with the revert of even the pre-console putc(). I think for now I will provide an option to check the device tree later in the boot, and later look at having some sort of fallback config for the console. > > I should check - Is it possible to not have a default console, and > therefor pre console buffer is used all the way up to the console defined > in the environment being intialised? I actually created a patch to delay console init until after relocation, just to see how this might work. It works fine, and does speed things up a little, but is of course not in keeping with the U-Boot design. Anyway all I am really concerned about is that we might not make it through the dark period. For now I am going to forget about that problem; there are plenty of others. Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Simon, On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass wrote: > I am going to have a similar problem in the SPL soon - how to deal > with panic(). Advice gratefully accepted. Take a leaf out of the Linux x86 source arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code which is entered by the boot loader (so it's like SPL - IPL being the BIOS/Bootloader combo) void main(void) { /* First, copy the boot header into the "zeropage" */ copy_boot_params(); /* Initialize the early-boot console */ console_init(); ... arch/x86/boot/early_serial_console.c void console_init(void) { parse_earlyprintk(); if (!early_serial_base) parse_console_uart8250(); } early_serial_base is a global defined in boot.h: extern int early_serial_base; You can do the same in SPL, but you are not going to have the luxury of having it configurable unless you can do so in some non-volatile memory or hardware configuration (dedicated GPIO pins etc) It's a chicken and egg scenario - If you want your default console port to be configurable, you need code to determine the configuration. But you cannot spew out debug messages for the code which determines the console configuration. Linux x86 has the same problem, there is no way to ouput debug messages in copy_boot_params() or console_init() In U-Boot we kind of 'cheat' - We define a board specific default console in the board config (hard coded in the U-Boot binary) which we use unitl environment variables are available. Linux x86 could do the same - have compile time options which allow the serial console to be enabled before copy_boot_params(), but the amount of code which is 'dark' is so small it's not worth it. U-Boot is different, the amount of code that is 'dark' before the environment variables are available is rather large. And pre console buffer covers the 'dark' code just prior to the hard-coded console being available (but of course pre console buffer does not help if there is a hang or crash before the hard-coded console is available) I should check - Is it possible to not have a default console, and therefor pre console buffer is used all the way up to the console defined in the environment being intialised? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Thu, Mar 22, 2012 at 4:00 PM, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: >> >> >> Yes, it is there, sorry. >> > >> > Which commit is that? >> >> It was 295d3942: Add board_pre_console_putc to deal with early console outp= >> ut >> >> The discussion threads are around here: >> >> http://lists.denx.de/pipermail/u-boot/2011-August/099620.html >> >> >> If you are looking for a revert :-) >> >> http://patchwork.ozlabs.org/patch/147617/ > > Yes, this should be reverted, indeed. OK, well you have it there. I am going to have a similar problem in the SPL soon - how to deal with panic(). Advice gratefully accepted. Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Nothing ever becomes real till it is experienced -- even a proverb is > no proverb to you till your life has illustrated it. - John Keats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon Glass, In message you wrote: > > I am going to have a similar problem in the SPL soon - how to deal > with panic(). Advice gratefully accepted. The SPL code is not special in this regard: initialize the console port as soon as possible; then use it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A Stanford research group advertised for participants in a study of obsessive-compulsive disorder. They were looking for therapy clients who had been diagnosed with this disorder. The response was grati- fying; they got 3,000 responses about three days after the ad came out. All from the same person. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon, In message you wrote: > > >> Yes, it is there, sorry. > > > > Which commit is that? > > It was 295d3942: Add board_pre_console_putc to deal with early console outp= > ut > > The discussion threads are around here: > > http://lists.denx.de/pipermail/u-boot/2011-August/099620.html > > > If you are looking for a revert :-) > > http://patchwork.ozlabs.org/patch/147617/ Yes, this should be reverted, indeed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. - John Keats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Stephen, On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren wrote: > I was under the impression that earlyprintk was a boolean option, and > didn't take any arguments. But, a quick grep shows that some archs do > allow it to take an argument. The ARM code that handles the option > doesn't process the argument at present as far as I can tell, although > many ARM defconfigs do provide one. I'll see if it's possible to rework > the Tegra kernel code to use any earlyprintk argument. If you're going to look at getting earlyprintk able to take arguments, this bug (and the associated links) might be of interest to you: http://code.google.com/p/chromium-os/issues/detail?id=19185 It would certainly be nice to get earlyprintk able to take arguments on ARM in the kernel. I didn't originally go down that route because it seemed like there were going to be lots of yaks to shave and it would involve changes to some of the core Linux ARM boot code. It also didn't solve the problem where the ARM kernel wants to do prints before translation (as Olof points out in in the discussion thread linked above). ...but it does seem to be the better route. > I doubt it will be possible to do this in the ARM zImage decompressor > though. The "decompressing" part of the kernel wouldn't come for free without a lot of work, but maybe the right answer is to leverage u-boot's ability to decompress the kernel and stop using the zImage anyway. That would make Simon happy, I think. -Doug ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Thu, Mar 22, 2012 at 6:25 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: >> >> >> OK, so revert that commit? >> > >> > It hasn't hit mainline yet, or has it? >> >> Yes, it is there, sorry. > > Which commit is that? It was 295d3942: Add board_pre_console_putc to deal with early console output The discussion threads are around here: http://lists.denx.de/pipermail/u-boot/2011-August/099620.html If you are looking for a revert :-) http://patchwork.ozlabs.org/patch/147617/ > >> > This is why initializing the serial console has always been one of the >> > very, very first initialization steps in U-Boot. >> >> So if actually you want a pre-console panic() to be silent then that's fine. > > I do not _want_ it. > > This is a simple matter of facts that cannot be avoided. If we cannot > initialize the consolem then we cannot print anything. > >> It's a little unfriendly though - so would you be interested in >> keeping board_pre_console_putc() around if we could solve this >> entirely with code in there? It turns out that Tegra has a setting for >> console UART in the hardware parameters that we can access.( I won't >> ask you about how to handle a panic() in SPL yet). > > If you can initialize the console in a way that allows sending > characters, then just do this - do this as part of the recular > fconsole init code, so we do have a working console, and we do not > need ay "pre-console" stuff. > OK, let's leave it for now, I don't see a way of achieving this in the case of an early panic. Regards, Simon > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > It is common sense to take a method and try it. If it fails, admit it > frankly and try another. But above all, try something. > - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon Glass, In message you wrote: > > >> OK, so revert that commit? > > > > It hasn't hit mainline yet, or has it? > > Yes, it is there, sorry. Which commit is that? > > This is why initializing the serial console has always been one of the > > very, very first initialization steps in U-Boot. > > So if actually you want a pre-console panic() to be silent then that's fine. I do not _want_ it. This is a simple matter of facts that cannot be avoided. If we cannot initialize the consolem then we cannot print anything. > It's a little unfriendly though - so would you be interested in > keeping board_pre_console_putc() around if we could solve this > entirely with code in there? It turns out that Tegra has a setting for > console UART in the hardware parameters that we can access.( I won't > ask you about how to handle a panic() in SPL yet). If you can initialize the console in a way that allows sending characters, then just do this - do this as part of the recular fconsole init code, so we do have a working console, and we do not need ay "pre-console" stuff. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Wed, Mar 21, 2012 at 4:07 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: >> >> > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() >> > stuff, because this is bogus. If you do output to a serial UART port, >> > this _is_ your console. Just use it in the standard war. >> > >> > I made my mind up: I want to get rid of all this "pre_console" UART >> > stuff. >> >> OK, so revert that commit? > > It hasn't hit mainline yet, or has it? Yes, it is there, sorry. > >> In that case I have a question. How can we get console output in the >> event of a panic before console_ready() is called? > > You cannot, by definition. You cannot output anything to the console > without initializing it before. > > This is why initializing the serial console has always been one of the > very, very first initialization steps in U-Boot. So if actually you want a pre-console panic() to be silent then that's fine. It's a little unfriendly though - so would you be interested in keeping board_pre_console_putc() around if we could solve this entirely with code in there? It turns out that Tegra has a setting for console UART in the hardware parameters that we can access.( I won't ask you about how to handle a panic() in SPL yet). Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > There are three ways to get something done: do it yourself, hire > someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon Glass, In message you wrote: > > > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() > > stuff, because this is bogus. If you do output to a serial UART port, > > this _is_ your console. Just use it in the standard war. > > > > I made my mind up: I want to get rid of all this "pre_console" UART > > stuff. > > OK, so revert that commit? It hasn't hit mainline yet, or has it? > In that case I have a question. How can we get console output in the > event of a panic before console_ready() is called? You cannot, by definition. You cannot output anything to the console without initializing it before. This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Wed, Mar 21, 2012 at 3:56 PM, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: >> >> 3. What you propose is actually very easy to implement - it just >> requires a new config like CONFIG_DEFAULT_UART or >> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >> board_pre_console_putc() code. > > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() > stuff, because this is bogus. If you do output to a serial UART port, > this _is_ your console. Just use it in the standard war. > > I made my mind up: I want to get rid of all this "pre_console" UART > stuff. OK, so revert that commit? In that case I have a question. How can we get console output in the event of a panic before console_ready() is called? Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "The first rule of magic is simple. Don't waste your time waving your > hands and hoping when a rock or a club will do." > - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Stephen, In message <4f6a1d1e.2090...@wwwdotorg.org> you wrote: > > But the last few messages in this thread have all been about the > following as far as I'm concerned: > > * The U-Boot configuration defines which single UART to use for the > initial console. > > * This initial console is registered early enough that almost all > failures can be reported. In particular, something as non-critical as > locating and parsing the DT should happen after this initial console is > registered, so that DT existence/parsing problems can be reported to > this initial console. > > By non-critical here, I mean that there should be no reason to require > the DT to be parsed in order for the CPU to boot, and the initial > UART-based console to be registered. DT parsing shouldn't be attempted > until this basic level of operation is achieved; it should be be > required that the DT be parsed for any of that to work. > > * When the DT is parsed later, the console specification from DT > replaces the initial console. > > With this scheme in place, there surely isn't any need for any kind of > special-case early putc/puts/printf - wasn't this exactly Wolfgang's point? Correct, that's what I have in mind. Actually we already do the same in other situations - for example on systems with console on LCD, whih becomes available pretty late in the boot sequence. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de They weren't that important. They were merely at the top. The people who really run organizations are usually found several levels down, where it's still possible to get things done. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon, In message you wrote: > > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war. I made my mind up: I want to get rid of all this "pre_console" UART stuff. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Stephen Warren, In message <4f6a01d3.3020...@wwwdotorg.org> you wrote: > > > It appears that all you are trying here is an annoying, but somewhat > > unlikely error situation. As marked above (see *), it might make > > sense to think of alternative ways to find out what the console port > > might be. One possibility to do this is to use the environment. > > You need access to the environment anyway to initialize the console > > port (for reading the "baudrate" setting). So why not encoding the > > console UART port for example as part of a "hwconfig" setting? This > > setting could be auto-initialized when you load a DT on this board > > (eventually after verifying that it works). ... > I'd prefer to just have a different U-Boot (build) config for each HW > configuration, and define the console UART as part of that configuration > using the existing defines that are for that purpose. This is another option - at the cost of maintaining separate binary images. > If we put the UART ID into the environment, then we either need to: > > a) Have a different U-Boot configuration anyway, in order to define the > different environment during the U-Boot build process. > > b) Post-process the U-Boot binary after building it, in order to modify > the environment that's contained in that binary. Not true. In the normal course of events, the board would boot with a working device tree provided, which provides correct console information. This could be used to auto-initialize the correct environment settings. You just have to make sure that board boots a single time with a working DT image - I don't know how production tests and/or software commissioning on these boards is organized, but this seems to be a possible route to me. [Been there, done that before. About 12 years before, IIRC.] You probably also need to program MAC addresses etc. ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Pardon me for breathing, which I never do anyway so I don't know why I bother to say it, oh God, I'm so depressed. Here's another of those self-satisfied doors. Life! Don't talk to me about life." - Marvin the Paranoid Android ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 11:50 AM, Simon Glass wrote: > Hi Stephen, > > On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren > wrote: >> On 03/21/2012 11:13 AM, Simon Glass wrote: >>> Hi Stephen, >>> >>> On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren >>> wrote: On 03/21/2012 10:59 AM, Simon Glass wrote: > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option? >>> >>> These will only exist when CONFIG_OF_CONTROL is not defined. It might >>> confusing to use the same CONFIGs for the pre-console panic() case, >>> knowing that they will in fact be ignored in a normal boot. I would >>> suggest a new option, at least in the CONFIG_OF_CONTROL case where the >>> two options you mention will not be used. >> >> Oh. >> >> But in u-boot-tegra/master, both Seaboard and Ventana still set those >> options even though they have CONFIG_OF_CONTROL turned on. And it looks >> like board_init_uart_f() both uses those defines irrespective of >> CONFIG_OF_CONTROL /and/ is called solely based on >> CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined >> for Seaboard and Ventana. > > Yes that's true. I have not yet prepared an upstream patch to fix > this. I will get to this one we have USB/I2C in, but in the meantime, > this series will probably nearly apply. The third patch is the main > event. > > https://gerrit.chromium.org/gerrit/#change,18256 > https://gerrit.chromium.org/gerrit/#change,18255 > https://gerrit.chromium.org/gerrit/#change,18257 > https://gerrit.chromium.org/gerrit/#change,18259 > >> >> I thought the upshot of this discussion was that there wasn't any need >> for any kind of pre-console stuff, either putc, puts/printf or whatever; >> instead, the console should simply be registered as early as possible >> based on the board/config's UART selection? > > Not quite - going back to your previous message, if there is a panic > before the console is ready (and in the event of there being no fdt) I > would like to offer a message on a UART selected by a CONFIG. > >> >> (and of course the DT parsed after that console was registered; no need >> for it before) > > The DT must be parsed before the console is registered - after all the > DT tells us which is the console. Yes, we can't know what console the DT says to use until the DT is located and parsed. That much is blatantly obvious. But the last few messages in this thread have all been about the following as far as I'm concerned: * The U-Boot configuration defines which single UART to use for the initial console. * This initial console is registered early enough that almost all failures can be reported. In particular, something as non-critical as locating and parsing the DT should happen after this initial console is registered, so that DT existence/parsing problems can be reported to this initial console. By non-critical here, I mean that there should be no reason to require the DT to be parsed in order for the CPU to boot, and the initial UART-based console to be registered. DT parsing shouldn't be attempted until this basic level of operation is achieved; it should be be required that the DT be parsed for any of that to work. * When the DT is parsed later, the console specification from DT replaces the initial console. With this scheme in place, there surely isn't any need for any kind of special-case early putc/puts/printf - wasn't this exactly Wolfgang's point? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren wrote: > On 03/21/2012 11:13 AM, Simon Glass wrote: >> Hi Stephen, >> >> On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren >> wrote: >>> On 03/21/2012 10:59 AM, Simon Glass wrote: 3. What you propose is actually very easy to implement - it just requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code. >>> >>> One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and >>> CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those >>> is appropriate for this, rather than inventing yet another config option? >> >> These will only exist when CONFIG_OF_CONTROL is not defined. It might >> confusing to use the same CONFIGs for the pre-console panic() case, >> knowing that they will in fact be ignored in a normal boot. I would >> suggest a new option, at least in the CONFIG_OF_CONTROL case where the >> two options you mention will not be used. > > Oh. > > But in u-boot-tegra/master, both Seaboard and Ventana still set those > options even though they have CONFIG_OF_CONTROL turned on. And it looks > like board_init_uart_f() both uses those defines irrespective of > CONFIG_OF_CONTROL /and/ is called solely based on > CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined > for Seaboard and Ventana. Yes that's true. I have not yet prepared an upstream patch to fix this. I will get to this one we have USB/I2C in, but in the meantime, this series will probably nearly apply. The third patch is the main event. https://gerrit.chromium.org/gerrit/#change,18256 https://gerrit.chromium.org/gerrit/#change,18255 https://gerrit.chromium.org/gerrit/#change,18257 https://gerrit.chromium.org/gerrit/#change,18259 > > I thought the upshot of this discussion was that there wasn't any need > for any kind of pre-console stuff, either putc, puts/printf or whatever; > instead, the console should simply be registered as early as possible > based on the board/config's UART selection? Not quite - going back to your previous message, if there is a panic before the console is ready (and in the event of there being no fdt) I would like to offer a message on a UART selected by a CONFIG. > > (and of course the DT parsed after that console was registered; no need > for it before) The DT must be parsed before the console is registered - after all the DT tells us which is the console. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 11:13 AM, Simon Glass wrote: > Hi Stephen, > > On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren > wrote: >> On 03/21/2012 10:59 AM, Simon Glass wrote: >>> 3. What you propose is actually very easy to implement - it just >>> requires a new config like CONFIG_DEFAULT_UART or >>> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >>> board_pre_console_putc() code. >> >> One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and >> CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those >> is appropriate for this, rather than inventing yet another config option? > > These will only exist when CONFIG_OF_CONTROL is not defined. It might > confusing to use the same CONFIGs for the pre-console panic() case, > knowing that they will in fact be ignored in a normal boot. I would > suggest a new option, at least in the CONFIG_OF_CONTROL case where the > two options you mention will not be used. Oh. But in u-boot-tegra/master, both Seaboard and Ventana still set those options even though they have CONFIG_OF_CONTROL turned on. And it looks like board_init_uart_f() both uses those defines irrespective of CONFIG_OF_CONTROL /and/ is called solely based on CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined for Seaboard and Ventana. I thought the upshot of this discussion was that there wasn't any need for any kind of pre-console stuff, either putc, puts/printf or whatever; instead, the console should simply be registered as early as possible based on the board/config's UART selection? (and of course the DT parsed after that console was registered; no need for it before) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren wrote: > On 03/21/2012 10:59 AM, Simon Glass wrote: >> 3. What you propose is actually very easy to implement - it just >> requires a new config like CONFIG_DEFAULT_UART or >> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >> board_pre_console_putc() code. > > One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and > CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those > is appropriate for this, rather than inventing yet another config option? These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 10:59 AM, Simon Glass wrote: > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren wrote: > On 03/21/2012 04:35 AM, Graeme Russ wrote: >> Hi Stephen, Wolfgang, >> >> On 03/21/2012 08:38 PM, Wolfgang Denk wrote: >>> Dear Simon Glass, >>> >>> In message >>> you >>> wrote: >> >>> We have standard ways of telling the Linux kernel what the console >>> port is - the "console=" boot argument has been working fine for many, >>> many years and many, many boards and systems. But Tegra needs to >>> invent it's own hackinsh implementation of putting special data in >>> some special registers. What a crap. >> >> This made me look into the x86 code - There is a command line option >> 'earlyprintk' which is available stupidly early (even the real-mode code >> and de-compressor have access to it) >> >> So I do now wonder why Tegra needs to do anything differently > > I was under the impression that earlyprintk was a boolean option, and > didn't take any arguments. But, a quick grep shows that some archs do > allow it to take an argument. The ARM code that handles the option > doesn't process the argument at present as far as I can tell, although > many ARM defconfigs do provide one. I'll see if it's possible to rework > the Tegra kernel code to use any earlyprintk argument. > > I doubt it will be possible to do this in the ARM zImage decompressor > though. > > Perhaps the kernel should follow these rules: > > If the kernel .config specifies a UART to output the early messages to, > then we use that by default (both for the zImage decompressor and > earlyprintk if enabled). This option can already include "none" which > would be safe across arbitary boards as a default. > > The zImage decompressor will always use that UART. If there are issues > in the decompressor, rebuild the kernel for the specific UART for the > board being tested to see the error spew. > > The kernel proper will parse any earlyprintk argument, and override the > UART specified in .config if an earlyprintk argument is present. > > This makes debugging zImage decmopressor issues slightly more annoying, > but (a) we'll probably have to do something like this for multi-SoC > kernel images anyway, and (b) zImage decompressor issues are quite rate. > > I suppose we could apply the same approach to U-Boot too: Have the > U-Boot configuration specify a UART to use for the console, which would > have to be "none" by default for maximum safety in a multi-board U-Boot > (build) config, but could be the single correct one for a single-board > U-Boot config. Then, replace this console with the one from DT once DT > is parsed. > > This would again make debugging a multi-board U-Boot config's boot hang > more annoying, since you'd have to rebuild in order to set a specific > "early" UART for the console, but at least it'd be possible. > > Then, we just have to make sure that this "early" console is always > available before any panic due to missing DT, so that problem would at > least be discoverable after setting the UART to use. Hopefully this > "early" console would be registered early enough that there are very > very few things that can fail before it... > > Tom/Simon: Does the U-Boot side of this sound acceptable to you? 1. I think we have agreed that we cannot and will not (at least for now) solve the problem of trying to get a message to the user during a panic() when we don't even know the console UART. 2. Given (1), it seems reasonable to allow the board config to select an 'early console UART' (which may be NONE) for use for very early panics in U-Boot. If this is not set, or set incorrectly, then no output will be visible. 3. What you propose is actually very easy to implement - it just requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code. So yes, I think it is acceptable. [[[ If I may comment on the Linux side, I think it is worth at least checking whether it is possible to find the UART in the zImage decompressor using the earlyprintk=... setting. It would solve the problem of this patch at least. Even if we need to just look at the number at the end of the setting and use that UART number :-( ]]] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 04:35 AM, Graeme Russ wrote: > Hi Stephen, Wolfgang, > > On 03/21/2012 08:38 PM, Wolfgang Denk wrote: >> Dear Simon Glass, >> >> In message >> you >> wrote: > >> We have standard ways of telling the Linux kernel what the console >> port is - the "console=" boot argument has been working fine for many, >> many years and many, many boards and systems. But Tegra needs to >> invent it's own hackinsh implementation of putting special data in >> some special registers. What a crap. > > This made me look into the x86 code - There is a command line option > 'earlyprintk' which is available stupidly early (even the real-mode code > and de-compressor have access to it) > > So I do now wonder why Tegra needs to do anything differently I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument. I doubt it will be possible to do this in the ARM zImage decompressor though. Perhaps the kernel should follow these rules: If the kernel .config specifies a UART to output the early messages to, then we use that by default (both for the zImage decompressor and earlyprintk if enabled). This option can already include "none" which would be safe across arbitary boards as a default. The zImage decompressor will always use that UART. If there are issues in the decompressor, rebuild the kernel for the specific UART for the board being tested to see the error spew. The kernel proper will parse any earlyprintk argument, and override the UART specified in .config if an earlyprintk argument is present. This makes debugging zImage decmopressor issues slightly more annoying, but (a) we'll probably have to do something like this for multi-SoC kernel images anyway, and (b) zImage decompressor issues are quite rate. I suppose we could apply the same approach to U-Boot too: Have the U-Boot configuration specify a UART to use for the console, which would have to be "none" by default for maximum safety in a multi-board U-Boot (build) config, but could be the single correct one for a single-board U-Boot config. Then, replace this console with the one from DT once DT is parsed. This would again make debugging a multi-board U-Boot config's boot hang more annoying, since you'd have to rebuild in order to set a specific "early" UART for the console, but at least it'd be possible. Then, we just have to make sure that this "early" console is always available before any panic due to missing DT, so that problem would at least be discoverable after setting the UART to use. Hopefully this "early" console would be registered early enough that there are very very few things that can fail before it... Tom/Simon: Does the U-Boot side of this sound acceptable to you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 03:38 AM, Wolfgang Denk wrote: ... > To bring this to a constructive end: > > It appears that all you are trying here is an annoying, but somewhat > unlikely error situation. As marked above (see *), it might make > sense to think of alternative ways to find out what the console port > might be. One possibility to do this is to use the environment. > You need access to the environment anyway to initialize the console > port (for reading the "baudrate" setting). So why not encoding the > console UART port for example as part of a "hwconfig" setting? This > setting could be auto-initialized when you load a DT on this board > (eventually after verifying that it works). > > OK, there is still a chance that the environment settings are missing > or incorrect _and_ the DT cannot be loaded, but the probability for > such a double-fault is much, much smaller. > > Could this be an acceptable solution for you? I'd prefer to just have a different U-Boot (build) config for each HW configuration, and define the console UART as part of that configuration using the existing defines that are for that purpose. If we put the UART ID into the environment, then we either need to: a) Have a different U-Boot configuration anyway, in order to define the different environment during the U-Boot build process. b) Post-process the U-Boot binary after building it, in order to modify the environment that's contained in that binary. Neither of those seem better to me that simply putting the UART ID into the U-Boot config directly in the first place. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, Wolfgang, On 03/21/2012 08:38 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: > We have standard ways of telling the Linux kernel what the console > port is - the "console=" boot argument has been working fine for many, > many years and many, many boards and systems. But Tegra needs to > invent it's own hackinsh implementation of putting special data in > some special registers. What a crap. This made me look into the x86 code - There is a command line option 'earlyprintk' which is available stupidly early (even the real-mode code and de-compressor have access to it) So I do now wonder why Tegra needs to do anything differently Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon Glass, In message you wrote: > > > I agree - The board designer should specify a 'default' debug port which > > is used for all character output prior to the 'configured' console port > > being initialised. > > We can provide that, but if it is wrong for the board we are using, Then your board configuration is wrong and needs to be fixed. > We cannot select the UART via CONFIG - remember that all of these > boards have the same U-Boot binary. Please read that again :-) The > device tree is the only thing that distinguishes them. All of the > CONFIG options are identical for all boards. This is conceptually broken. If you cannot define a common UART port as debug console, and if there is no other way to find out what the console port should be (*), you must either use static board-specific configuration, or you must accept the fact that there is no console output in certain error situations. The longer I read about this the less I feel willing to accept warts in the code trying to handle this. This Tegra code is starting to annoy me. We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap. We have a pretty clean concept of dealing with console output for more a decade. Everybody uses it, without any significant problems. The Tegra comes and submits more and more obscure code to fix it's home-made problems. I don't want to have that. I got better things to do than reading these patches again and again. I don't even see that we are converging on some acceptable solution. To bring this to a constructive end: It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works). OK, there is still a chance that the environment settings are missing or incorrect _and_ the DT cannot be loaded, but the probability for such a double-fault is much, much smaller. Could this be an acceptable solution for you? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de [Braddock:] Mr. Churchill, you are drunk. [Churchill:] And you madam, are ugly. But I shall be sober tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Stephen Warren, In message <4f68f3d0.6030...@wwwdotorg.org> you wrote: > > For each board, there is a single fixed UART that should be used for Thanks for this statement. I agree 100%. > both pre-console panic and the "real" console later. This is fixed by > the single static board design. Here I disagree. The concept of "pre-console panic" as used here is broken. We should _always_ initialize this "single fixed UART" as debug console as early as possible. Period. If we have a "pre-console panic" then, we cannot do anything about it, because if "as early as possible" is not sufficient, then it cannot be helped - obviously we cannot initialize the UART before that. And any panic after that is just anormal thing that can be printed on the debug console port. No need for any special handling. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstän- de (Mausbewegung) und "ga" sagen (Mausklick) abzukommen, zugunsten eines mächtigeren und langwierig zu erlernenden Tools (Sprache). -- Achim Linder in de.comp.os.linux.misc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Tue, Mar 20, 2012 at 5:42 PM, Stephen Warren wrote: > On 03/20/2012 05:33 PM, Simon Glass wrote: > ... >> We cannot select the UART via CONFIG - remember that all of these >> boards have the same U-Boot binary. Please read that again :-) The >> device tree is the only thing that distinguishes them. All of the >> CONFIG options are identical for all boards. > > I don't agree that all the boards have the same U-Boot binary. At > present, there are about 6 Tegra boards in mainline U-Boot all with > different binaries. Er, I was referring to all the boards that use the same config, not all the boards in mainline U-Boot. However I agree that we currently have 6 boards, we could fairly easily change this into one board with a device tree selector. > > Even with DT, I don't see anything wrong with having the low-level init > code parameterized and built per board (e.g. debug UART), but all the > higher level devices initialized/configured from device tree (e.g. I2C, > MMC, USB). It doesn't achieve the design goal I mentioned, but yes this is possible. > > Even if the binary result from the boot process is identical, but we did > something like I proposed a few emails back to inject the correct UART > ID into an initially common binary, you still get left with different > binaries per board, in terms of what you're actually flashing onto the > board. > > (yes, I'd be interested in seeing the SPL code you mentioned) OK. Let me know if we are on the same page on this topic, and I will start a new thread... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stehpen, On Wed, Mar 21, 2012 at 12:18 PM, Simon Glass wrote: > Hi Graeme, > > On Tue, Mar 20, 2012 at 5:39 PM, Graeme Russ wrote: >> Hi Simon >> >> On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass wrote: >>> Hi Graeme, >>> >>> On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ wrote: Hi Simon, >> And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards. >>> >>> Nope. There is only one u-boot.bin for all boards that use this SOC. >> >> And this is what I simply don't grok - Why have a single board config for >> a range of boards that are obviously different? > > That's the design goal - a single U-Boot binary for all boards that > use a particular SOC. > >> >> I suppose I haven't dealt with device tree and I imagine that is what this >> is all about. But to me, device trees are a construct for a higher level >> of operation (the OS) not the boot loader (although I get that the boot >> loader can parse the device tree in order to pick up what devices are >> installed and need some kind of low-level initialisation) > > Actually a device tree describes the hardware, and therefore should in > principle be just as applicable to the boot loader. > >> >> I think at such a low level you really have to say 'hey, these boards are >> different and need a different configuration' unless you put something in >> hardware that allows U-Boot to pick up on the difference without needing >> to initialise _anything_ similar to what Stephen has done to pass the >> debug UART info to Linux via a scratch register > > Well we could do that, but the config is in some sense supposed to be > the device tree. We are only dealing here with a little case where > there is no device tree and want to output a message. Exactly - Your goal is to create a board configuration which has no concept of the true physical nature of the board and for that true nature to be provided in a configuration file. The configuration file may or may not be valid and if it isn't, you have no idea how to tell the user. Worse, if it is valid but something else happens which means it cannot be loaded then, again, you cannot tell the user what went wrong gracefully The idea of having a last resort backup plan to spit out a diagnostic message is good, but I think the implementation fallls short of the mark here (I'm actually talking about Simon's patch - this 'mark one port for Linux to use as a fall-back' is, IMHO, pretty neat) Quite honestly, all boards which use the same UART to output the panic message can have the same U-Boot binary. If two boards use differing ports for the panic message, then they really need to be using different U-Boot binaries unless you have a physical configuration (a jumper for example) which can be detected without any other initialisation Another option maybe is to read the serial port when 'panic' mode is entered - Cycle through all ports (changing BAUD rate if need be) and if you pick up a preset character, dump the panic message to that port - You could even use the hardware lines (like RI if available) as an additional check Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme, On Tue, Mar 20, 2012 at 5:39 PM, Graeme Russ wrote: > Hi Simon > > On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass wrote: >> Hi Graeme, >> >> On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ wrote: >>> Hi Simon, > >>> And we are talking about one board vendor taking a SoC and using UARTA >>> for the panic output and another board vendor deciding to use UARTB - But >>> surely these vendors will create a separate config file for their boards. >> >> Nope. There is only one u-boot.bin for all boards that use this SOC. > > And this is what I simply don't grok - Why have a single board config for > a range of boards that are obviously different? That's the design goal - a single U-Boot binary for all boards that use a particular SOC. > > I suppose I haven't dealt with device tree and I imagine that is what this > is all about. But to me, device trees are a construct for a higher level > of operation (the OS) not the boot loader (although I get that the boot > loader can parse the device tree in order to pick up what devices are > installed and need some kind of low-level initialisation) Actually a device tree describes the hardware, and therefore should in principle be just as applicable to the boot loader. > > I think at such a low level you really have to say 'hey, these boards are > different and need a different configuration' unless you put something in > hardware that allows U-Boot to pick up on the difference without needing > to initialise _anything_ similar to what Stephen has done to pass the > debug UART info to Linux via a scratch register Well we could do that, but the config is in some sense supposed to be the device tree. We are only dealing here with a little case where there is no device tree and want to output a message. Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/20/2012 05:33 PM, Simon Glass wrote: ... > We cannot select the UART via CONFIG - remember that all of these > boards have the same U-Boot binary. Please read that again :-) The > device tree is the only thing that distinguishes them. All of the > CONFIG options are identical for all boards. I don't agree that all the boards have the same U-Boot binary. At present, there are about 6 Tegra boards in mainline U-Boot all with different binaries. Even with DT, I don't see anything wrong with having the low-level init code parameterized and built per board (e.g. debug UART), but all the higher level devices initialized/configured from device tree (e.g. I2C, MMC, USB). Even if the binary result from the boot process is identical, but we did something like I proposed a few emails back to inject the correct UART ID into an initially common binary, you still get left with different binaries per board, in terms of what you're actually flashing onto the board. (yes, I'd be interested in seeing the SPL code you mentioned) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Simon On Wed, Mar 21, 2012 at 11:19 AM, Simon Glass wrote: > Hi Graeme, > > On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ wrote: >> Hi Simon, >> And we are talking about one board vendor taking a SoC and using UARTA >> for the panic output and another board vendor deciding to use UARTB - But >> surely these vendors will create a separate config file for their boards. > > Nope. There is only one u-boot.bin for all boards that use this SOC. And this is what I simply don't grok - Why have a single board config for a range of boards that are obviously different? I suppose I haven't dealt with device tree and I imagine that is what this is all about. But to me, device trees are a construct for a higher level of operation (the OS) not the boot loader (although I get that the boot loader can parse the device tree in order to pick up what devices are installed and need some kind of low-level initialisation) I think at such a low level you really have to say 'hey, these boards are different and need a different configuration' unless you put something in hardware that allows U-Boot to pick up on the difference without needing to initialise _anything_ similar to what Stephen has done to pass the debug UART info to Linux via a scratch register Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme, On Tue, Mar 20, 2012 at 5:17 PM, Graeme Russ wrote: > Hi Simon, > > On Wed, Mar 21, 2012 at 11:02 AM, Simon Glass wrote: >> Hi Graeme, >> >> On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ wrote: >>> Hi Simon, >>> >>> On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass wrote: > We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards. >>> >>> But I don't get it - In your Seaboard patch, you only use UARTD so in this >>> case we could CONFIG_ it? >> >> Yes, Stephen specifically asked for this so I changed it. See the >> other ongoing discussion on this. >> >>> >>> And it's sounding like for other scenarios you are going to resign >>> yourself to there not being a common UART so you will send the pre-console >>> (panic) message to multiple UARTs - something that should be avoided at >>> all costs... >> >> Of course - we cannot require the board to use a particular UART. The >> SOCs have various options and different people will make different >> decisions. Honestly, if we can't deal with UART selection in the >> device tree, we aren't going to solve the more difficult problems. > > But aren't we dealing in a case where the device tree is probably not > available anyway? Yes. > > And we are talking about one board vendor taking a SoC and using UARTA > for the panic output and another board vendor deciding to use UARTB - But > surely these vendors will create a separate config file for their boards. Nope. There is only one u-boot.bin for all boards that use this SOC. > >>> I know we are dealing with a corner case abnormal situation here, but >>> something does not smell right... Maybe I'm not understanding something >>> obvious yet... >> >> I'm not sure. I suspect it could be easily explained with an hour at >> the whiteboard, but it's hard by email. >> >> The requirement is to output a message that the user can see, and we >> have a selection of UARTs which *might* be the console UART. For now >> we don't know exactly which one it is (see my SPL config comment >> though which might eventually solve this). So we send output to >> several of them. To protect against any danger, we permit the board >> file to select which are permitted. > > Again, we are going back to per-board configurations - Why can't this > selection be CONFIG_'d? Surely we could define a bitmap of available UARTs > in a SoC header (and reserve space for board specific UARTs) which can > then be used in the board config. > > I'm not really seeing an example of where two boards use exactly the same > configuration file and yet one has 'UARTx' plumbed and the other does not > > Sorry, I'm not trying to be difficult, just poking all the corners to see > what squishes ;) The key point is that they all have the same CONFIG and there is only one u-boot.bin. Once you understand that, the problem will become clearer. Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Simon, On Wed, Mar 21, 2012 at 11:02 AM, Simon Glass wrote: > Hi Graeme, > > On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ wrote: >> Hi Simon, >> >> On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass wrote: >>> We cannot select the UART via CONFIG - remember that all of these >>> boards have the same U-Boot binary. Please read that again :-) The >>> device tree is the only thing that distinguishes them. All of the >>> CONFIG options are identical for all boards. >> >> But I don't get it - In your Seaboard patch, you only use UARTD so in this >> case we could CONFIG_ it? > > Yes, Stephen specifically asked for this so I changed it. See the > other ongoing discussion on this. > >> >> And it's sounding like for other scenarios you are going to resign >> yourself to there not being a common UART so you will send the pre-console >> (panic) message to multiple UARTs - something that should be avoided at >> all costs... > > Of course - we cannot require the board to use a particular UART. The > SOCs have various options and different people will make different > decisions. Honestly, if we can't deal with UART selection in the > device tree, we aren't going to solve the more difficult problems. But aren't we dealing in a case where the device tree is probably not available anyway? And we are talking about one board vendor taking a SoC and using UARTA for the panic output and another board vendor deciding to use UARTB - But surely these vendors will create a separate config file for their boards. >> I know we are dealing with a corner case abnormal situation here, but >> something does not smell right... Maybe I'm not understanding something >> obvious yet... > > I'm not sure. I suspect it could be easily explained with an hour at > the whiteboard, but it's hard by email. > > The requirement is to output a message that the user can see, and we > have a selection of UARTs which *might* be the console UART. For now > we don't know exactly which one it is (see my SPL config comment > though which might eventually solve this). So we send output to > several of them. To protect against any danger, we permit the board > file to select which are permitted. Again, we are going back to per-board configurations - Why can't this selection be CONFIG_'d? Surely we could define a bitmap of available UARTs in a SoC header (and reserve space for board specific UARTs) which can then be used in the board config. I'm not really seeing an example of where two boards use exactly the same configuration file and yet one has 'UARTx' plumbed and the other does not Sorry, I'm not trying to be difficult, just poking all the corners to see what squishes ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme, On Tue, Mar 20, 2012 at 4:52 PM, Graeme Russ wrote: > Hi Simon, > > On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass wrote: >> Hi Graeme, >> >> On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ wrote: >>> Hi Stephen, Simon, >>> >>> On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren >>> wrote: On 03/20/2012 02:13 PM, Simon Glass wrote: > Hi Stephen, > > On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren > wrote: >> This works together with a kernel change that looks at the scratchpad >> register to determine which of the many UARTs it should use for early >> printing: >> >> http://www.spinics.net/lists/arm-kernel/msg154633.html >> >> Note that this configuration only affects the kernel's decompressor and >> earlyprintk code. Once the kernel is initialized far enough to parse the >> device tree, the console is initialized using information contained >> therein. >> >> Base on work by Doug Anderson , but significantly >> rewritten. >> >> Signed-off-by: Stephen Warren >>> > For the pre-console panic stuff, the point is that there may well be > one UART used for the console, but *we don't know which one it is!*. That's where we disagree. For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design. >>> >>> I agree - The board designer should specify a 'default' debug port which >>> is used for all character output prior to the 'configured' console port >>> being initialised. >> >> We can provide that, but if it is wrong for the board we are using, >> then there will be no output. Stephen's original complaint was a brick >> if there is no valid device tree. We need this to work! >> >>> >>> In the 'normal' boot case, the default console should never have any output >>> sent to it (unless it also happens to be the 'configured' console port) as >>> Both U-Boot and Linux will use a pre console buffer to buffer any output >>> prior to the 'configured' console being available >>> >>> So I think there is a clear evidence that the 'Board panic no console' >>> and 'Specify debugging serial port at boot' are intrinsicly related - Both >>> U-Boot and Linux should be dumping their 'pre-console' messages to the >>> same port and this port should be specified by the hardware designer >>> >>> So that being the case, there should be a single CONFIG_ option which >>> both patches should be using >> >> We cannot select the UART via CONFIG - remember that all of these >> boards have the same U-Boot binary. Please read that again :-) The >> device tree is the only thing that distinguishes them. All of the >> CONFIG options are identical for all boards. > > But I don't get it - In your Seaboard patch, you only use UARTD so in this > case we could CONFIG_ it? Yes, Stephen specifically asked for this so I changed it. See the other ongoing discussion on this. > > And it's sounding like for other scenarios you are going to resign > yourself to there not being a common UART so you will send the pre-console > (panic) message to multiple UARTs - something that should be avoided at > all costs... Of course - we cannot require the board to use a particular UART. The SOCs have various options and different people will make different decisions. Honestly, if we can't deal with UART selection in the device tree, we aren't going to solve the more difficult problems. > > I know we are dealing with a corner case abnormal situation here, but > something does not smell right... Maybe I'm not understanding something > obvious yet... I'm not sure. I suspect it could be easily explained with an hour at the whiteboard, but it's hard by email. The requirement is to output a message that the user can see, and we have a selection of UARTs which *might* be the console UART. For now we don't know exactly which one it is (see my SPL config comment though which might eventually solve this). So we send output to several of them. To protect against any danger, we permit the board file to select which are permitted. Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Simon, On Wed, Mar 21, 2012 at 10:33 AM, Simon Glass wrote: > Hi Graeme, > > On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ wrote: >> Hi Stephen, Simon, >> >> On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren >> wrote: >>> On 03/20/2012 02:13 PM, Simon Glass wrote: Hi Stephen, On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren wrote: > This works together with a kernel change that looks at the scratchpad > register to determine which of the many UARTs it should use for early > printing: > > http://www.spinics.net/lists/arm-kernel/msg154633.html > > Note that this configuration only affects the kernel's decompressor and > earlyprintk code. Once the kernel is initialized far enough to parse the > device tree, the console is initialized using information contained > therein. > > Base on work by Doug Anderson , but significantly > rewritten. > > Signed-off-by: Stephen Warren >> >>> For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*. >>> >>> That's where we disagree. >>> >>> For each board, there is a single fixed UART that should be used for >>> both pre-console panic and the "real" console later. This is fixed by >>> the single static board design. >> >> I agree - The board designer should specify a 'default' debug port which >> is used for all character output prior to the 'configured' console port >> being initialised. > > We can provide that, but if it is wrong for the board we are using, > then there will be no output. Stephen's original complaint was a brick > if there is no valid device tree. We need this to work! > >> >> In the 'normal' boot case, the default console should never have any output >> sent to it (unless it also happens to be the 'configured' console port) as >> Both U-Boot and Linux will use a pre console buffer to buffer any output >> prior to the 'configured' console being available >> >> So I think there is a clear evidence that the 'Board panic no console' >> and 'Specify debugging serial port at boot' are intrinsicly related - Both >> U-Boot and Linux should be dumping their 'pre-console' messages to the >> same port and this port should be specified by the hardware designer >> >> So that being the case, there should be a single CONFIG_ option which >> both patches should be using > > We cannot select the UART via CONFIG - remember that all of these > boards have the same U-Boot binary. Please read that again :-) The > device tree is the only thing that distinguishes them. All of the > CONFIG options are identical for all boards. But I don't get it - In your Seaboard patch, you only use UARTD so in this case we could CONFIG_ it? And it's sounding like for other scenarios you are going to resign yourself to there not being a common UART so you will send the pre-console (panic) message to multiple UARTs - something that should be avoided at all costs... I know we are dealing with a corner case abnormal situation here, but something does not smell right... Maybe I'm not understanding something obvious yet... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme, On Tue, Mar 20, 2012 at 4:28 PM, Graeme Russ wrote: > Hi Stephen, Simon, > > On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren wrote: >> On 03/20/2012 02:13 PM, Simon Glass wrote: >>> Hi Stephen, >>> >>> On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren >>> wrote: This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing: http://www.spinics.net/lists/arm-kernel/msg154633.html Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein. Base on work by Doug Anderson , but significantly rewritten. Signed-off-by: Stephen Warren > >> >>> For the pre-console panic stuff, the point is that there may well be >>> one UART used for the console, but *we don't know which one it is!*. >> >> That's where we disagree. >> >> For each board, there is a single fixed UART that should be used for >> both pre-console panic and the "real" console later. This is fixed by >> the single static board design. > > I agree - The board designer should specify a 'default' debug port which > is used for all character output prior to the 'configured' console port > being initialised. We can provide that, but if it is wrong for the board we are using, then there will be no output. Stephen's original complaint was a brick if there is no valid device tree. We need this to work! > > In the 'normal' boot case, the default console should never have any output > sent to it (unless it also happens to be the 'configured' console port) as > Both U-Boot and Linux will use a pre console buffer to buffer any output > prior to the 'configured' console being available > > So I think there is a clear evidence that the 'Board panic no console' > and 'Specify debugging serial port at boot' are intrinsicly related - Both > U-Boot and Linux should be dumping their 'pre-console' messages to the > same port and this port should be specified by the hardware designer > > So that being the case, there should be a single CONFIG_ option which > both patches should be using We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards. If I had time right now I would send out a proper serial fdt patch series - the previous one was just a WIP. But you can see it here: https://gerrit.chromium.org/gerrit/#change,18257 > > Just my 2% of $1.00 ;) > > Regards, > > Graeme Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Tue, Mar 20, 2012 at 2:17 PM, Stephen Warren wrote: > On 03/20/2012 02:13 PM, Simon Glass wrote: >> Hi Stephen, >> >> On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren >> wrote: >>> This works together with a kernel change that looks at the scratchpad >>> register to determine which of the many UARTs it should use for early >>> printing: >>> >>> http://www.spinics.net/lists/arm-kernel/msg154633.html >>> >>> Note that this configuration only affects the kernel's decompressor and >>> earlyprintk code. Once the kernel is initialized far enough to parse the >>> device tree, the console is initialized using information contained >>> therein. >>> >>> Base on work by Doug Anderson , but significantly >>> rewritten. >>> >>> Signed-off-by: Stephen Warren >>> --- >>> Tom, this patch applies on top of u-boot-tegra/master, with the top 4 >>> commits removed and replaced with Simon's latest putc series from last >>> night. >>> >>> Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to >>> remove the uart_ids parameter and simply call get_uart_ids() internally? >> >> I can't help thinking there is a bit of a misunderstanding here. I >> suspected it from your comments yesterday, so let's try to clear it >> up. > > It's not so much a misunderstanding as a disagreement over the right > direction. OK > >> This patch is intended (I believe) to signal to Linux which UART is >> used for the earlyprintk console. This is so when U-Boot cannot >> decompress the kernel (because we are booting a zImage which has its >> own decompression wrapper) we can print the 'Uncompressing Linux...' >> message. Is that correct? > > That's one thing it affects, yes. > > It also affects the DEBUG_LL/earlyprintk output, i.e. all the kernel > spew (by the kernel itself, not the decompressor) that happens before > the real console device is set up. > > (When there's no problem and earlyprintk isn't on, this is all buffered > up and sent out the console when it appears, but if there's a panic > before the console is initialized, you won't see any messages. If > earlyprintk is enabled, the messages aren't buffered, but instead sent > immediately using the DEBUG_LL mechanism, and this patch is what tells > the DEBUG_LL mechanism which UART to use). Yes that's true also. > >> If so, what you want to find out here is exactly which UART is being >> used for the console. It will be a single UART, it will be know for >> sure, whether the information comes from CONFIG or the device tree. > > True, implementing it that way would also be useful. Right now, that's > driven by CONFIG_SYS_NS16550_COM*, but can come from DT too. OK > >> For the pre-console panic stuff, the point is that there may well be >> one UART used for the console, but *we don't know which one it is!*. > > That's where we disagree. > > For each board, there is a single fixed UART that should be used for > both pre-console panic and the "real" console later. This is fixed by > the single static board design. > > In other words: While other boards may be similar to Seaboard, they are > not Seaboard, and we shouldn't be using the Seaboard board file for > them. They are different boards that are simply similar in design. But > for example, many use a different UART for their debug console - a clear > difference in hardware. > > For each one of these derived boards, there is a single static UART that > should be used, as determined by the board design. > > Thus, I argue that there really is no concept of "which UART do we use" > *for a given board*. > > I think perhaps the way to clear this up is to make the existing > Seaboard and Ventana boards NOT be device-tree-driven, but rather be > "board-file" driven. Instead of co-opting Seaboard, introduce a new > "tegra2dt" board that is purely DT driven. (This is exactly what's been > done in the kernel). Then, it would make a lot more sense to talk about > there being multiple possible UARTs to use for the console, since the > board you build U-Boot for would then explicitly be for multiple boards, > rather than hijacking a particular single board file to work on multiple > boards. It'd also allow people to boot U-Boot on Seaboard without using > DT if they wanted, at the very least as a temporary transition mechanism. Know you of such people? But yes I am thinking beyond Seaboard and yes we do need a 'generic' tegra2 board instead of using Seaboard. I am not sure of the value of having separate boards at all though, since with a the device tree there should be nothing in the board files that is not generic. I suppose that is what has stopped me from actually implementing a generic tegra2 board so far - in my mind it is just Seaboard (or anything else if you prefer, since they are all the same in that all differences are captured by the device tree). But I agree we should do it. > > As an aside, for the tegra2dt board, perhaps we should have a single > well-known location in the U-Boot binary that contains
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, Simon, On Wed, Mar 21, 2012 at 8:17 AM, Stephen Warren wrote: > On 03/20/2012 02:13 PM, Simon Glass wrote: >> Hi Stephen, >> >> On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren >> wrote: >>> This works together with a kernel change that looks at the scratchpad >>> register to determine which of the many UARTs it should use for early >>> printing: >>> >>> http://www.spinics.net/lists/arm-kernel/msg154633.html >>> >>> Note that this configuration only affects the kernel's decompressor and >>> earlyprintk code. Once the kernel is initialized far enough to parse the >>> device tree, the console is initialized using information contained >>> therein. >>> >>> Base on work by Doug Anderson , but significantly >>> rewritten. >>> >>> Signed-off-by: Stephen Warren > >> For the pre-console panic stuff, the point is that there may well be >> one UART used for the console, but *we don't know which one it is!*. > > That's where we disagree. > > For each board, there is a single fixed UART that should be used for > both pre-console panic and the "real" console later. This is fixed by > the single static board design. I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised. In the 'normal' boot case, the default console should never have any output sent to it (unless it also happens to be the 'configured' console port) as Both U-Boot and Linux will use a pre console buffer to buffer any output prior to the 'configured' console being available So I think there is a clear evidence that the 'Board panic no console' and 'Specify debugging serial port at boot' are intrinsicly related - Both U-Boot and Linux should be dumping their 'pre-console' messages to the same port and this port should be specified by the hardware designer So that being the case, there should be a single CONFIG_ option which both patches should be using Just my 2% of $1.00 ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/20/2012 02:13 PM, Simon Glass wrote: > Hi Stephen, > > On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren > wrote: >> This works together with a kernel change that looks at the scratchpad >> register to determine which of the many UARTs it should use for early >> printing: >> >> http://www.spinics.net/lists/arm-kernel/msg154633.html >> >> Note that this configuration only affects the kernel's decompressor and >> earlyprintk code. Once the kernel is initialized far enough to parse the >> device tree, the console is initialized using information contained >> therein. >> >> Base on work by Doug Anderson , but significantly >> rewritten. >> >> Signed-off-by: Stephen Warren >> --- >> Tom, this patch applies on top of u-boot-tegra/master, with the top 4 >> commits removed and replaced with Simon's latest putc series from last >> night. >> >> Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to >> remove the uart_ids parameter and simply call get_uart_ids() internally? > > I can't help thinking there is a bit of a misunderstanding here. I > suspected it from your comments yesterday, so let's try to clear it > up. It's not so much a misunderstanding as a disagreement over the right direction. > This patch is intended (I believe) to signal to Linux which UART is > used for the earlyprintk console. This is so when U-Boot cannot > decompress the kernel (because we are booting a zImage which has its > own decompression wrapper) we can print the 'Uncompressing Linux...' > message. Is that correct? That's one thing it affects, yes. It also affects the DEBUG_LL/earlyprintk output, i.e. all the kernel spew (by the kernel itself, not the decompressor) that happens before the real console device is set up. (When there's no problem and earlyprintk isn't on, this is all buffered up and sent out the console when it appears, but if there's a panic before the console is initialized, you won't see any messages. If earlyprintk is enabled, the messages aren't buffered, but instead sent immediately using the DEBUG_LL mechanism, and this patch is what tells the DEBUG_LL mechanism which UART to use). > If so, what you want to find out here is exactly which UART is being > used for the console. It will be a single UART, it will be know for > sure, whether the information comes from CONFIG or the device tree. True, implementing it that way would also be useful. Right now, that's driven by CONFIG_SYS_NS16550_COM*, but can come from DT too. > For the pre-console panic stuff, the point is that there may well be > one UART used for the console, but *we don't know which one it is!*. That's where we disagree. For each board, there is a single fixed UART that should be used for both pre-console panic and the "real" console later. This is fixed by the single static board design. In other words: While other boards may be similar to Seaboard, they are not Seaboard, and we shouldn't be using the Seaboard board file for them. They are different boards that are simply similar in design. But for example, many use a different UART for their debug console - a clear difference in hardware. For each one of these derived boards, there is a single static UART that should be used, as determined by the board design. Thus, I argue that there really is no concept of "which UART do we use" *for a given board*. I think perhaps the way to clear this up is to make the existing Seaboard and Ventana boards NOT be device-tree-driven, but rather be "board-file" driven. Instead of co-opting Seaboard, introduce a new "tegra2dt" board that is purely DT driven. (This is exactly what's been done in the kernel). Then, it would make a lot more sense to talk about there being multiple possible UARTs to use for the console, since the board you build U-Boot for would then explicitly be for multiple boards, rather than hijacking a particular single board file to work on multiple boards. It'd also allow people to boot U-Boot on Seaboard without using DT if they wanted, at the very least as a temporary transition mechanism. As an aside, for the tegra2dt board, perhaps we should have a single well-known location in the U-Boot binary that contains the "uart_ids" value. This can be initialized to "all UARTs" by default by the code (or perhaps "no UARTs" for safety). As part of the manual post-processing to convert this common u-boot.bin binary to a particular board prior to flashing, one could both (a) append the .dtb file just like is required now (b) patch that well-known location to set the specific UARTs for the panic putc, if desired. "Well known" could perhaps be determined using "nm" and searching for a specific symbol. A helper script could be provided to make this easy. What do you think of this? > So the concept of selecting a particular UART and writing out a > message is not really good enough. Sure it works on Seaboard, and I > adjusted my patch to only use UARTD, but doesn't work on a Seaboard > variant where we don't yet have t
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Tue, Mar 20, 2012 at 12:57 PM, Stephen Warren wrote: > This works together with a kernel change that looks at the scratchpad > register to determine which of the many UARTs it should use for early > printing: > > http://www.spinics.net/lists/arm-kernel/msg154633.html > > Note that this configuration only affects the kernel's decompressor and > earlyprintk code. Once the kernel is initialized far enough to parse the > device tree, the console is initialized using information contained > therein. > > Base on work by Doug Anderson , but significantly > rewritten. > > Signed-off-by: Stephen Warren > --- > Tom, this patch applies on top of u-boot-tegra/master, with the top 4 > commits removed and replaced with Simon's latest putc series from last > night. > > Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to > remove the uart_ids parameter and simply call get_uart_ids() internally? I can't help thinking there is a bit of a misunderstanding here. I suspected it from your comments yesterday, so let's try to clear it up. This patch is intended (I believe) to signal to Linux which UART is used for the earlyprintk console. This is so when U-Boot cannot decompress the kernel (because we are booting a zImage which has its own decompression wrapper) we can print the 'Uncompressing Linux...' message. Is that correct? If so, what you want to find out here is exactly which UART is being used for the console. It will be a single UART, it will be know for sure, whether the information comes from CONFIG or the device tree. For the pre-console panic stuff, the point is that there may well be one UART used for the console, but *we don't know which one it is!*. So the concept of selecting a particular UART and writing out a message is not really good enough. Sure it works on Seaboard, and I adjusted my patch to only use UARTD, but doesn't work on a Seaboard variant where we don't yet have the device tree and so don't know which UART is used for the console. The device tree specifies the console UART - it cannot be known at compile time. The best we can do is specify the possible and legal options. Please don't get these two things (asking which is the console UART and asking which UARTs could possible be the console) confused - I realise that this is a bit mess. To be clear, the pre-console panic is NOT: 1. Intended to just print a message on the console - that would be easy if we actually knew which was the console; nor 2. Intended as a general-purpose pre-console message output interface - there is already Graeme's pre-console buffer for that. > > BTW, it seems inconsistent to have all the Tegra code key off > CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off > CONFIG_SYS_NS16550_COM*. Can the two be unified somehow? > > arch/arm/cpu/armv7/tegra2/board.c | 31 +-- > 1 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/cpu/armv7/tegra2/board.c > b/arch/arm/cpu/armv7/tegra2/board.c > index c7ea96b..27831f3 100644 > --- a/arch/arm/cpu/armv7/tegra2/board.c > +++ b/arch/arm/cpu/armv7/tegra2/board.c > @@ -115,7 +115,7 @@ void tegra_setup_uarts(int uart_ids) > } > } > > -void board_init_uart_f(void) > +static int get_uart_ids(void) > { > int uart_ids = 0; /* bit mask of which UART ids to enable */ > > @@ -128,7 +128,13 @@ void board_init_uart_f(void) > #ifdef CONFIG_TEGRA2_ENABLE_UARTD > uart_ids |= TEGRA_UARTD; > #endif > - tegra_setup_uarts(uart_ids); > + > + return uart_ids; > +} If you want this, then I suggest tegra_get_console_uart_id() might be a better, to avoid confusion. It can just return an enum. > + > +void board_init_uart_f(void) > +{ > + tegra_setup_uarts(get_uart_ids()); > } > > #ifndef CONFIG_SYS_DCACHE_OFF > @@ -150,6 +156,27 @@ static const u32 uart_reg_addr[TEGRA_UART_COUNT] = { > NV_PA_APB_UARTD_BASE, > }; > > +void arch_preboot_os(void) > +{ > + int uart_ids, i; > + > + /* > + * The Linux kernel earlyprintk code detects which UART to use by > + * searching for one with 'D' in the UART scratch register. This > + * is set up here. > + */ > + uart_ids = get_uart_ids(); > + > + for (i = 0; i < TEGRA_UART_COUNT; i++) { I feel there should only be a single UART here. After all, what is Linux supposed to do in early printk if it seems more than one UART? > + if (uart_ids & (1 << i)) { > + NS16550_t regs = (NS16550_t)uart_reg_addr[i]; > + if (!regs) > + continue; > + writeb('D', ®s->spr); > + } > + } > +} > + > void tegra_pre_console_panic(int uart_ids, unsigned clock_freq, > unsigned multiplier, const char *str) > { > -- > 1.7.0.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de
[U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
This works together with a kernel change that looks at the scratchpad register to determine which of the many UARTs it should use for early printing: http://www.spinics.net/lists/arm-kernel/msg154633.html Note that this configuration only affects the kernel's decompressor and earlyprintk code. Once the kernel is initialized far enough to parse the device tree, the console is initialized using information contained therein. Base on work by Doug Anderson , but significantly rewritten. Signed-off-by: Stephen Warren --- Tom, this patch applies on top of u-boot-tegra/master, with the top 4 commits removed and replaced with Simon's latest putc series from last night. Simon, I wonder if tegra_pre_console_panic() shouldn't be modified to remove the uart_ids parameter and simply call get_uart_ids() internally? BTW, it seems inconsistent to have all the Tegra code key off CONFIG_TEGRA2_ENABLE_UART*, whereas the serial driver keys off CONFIG_SYS_NS16550_COM*. Can the two be unified somehow? arch/arm/cpu/armv7/tegra2/board.c | 31 +-- 1 files changed, 29 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/tegra2/board.c b/arch/arm/cpu/armv7/tegra2/board.c index c7ea96b..27831f3 100644 --- a/arch/arm/cpu/armv7/tegra2/board.c +++ b/arch/arm/cpu/armv7/tegra2/board.c @@ -115,7 +115,7 @@ void tegra_setup_uarts(int uart_ids) } } -void board_init_uart_f(void) +static int get_uart_ids(void) { int uart_ids = 0; /* bit mask of which UART ids to enable */ @@ -128,7 +128,13 @@ void board_init_uart_f(void) #ifdef CONFIG_TEGRA2_ENABLE_UARTD uart_ids |= TEGRA_UARTD; #endif - tegra_setup_uarts(uart_ids); + + return uart_ids; +} + +void board_init_uart_f(void) +{ + tegra_setup_uarts(get_uart_ids()); } #ifndef CONFIG_SYS_DCACHE_OFF @@ -150,6 +156,27 @@ static const u32 uart_reg_addr[TEGRA_UART_COUNT] = { NV_PA_APB_UARTD_BASE, }; +void arch_preboot_os(void) +{ + int uart_ids, i; + + /* +* The Linux kernel earlyprintk code detects which UART to use by +* searching for one with 'D' in the UART scratch register. This +* is set up here. +*/ + uart_ids = get_uart_ids(); + + for (i = 0; i < TEGRA_UART_COUNT; i++) { + if (uart_ids & (1 << i)) { + NS16550_t regs = (NS16550_t)uart_reg_addr[i]; + if (!regs) + continue; + writeb('D', ®s->spr); + } + } +} + void tegra_pre_console_panic(int uart_ids, unsigned clock_freq, unsigned multiplier, const char *str) { -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot