Re: [U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration

[Bin Meng]

Hi Tim,

+Simon and U-Boot ML.

On Wed, Oct 7, 2015 at 12:22 AM, Timothy Scott <tescott...@gmail.com> wrote:
> Bin,
>
> I've seen your name associated with U-boot repo commits relating to the
> ns16550 and the UARTs that are sitting on the PCI bus for the Intel
> Baytrail.  I'm working on setting up a board based on the Intel E3815
> (Baytrail) and am having difficulty redirecting the console to hsuart0.
> Things work great for the legacy COM port @ address 0x3F8, but fail (ie.
> continuous U-Boot resets) when I try to change things to use hsuart0.  With
> the hsuart0 defined in the DTS, I'd expect "coninfo" to reflect the hsuart0
> device, but I do not see it.  "dm tree" shows the device present but that it
> is unprobed.
>
> Note that I'm working against U-Boot v2015.04.  I tried updating to v2015.07
> to see if that would help, but that ended up killing other devices that are
> working fine on v2015.04 so I'm trying to stick with that.
>

Can you please rebase your working tree based on commit

commit b21b208184721eed198bdf59204b452716986377
Author: Bin Meng <bmeng...@gmail.com>
Date:   Wed Dec 31 16:05:14 2014 +0800

x86: crownbay: Add pci devices in the dts file

This is the initial commit that was the first time to support PCI UART
and verified on Intel Crown Bay.

At some time later there was a change in the dev_get_addr() API that
broke the PCI UART codes but I can't remember when that regression was
introduced. This was later fixed by commit:

commit 236efe36be6d1c544f9477f10fdf38a17cd7a869
Author: Simon Glass <s...@chromium.org>
Date:   Sun Aug 2 18:13:50 2015 -0600

Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"

The symptom you observed (continuous U-Boot reset) is probably due to
this. As when U-Boot does not find a working serial console, it simply
resets.

> Here's my current DTS file.  I used the crownbay.dts configuration as a
> reference.  Not sure if you can see anything wrong with my config, but a
> second pair of eyes on it would help!
>
> /dts-v1/;
>
> /include/ "skeleton.dtsi"
> /include/ "serial.dtsi"
>
> / {
> model = "Yukon"; /* my board name */
> compatible = "intel,yukon", "intel,baytrail";
>
> aliases {
> serial0 = "/serial";
> serial1 = "/pci/serial@1e,3";
> };
>
> config {
> silent_console = <0>;
> };
>
> chosen {
> stdout-path = "/serial"; /* switching this to  results in
> continuous resets.  Configuration as-is works fine but uses the PCU uart on
> the baytrail part. */
> };
> pci {
> #address-cells = <3>;
>         #size-cells = <2>;
> compatible = "simple-bus"; /* I had to change this from intel,cpi to
> simple-bus in order for 'dm tree' to show this node and the hsuart0 node/ */
> device_type="pci";
>
> hsuart0: serial@1e,3 {
> compatible = "pci8086,0f0a","x86-uart";
> u-boot,dm-pre-reloc;
> reg = <0x0200F310 0x0 0x0 0x0 0x0>; /* memory-mapped, PCI 0/30/3
> device, config @ address 0x10 */
> reg-shift = <0>;
> clock-frequency = <1843200>;
> current-speed = <115200>;
> };
> };
> };
>
> Here is the output of "coninfo" with the above DTS definitions:
>
> => coninfo
> List of available devices:
> serial   0003 .IO stdin stdout stderr
> sserial  8003 SIO
> nulldev  8003 SIO
> nc   8003 SIO
> cbmem0002 ..O
>
> Here is the output of "dm tree" and "dm uclass" with the above DTS
> definition:
>
> => dm tree
>  Class   Probed   Name
> 
>  root[ + ]root_driver
>  serial  [ + ]|-- serial
>  simple_bus  [   ]`-- pci
>  serial  [   ]`-- serial@1e,3
> => dm uclass
> uclass 0: root
> - * root_driver @ 7aa12058
>
> Cannot find uclass for id 1: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> Cannot find uclass for id 2: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> Cannot find uclass for id 3: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> Cannot find uclass for id 4: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> Cannot find uclass for id 5: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> Cannot find uclass for id 6: please add the UCLASS_DRIVER() declaration for
> this UCLASS_... id
> uclass 7: simple_bus
> -   pci @ 7aa12158
>
> uclass 8: gpio
> uclass 9: serial
> - * serial @ 7aa120d0, 0
> -   serial@1e,3 @ 7aa121b0, 1
>
> Ca

Re: [U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration

[Bin Meng]

Hi Tim,

On Wed, Oct 7, 2015 at 11:26 PM, Timothy Scott  wrote:
> Bin,
>
> Thanks for the response.  I've got things working with v2015.04, but it took
> some tweaking.  Here's what I learned:
>
> 1) PCI is initialized AFTER the code was attempting to configure hsuart0.
> Since hsuart0 is on the PCI bus, the various registers being read were
> coming up 0x and therefore hsuart0 access was invalid.

Yes, in v2015.04, Intel Crown Bay codes did this by defining
CONFIG_SYS_EARLY_PCI_INIT and calling the PCI enumeration in
arch_cpu_init() manually. With DM conversion on the latest
u-boot/master branch, this is not needed as the enumeration will be
triggered as needed.

> 2) I'm swapping between PCU_UART (legac y) and SIO_UART at run-time, while
> using the ns16550 driver in both instances.  The code that underlies
> ns16550_writeb() and ns16550_readb() expects things to be configured at
> compile time via CONFIG options instead of something you can jack with at
> run-time.
>

This can be enhanced by converting the ns16550 CONFIG options to a
device tree bindings, however I don't know if there is any plan to do
this. My only concern of doing it via device tree is that some
performance degradation might be observed.

> My workarounds:
> - created hsuart_init() in serial-uclass.c, patterned off of
> serial_find_console_or_panic().  This references a unique chosen option I
> named "hsuart-path" and loads up hsuart device for me.  I do this to get the
> hsuart0 probed and loaded.  (If there's a better way to force a device
> probe, please let me know.)
> - created initr_hsuart_serial() in board_r.c, and invoked this via the
> init_sequence_r[] table, after initr_pci.
> - updated ns16550.c's ns16550_platdata with a "mem_map" parameter.  I added
> a "mem-map" parm to the hsuart DTS entry, and load this value in via
> ns16550_serial_ofdata_to_platdata.  This is then referenced in
> ns16550_writeb() and ns16550_readb() to perform a memory mapped access,
> instead of whatever the CONFIG options have defined.  In my case, CONFIG
> options result in a port mapped access.
>
> All this is pretty hackish but works for my purposes.
>
> Thanks again,
> --tim
>
>

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration

[Timothy Scott]

Bin,

Thanks for the response.  I've got things working with v2015.04, but it
took some tweaking.  Here's what I learned:

1) PCI is initialized AFTER the code was attempting to configure hsuart0.
Since hsuart0 is on the PCI bus, the various registers being read were
coming up 0x and therefore hsuart0 access was invalid.
2) I'm swapping between PCU_UART (legac y) and SIO_UART at run-time, while
using the ns16550 driver in both instances.  The code that underlies
ns16550_writeb() and ns16550_readb() expects things to be configured at
compile time via CONFIG options instead of something you can jack with at
run-time.

My workarounds:
- created hsuart_init() in serial-uclass.c, patterned off of
serial_find_console_or_panic().  This references a unique chosen option I
named "hsuart-path" and loads up hsuart device for me.  I do this to get
the hsuart0 probed and loaded.  (If there's a better way to force a device
probe, please let me know.)
- created initr_hsuart_serial() in board_r.c, and invoked this via the
init_sequence_r[] table, after initr_pci.
- updated ns16550.c's ns16550_platdata with a "mem_map" parameter.  I added
a "mem-map" parm to the hsuart DTS entry, and load this value in via
ns16550_serial_ofdata_to_platdata.  This is then referenced in
ns16550_writeb() and ns16550_readb() to perform a memory mapped access,
instead of whatever the CONFIG options have defined.  In my case, CONFIG
options result in a port mapped access.

All this is pretty hackish but works for my purposes.

Thanks again,
--tim


On Wed, Oct 7, 2015 at 3:10 AM, Bin Meng <bmeng...@gmail.com> wrote:

> Hi Tim,
>
> +Simon and U-Boot ML.
>
> On Wed, Oct 7, 2015 at 12:22 AM, Timothy Scott <tescott...@gmail.com>
> wrote:
> > Bin,
> >
> > I've seen your name associated with U-boot repo commits relating to the
> > ns16550 and the UARTs that are sitting on the PCI bus for the Intel
> > Baytrail.  I'm working on setting up a board based on the Intel E3815
> > (Baytrail) and am having difficulty redirecting the console to hsuart0.
> > Things work great for the legacy COM port @ address 0x3F8, but fail (ie.
> > continuous U-Boot resets) when I try to change things to use hsuart0.
> With
> > the hsuart0 defined in the DTS, I'd expect "coninfo" to reflect the
> hsuart0
> > device, but I do not see it.  "dm tree" shows the device present but
> that it
> > is unprobed.
> >
> > Note that I'm working against U-Boot v2015.04.  I tried updating to
> v2015.07
> > to see if that would help, but that ended up killing other devices that
> are
> > working fine on v2015.04 so I'm trying to stick with that.
> >
>
> Can you please rebase your working tree based on commit
>
> commit b21b208184721eed198bdf59204b452716986377
> Author: Bin Meng <bmeng...@gmail.com>
> Date:   Wed Dec 31 16:05:14 2014 +0800
>
> x86: crownbay: Add pci devices in the dts file
>
> This is the initial commit that was the first time to support PCI UART
> and verified on Intel Crown Bay.
>
> At some time later there was a change in the dev_get_addr() API that
> broke the PCI UART codes but I can't remember when that regression was
> introduced. This was later fixed by commit:
>
> commit 236efe36be6d1c544f9477f10fdf38a17cd7a869
> Author: Simon Glass <s...@chromium.org>
> Date:   Sun Aug 2 18:13:50 2015 -0600
>
> Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"
>
> The symptom you observed (continuous U-Boot reset) is probably due to
> this. As when U-Boot does not find a working serial console, it simply
> resets.
>
> > Here's my current DTS file.  I used the crownbay.dts configuration as a
> > reference.  Not sure if you can see anything wrong with my config, but a
> > second pair of eyes on it would help!
> >
> > /dts-v1/;
> >
> > /include/ "skeleton.dtsi"
> > /include/ "serial.dtsi"
> >
> > / {
> > model = "Yukon"; /* my board name */
> > compatible = "intel,yukon", "intel,baytrail";
> >
> > aliases {
> > serial0 = "/serial";
> > serial1 = "/pci/serial@1e,3";
> > };
> >
> > config {
> > silent_console = <0>;
> > };
> >
> > chosen {
> > stdout-path = "/serial"; /* switching this to  results in
> > continuous resets.  Configuration as-is works fine but uses the PCU uart
> on
> > the baytrail part. */
> > };
> > pci {
> > #address-cells = <3>;
> > #size-cells = <2>;
> > compatible = "simple-bus"; /* I had to change this from intel,cpi to
> > simple-bus in order 

Re: [U-Boot] U-boot qemu-x86 :load acpi tables from fw_cfg.

[Paolo Bonzini]

On 22/05/2015 18:54, Saket Sinha wrote:
 Hi Simon,
 

 Is it possible for us to add support to qemu to provide acpi tables
 via fw_cfg in u-boot ?

 If we find acpi tables in fw_cfg try loading them, otherwise fallback
 to the builtin acpi tables.

 Coreboot does it in the following way -
 http://review.coreboot.org/#/c/4040/

 It seems like it might be useful to implement this in U-Boot. Perhaps
 look at this after you have the built-in support running?

 
 I guess it would be extremely useful for u-boot.
 
 It is being used by q-boot, a new minimal x86 firmware for QEMU.
 http://lwn.net/Articles/645455/
 https://github.com/bonzini/qboot
 
 q-boot is able to give a minimal booting time, with the help of
 fw_cfg, by reading both the kernel and initrd image
 from fw_cfg.
 I guess ACPI support for both q-boot and qemu-x86 in u-boot can be
 implemented on similar lines.

ACPI support is now included in qboot.

Paolo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot qemu-x86 :load acpi tables from fw_cfg.

[Saket Sinha]

Hi Simon,


 Is it possible for us to add support to qemu to provide acpi tables
 via fw_cfg in u-boot ?

 If we find acpi tables in fw_cfg try loading them, otherwise fallback
 to the builtin acpi tables.

 Coreboot does it in the following way -
 http://review.coreboot.org/#/c/4040/

 It seems like it might be useful to implement this in U-Boot. Perhaps
 look at this after you have the built-in support running?


I guess it would be extremely useful for u-boot.

It is being used by q-boot, a new minimal x86 firmware for QEMU.
http://lwn.net/Articles/645455/
https://github.com/bonzini/qboot

q-boot is able to give a minimal booting time, with the help of
fw_cfg, by reading both the kernel and initrd image
from fw_cfg.
I guess ACPI support for both q-boot and qemu-x86 in u-boot can be
implemented on similar lines.


Regards,
Saket Sinha
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot qemu-x86 :load acpi tables from fw_cfg.

[Simon Glass]

Hi Saket,

On 22 May 2015 at 10:54, Saket Sinha saket.sinh...@gmail.com wrote:
 Hi Simon,


 Is it possible for us to add support to qemu to provide acpi tables
 via fw_cfg in u-boot ?

 If we find acpi tables in fw_cfg try loading them, otherwise fallback
 to the builtin acpi tables.

 Coreboot does it in the following way -
 http://review.coreboot.org/#/c/4040/

 It seems like it might be useful to implement this in U-Boot. Perhaps
 look at this after you have the built-in support running?


 I guess it would be extremely useful for u-boot.

 It is being used by q-boot, a new minimal x86 firmware for QEMU.
 http://lwn.net/Articles/645455/
 https://github.com/bonzini/qboot

 q-boot is able to give a minimal booting time, with the help of
 fw_cfg, by reading both the kernel and initrd image
 from fw_cfg.
 I guess ACPI support for both q-boot and qemu-x86 in u-boot can be
 implemented on similar lines.

Sounds good!

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot][coreboot-x86] Incremental Make fails

[Masahiro Yamada]

Hi Hua,


On Thu, 10 Apr 2014 16:32:32 +0800
Hua Yanghao huayang...@gmail.com wrote:

 Hi Masahiro,
 
 
  Strange.
  make coreboot-x86 is not supported anymore.
 
  Now, we must do make coreboot-x86_config all instead.
 We are still using U-boot 2014.01, which seems to be the latest stable
 release, isn't it?
 
 
  3. make # second make fails with message:
  make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib'
  make[1]: *** No rule to make target `.depend', needed by `built-in.o'.  
  Stop.
  make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib'
 
  Strange again.
 
  .depend files are not used any more.
  (They were used in the old build system prior to Kbuild.)
 Are you sure? I can see the .depend files is created all over the
 places. For both ARM  x86.
 
  Can anyone give some hints in how to solve this issue?
 
  Which version are you using?
 
 U-boot 2014.01
 
  I guess you are not using the latest version in the git repository.
 
  The most recommended solution is to use the latest version.
 
 Indeed the latest version have things fixed. :-) Will switch over.

Fetch the source tree by git clone:

git clone git://git.denx.de/u-boot.git


A big change happened to the U-Boot build system at v2014-rc1, 
which is right after v2014.01.

Unlike Linux Kernel, the stable releases are not maintained in U-Boot.
v2014.01 is just a snapshot of the mainline of develepment 3 months ago.

If you want to get a support from the community,
I recommend you to use u-boot/master branch.


Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [u-boot][coreboot-x86] Incremental Make fails

[Hua Yanghao]

Hi,
When doing make for coreboot-x86, in arch/x86/lib/Makefile it
re-generates libgcc.a from the original toolchain libgcc.a and did
some patching for certain libgcc functions. And this seems having some
issues when you try to do incremental compilation.

Steps to reproduce the issue:
1. Setup toolchain
2. make coreboot-x86 # sucess for the first time
3. make # second make fails with message:
make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib'
make[1]: *** No rule to make target `.depend', needed by `built-in.o'.  Stop.
make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib'

Can anyone give some hints in how to solve this issue?

Regards,
Yanghao
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot][coreboot-x86] Incremental Make fails

[Masahiro Yamada]

Hi Hua,

As far as I tested, the problem you mentioned
did not happen.


On Thu, 10 Apr 2014 14:59:33 +0800
Hua Yanghao huayang...@gmail.com wrote:

 Hi,
 When doing make for coreboot-x86, in arch/x86/lib/Makefile it
 re-generates libgcc.a from the original toolchain libgcc.a and did
 some patching for certain libgcc functions. And this seems having some
 issues when you try to do incremental compilation.
 
 Steps to reproduce the issue:
 1. Setup toolchain
 2. make coreboot-x86 # sucess for the first time

Strange.
make coreboot-x86 is not supported anymore.

Now, we must do make coreboot-x86_config all instead.


 3. make # second make fails with message:
 make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib'
 make[1]: *** No rule to make target `.depend', needed by `built-in.o'.  Stop.
 make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib'

Strange again.

.depend files are not used any more.
(They were used in the old build system prior to Kbuild.)


 Can anyone give some hints in how to solve this issue?

Which version are you using?

I guess you are not using the latest version in the git repository.

The most recommended solution is to use the latest version.


Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot][coreboot-x86] Incremental Make fails

[Hua Yanghao]

Hi Masahiro,


 Strange.
 make coreboot-x86 is not supported anymore.

 Now, we must do make coreboot-x86_config all instead.
We are still using U-boot 2014.01, which seems to be the latest stable
release, isn't it?


 3. make # second make fails with message:
 make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib'
 make[1]: *** No rule to make target `.depend', needed by `built-in.o'.  Stop.
 make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib'

 Strange again.

 .depend files are not used any more.
 (They were used in the old build system prior to Kbuild.)
Are you sure? I can see the .depend files is created all over the
places. For both ARM  x86.

 Can anyone give some hints in how to solve this issue?

 Which version are you using?

U-boot 2014.01

 I guess you are not using the latest version in the git repository.

 The most recommended solution is to use the latest version.

Indeed the latest version have things fixed. :-) Will switch over.


 Best Regards
 Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot for x86

[Graeme Russ]

Hi Raleigh,

Please keep the ML Cc'd (and please don't top-post)

On Thu, Jun 23, 2011 at 8:58 AM, Raleigh Boulware
r_boulw...@hotmail.com wrote:
 Thanks I will be looking for an eNET board. I am doing several Pentium
 U-boot projects.

An eNET board may be difficult to come by - They are a Remote Telemetry
Unit (RTU) developed by Serck Controls in Australia but now manufactured
by Control Microsystems in Canada (both companies are now subsiduaries of
Schneider Electric). They are used to monitor and control water pumping
stations, bore fields, reservoirs etc. They are not very usefull as a
U-Boot development platform - The only reason I have one is that I work
for Serck Controls and managed to convince someone to give me one that had
been sent back for repairs but was deemed 'not fit for service'.

You could always buy one from Control Microsystems, but be warned, they
are not exactly cheap ;)

As I said before, I am willing to help you get your Pentium projects
running.

 Hey so the 'make all' command makes the tool chain and the U-boot code
 itself. How do I just complie the U-boot source code now that I have the
 tool chain.

I think you might mean that it makes 'tools' and 'u-boot.bin' - 'tools'
is not a toolchain - They are a set of executables that can be used in
Linux to access the U-Boot environment etc. If you just want to build the
binary, 'make u-boot.bin' may be what you need (someone will correct me
if I'm wrong)

Regards,

Graeme


 Date: Wed, 22 Jun 2011 12:56:25 +1000
 Subject: Re: u-boot for x86
 From: graeme.r...@gmail.com
 To: r_boulw...@hotmail.com
 CC: u-boot@lists.denx.de

 Hi Raleigh,

 On Wed, Jun 22, 2011 at 12:44 PM, Raleigh Boulware
 r_boulw...@hotmail.com wrote:
  I am looking at the source code for the sc520 and can not figure out
  which
  board directory to look in. Which of the board plat form has the sc520?

 The only board which currently builds for the sc520 is the eNET board

  Also How do I configure for the sc520 board? How do I do a build for the
  sc520?

 1) Get the latest source using git
 2) make eNET_config
 3) make all

 I doubt that will be much help though, as you will need an eNET board to
 run it on :)

 If you have another x86 based board you want to get U-Boot running on, I
 am more than willing to help with advice and the odd bit of code

 Regards,

 Graeme

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot for x86

[Graeme Russ]

Hi Raleigh,

On Wed, Jun 22, 2011 at 12:44 PM, Raleigh Boulware
r_boulw...@hotmail.com wrote:
 I am looking at the source code for the sc520 and can not figure out which
 board directory to look in. Which of the board plat form has the sc520?

The only board which currently builds for the sc520 is the eNET board

 Also How do I configure for the sc520 board? How do I do a build for the
 sc520?

1) Get the latest source using git
2) make eNET_config
3) make all

I doubt that will be much help though, as you will need an eNET board to
run it on :)

If you have another x86 based board you want to get U-Boot running on, I
am more than willing to help with advice and the odd bit of code

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot on x86 reloaded

[Graeme Russ]

Hi Rodulf,

On 04/05/11 22:37, Rudolf Marek wrote:
 Hello all,
 

[snip]

   - The build warnings and errors you incurred are probably fixed in
 mainline (x86 is a bit of a forgotten cousin which gets broken when global
 patches are made to Makefile, linker scripts etc). If you still have
 problems compiling the latest U-Boot git head, please post them to the
 mailing list and I'll sort them out ASAP
 
 The links to the coreboot mailing list contain some patches.
 

Ok - I see two fixes needed (one in bios_setup.c and one in realmode.c).
These are both effectively in my realmode re-write, but if you can send
through a patch to fix them in the meantime, that would be great

   - When launching U-Boot as a payload from Coreboot, you really don't need
 to worry about what is at the end of the image (reset vector and jump to
 protected mode). All the fun begins at the first byte of u-boot.bin which
 is the first line of code in start.S
 
 I think it jumps to _start which is 32 bit entry point. The coreboot is in
 flat mode 32bit.
 

If you look at start.S, you will see a tiny bit of code before _start which
is the 'warm boot' entry point:

cli
cld

/* Turn of cache (this might require a 486-class CPU) */
movl%cr0, %eax
orl $(X86_CR0_NW | X86_CR0_CD), %eax
movl%eax, %cr0
wbinvd

/* Tell 32-bit code it is being entered from an in-RAM copy */
movw$GD_FLG_WARM_BOOT, %bx

Looking at coreboot in src/arch/x86/lib/c_start.S it appears coreboot and
U-Boot use the same GDT for code (0x10) and data (0x18) in a flat protected
mode configuration. We can probably make that a little more robust by
jumping over the segment register loads during warm-boot and just use
whatever coreboot gives us. U-Boot will wipe it all clean later anyway (see
arch/x86/cpu/x86_cpu_init_r) - x86_cpu_init_r calls reload_gdt() after
U-Boot has been relocated.

So if you build u-boot.bin with TEXT_BASE set wherever it will end up in
the coreboot image then you can just have coreboot jump to TEXT_BASE.

Now as for booting an ELF image, maybe the linker script needs to be
tweaked to set the entry point to _x86boot_start rather than _start

   - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used
 during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the
 CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already
 initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that
 will not get clobbered by the relocation
 
 Yes I set it to 256KB boundary.

Sounds reasonable - but you really need to set it to somewhere you know
there is physical RAM. Maybe this could be passed in a register in the warm
boot scenario and the address determined by coreboot

[big snip - we'll deal with real-mode / BIOS later]

 I would really like to see some U-Boot patches on the mailing list -
 Technically U-Boot is meant to be a stand-alone and self-sufficient, but I
 think for x86 there is merit in creating board configuration that gets
 boot-strapped by Coreboot (we just need to make sure the documentation is
 up-to-scratch)
 
 The patches are just now on coreboot mailing list. It is just a hack,
 because there are places which needs to be fixed, the computation of place
 for the realmode and bios sections needs to be fixed.  I added the coreboot
 as a board and subarchitecture.

I've had a chance to look at them, and the impact on U-Boot is surprisingly
minimal. A few comments:

-PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror
+PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386

NACK - Do not remove -Werror

-LDPPFLAGS += -DRESET_SEG_START=0x
+LDPPFLAGS += -DRESET_SEG_START=0xFF

NACK - As mentioned above, I see no reason to mess with this. Set TEXT_BASE
to be the location of U-Boot in the coreboot flash image and simply jump to it.

In /arch/x86/cpu/interrupts.c you add setup_i8259() and call it in
cpu_init_interrupts() which is called from cpu_init_r() - This is the wrong
place to be setting up the PIC (this file initialises the CPU interrupt
sub-system, not the external glue logic). And how is setup_i8259()
different from interrupt_init() found in arch/x86/lib/pcat_interrupt.c?

Now the problem could be that interrupt_init() is called after cpu_init_r()
- i.e. the CPU interrupt sub-system is setup before the PIC has been
configured. Maybe the PIC should be configured prior to relocation (and
therefore prior to initialisation of the CPU interrupt sub-system). Lets
look at moving that to board_early_init_f()

Apart from that, the patches look 'promising' ;)

Now, for me to officially consider them, they need to be posted to the
U-Boot mailing list using git format-patch / git send-email AFTER they have
been run through checkpatch (which can be found in the Linux source under
scripts/). You patches will end up in patchwork where they will be managed

 
 What is specific is that we will need 

[U-Boot] u-boot on x86 reloaded

[Rudolf Marek]

Hello,

I was asked to post it here too.

I would like to announce that I was able to boot Linux using u-boot on AMD64 
motherboard Asrock 939A785G. The development was done on QEMU.

How does it work?

Coreboot does the complete HW init including memory setup PCI etc. When 
finishes 
it loads u-boot.

Coreboot is free software replacement for BIOS, but unlike BIOS it only does 
the 
hardware init (and ACPI). A payload needs to be executed which does something 
useful for the user (like a linux kernel, SeaBIOS, FILO, grub etc)

You can read more about coreboot on http://coreboot.org

How the porting was done is described here:

http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/

http://www.coreboot.org/pipermail/coreboot/2011-April/064877.html
http://www.coreboot.org/pipermail/coreboot/2011-May/064914.html
http://www.coreboot.org/pipermail/coreboot/2011-May/064915.html

And boot log http://assembler.cz/minicom42.txt

This project started just for fun or because I can. Maybe there are some 
real uses. If you can think of some, please let me know.

Anyone with more free time could work on this?

I'm not subscribed, please cc me. I'm ccing coreboot mailing list too.

Thanks,
Rudolf

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot on x86 reloaded

[Graeme Russ]

On 04/05/11 18:54, Rudolf Marek wrote:
 Hello,
 
 I was asked to post it here too.
 
 I would like to announce that I was able to boot Linux using u-boot on AMD64 
 motherboard Asrock 939A785G. The development was done on QEMU.

Excellent - U-Boot on a new x86 board

 
 How does it work?
 
 Coreboot does the complete HW init including memory setup PCI etc. When 
 finishes 
 it loads u-boot.

This is one of the ways I was thinking of getting U-Boot running on
mainstream PC boards. The other is to create U-Boot as a GRUB payload.
Either way, it's all about getting the SDRAM initialised

[Snip]

 How the porting was done is described here:
 
 http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/

Excellent write-up - Thanks!

 
 http://www.coreboot.org/pipermail/coreboot/2011-April/064877.html
 http://www.coreboot.org/pipermail/coreboot/2011-May/064914.html
 http://www.coreboot.org/pipermail/coreboot/2011-May/064915.html
 
 And boot log http://assembler.cz/minicom42.txt
 
 This project started just for fun or because I can. Maybe there are some 
 real uses. If you can think of some, please let me know.

Well, that's why I started too - kudos for the effort

 
 Anyone with more free time could work on this?

Well I did have someone else contact me about doing exactly as you have
done (I have Bcc'd him in case he is interested)

As the U-Boot x86 maintainer, I am extremely interested in going further
with this and am keen to help get your work mainlined

 
 I'm not subscribed, please cc me. I'm ccing coreboot mailing list too.
 

OK, a few little points which may help answer some questions you didn't
realise you even had ;)

 - The build warnings and errors you incurred are probably fixed in
mainline (x86 is a bit of a forgotten cousin which gets broken when global
patches are made to Makefile, linker scripts etc). If you still have
problems compiling the latest U-Boot git head, please post them to the
mailing list and I'll sort them out ASAP
 - The x86 port of U-Boot was the first to implement the (now pretty much
standard) relocation scheme. Understanding it is a Very Good Idea(tm)
 - SYS_TEXT_BASE=0×1900 is very specific to the eNET - It is the start
of non-volatile (battery backed) SRAM. We can run from SRAM prior to
initialising SDRAM, so I use it as an alternative to Flash for testing new
builds (reset - TFTP new image to 0x1900 - go 1900)
 - When launching U-Boot as a payload from Coreboot, you really don't need
to worry about what is at the end of the image (reset vector and jump to
protected mode). All the fun begins at the first byte of u-boot.bin which
is the first line of code in start.S
 - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used
during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the
CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already
initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that
will not get clobbered by the relocation
 - I'm in the middle of re-writing the entire real-mode switch code and
real-mode support in U-Boot. The new code allows you to write real-mode
code in C - I even have the Linux real-mode printf ported :) This will make
writing your own 'BIOS' code for your board a lot easier
 - Ultimately, I would like to bypass Linux's real-mode stub (like GRUB)
and ditch the real-mode code (for the purpose of booting Linux)

I would really like to see some U-Boot patches on the mailing list -
Technically U-Boot is meant to be a stand-alone and self-sufficient, but I
think for x86 there is merit in creating board configuration that gets
boot-strapped by Coreboot (we just need to make sure the documentation is
up-to-scratch)

Looking forward to moving this forward

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot on x86 reloaded

[Rudolf Marek]

Hello all,

 Excellent - U-Boot on a new x86 board

Yes and in general any supported coreboot board.

 This is one of the ways I was thinking of getting U-Boot running on
 mainstream PC boards. The other is to create U-Boot as a GRUB payload.
 Either way, it's all about getting the SDRAM initialised

Not only, also HyperTransport, complex PCI stuff, power mngmt etc, lots of lots 
of stuff.

 Well, that's why I started too - kudos for the effort

Thanks.

 Anyone with more free time could work on this?

 Well I did have someone else contact me about doing exactly as you have
 done (I have Bcc'd him in case he is interested)

 As the U-Boot x86 maintainer, I am extremely interested in going further
 with this and am keen to help get your work mainlined

Ok

 OK, a few little points which may help answer some questions you didn't
 realise you even had ;)

   - The build warnings and errors you incurred are probably fixed in
 mainline (x86 is a bit of a forgotten cousin which gets broken when global
 patches are made to Makefile, linker scripts etc). If you still have
 problems compiling the latest U-Boot git head, please post them to the
 mailing list and I'll sort them out ASAP

The links to the coreboot mailing list contain some patches.

   - The x86 port of U-Boot was the first to implement the (now pretty much
 standard) relocation scheme. Understanding it is a Very Good Idea(tm)
   - SYS_TEXT_BASE=0×1900 is very specific to the eNET - It is the start
 of non-volatile (battery backed) SRAM. We can run from SRAM prior to
 initialising SDRAM, so I use it as an alternative to Flash for testing new
 builds (reset -  TFTP new image to 0x1900 -  go 1900)

Yes I move that to 16MB boundary to load it just into RAM. u-boot ELF can be 
loaded from coreboot, where it is stored compressed.

   - When launching U-Boot as a payload from Coreboot, you really don't need
 to worry about what is at the end of the image (reset vector and jump to
 protected mode). All the fun begins at the first byte of u-boot.bin which
 is the first line of code in start.S

I think it jumps to _start which is 32 bit entry point. The coreboot is in flat 
mode 32bit.

   - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used
 during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the
 CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already
 initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that
 will not get clobbered by the relocation

Yes I set it to 256KB boundary.

   - I'm in the middle of re-writing the entire real-mode switch code and
 real-mode support in U-Boot. The new code allows you to write real-mode
 code in C - I even have the Linux real-mode printf ported :) This will make
 writing your own 'BIOS' code for your board a lot easier

Well I liked here that there is no BIOS at all. The SeaBIOS is the layer used 
by 
coreboot to have full legacy BIOS stuff. This is used by KVM/Qenu too.

The coreboot can do VGA init (it has kind of BIOS emulation stuff for this) so 
at the end VGA + keyboard could be possible.

I guess if u-boot is for linux loading, then we need to add e820 stuff to have 
support for over 4GB of memory.

   - Ultimately, I would like to bypass Linux's real-mode stub (like GRUB)
 and ditch the real-mode code (for the purpose of booting Linux)

This is done in FILO. Check http://www.coreboot.org/FILO I guess it can be just 
ported. The coreboot will provide the memory map and this is how the FILO is 
doing that, just  transforming it and passing it directly to kernel.

 I would really like to see some U-Boot patches on the mailing list -
 Technically U-Boot is meant to be a stand-alone and self-sufficient, but I
 think for x86 there is merit in creating board configuration that gets
 boot-strapped by Coreboot (we just need to make sure the documentation is
 up-to-scratch)

The patches are just now on coreboot mailing list. It is just a hack, because 
there are places which needs to be fixed, the computation of place for the 
realmode and bios sections needs to be fixed.  I added the coreboot as a board 
and subarchitecture.

What is specific is that we will need to copy MPtable PIR and RSDP 
pointer 
to F-segment just after the bios section. The memory map can be read out of 
coreboot tables stored in high mem. Also a PCI mem stuff should be fixed in 
u-boot.

Also if we get rid of the .bios and .realmode section then the problem that 
those two sections are not relocated to end of memory disappears.

 Looking forward to moving this forward

Good. Please check the patches on coreboot ml and feel free to join #coreboot 
channel. I'm in both now as ruik.

Thanks,
Rudolf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot for x86 Core2Duo target

[Andy Pont]

Zvi wrote...

 On my next project, the target is Core2Duo (AMPRO's COM840).
 
 Is it a wise decision to use u-boot on this target ?

Probably not!  

Ampro will already have invested a lot of time and effort in porting the
BIOS to that board and are giving you a device that works out of the box.
If there is a specific issue that you have with their board then talk to
Ampro and they may look into it for you.

 Is it a huge project to port it to another x86 target that has a different
 ethernet controller ?

In the first instance it will rely on you being able to get all of the
information that you need in order to initialise all of the respective
hardware and some of the x86 CPU and chipset vendors limit who they make it
available to.

There are other questions you will need to ask, for instance.  Are you using
the VGA display?  If so, will your operating system device driver work
without the video BIOS having done the initialisation or some of the other
services provided by it?

 The u-boot image is loader by the BIOS from compact flash via SATA.

As Graeme Russ said, U-Boot would replace the BIOS.  I haven't looked at the
board but I would assume the BIOS can be in-situ updated.  In the first
instance you could try the flash update utility that goes along with the
BIOS to see if it will reprogram it with an arbitrary binary.  It may not do
as it may have a write protected boot block that you can't replace.

Andy.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot for x86 Core2Duo target

[Zvi Vered]

Hello,

I'm using u-boot on PPC405 (ML405) for about 3 years.

It is a great boot loader !

On my next project, the target is Core2Duo (AMPRO's COM840).

Is it a wise decision to use u-boot on this target ?
I prefare u-boot over grub or vxworks bootloader because it has many 
features.

If I understand correctly, sc520 is the only x86 target supported.

Is it a huge project to port it to another x86 target that has a different 
ethernet controller ?

The u-boot image is loader by the BIOS from compact flash via SATA.

What is the procedure for writing u-boot image on this flash ?

Thanks. 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot for x86 Core2Duo target

[Graeme Russ]

On 19/02/11 11:04, Zvi Vered wrote:
 Hello,
 
 I'm using u-boot on PPC405 (ML405) for about 3 years.
 
 It is a great boot loader !
 
 On my next project, the target is Core2Duo (AMPRO's COM840).
 
 Is it a wise decision to use u-boot on this target ?

I've had a quick look at the board on the Ampro website and it looks like
the type of design well suited to U-Boot

 I prefare u-boot over grub or vxworks bootloader because it has many 
 features.
 
 If I understand correctly, sc520 is the only x86 target supported.

At this point in time, yes

 
 Is it a huge project to port it to another x86 target that has a different 
 ethernet controller ?

Only one way to find out ;)

 
 The u-boot image is loader by the BIOS from compact flash via SATA.

No, U-Boot replaces the BIOS completely

 
 What is the procedure for writing u-boot image on this flash ?

You will need to determine if the BIOS chip in the COM 840 can be
reprogrammed and if so, how

Regards,

Graeme

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot