[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Peter Belm]

I posted a message before about this, but I didn't really give it the most
descriptive subject (I went off to find the chip model and then forgot to
add it to the subject, doh!)

Basically I'm trying to port uboot to the Broadcom BCM7038 chip, the current
bootloader I have is specific to the board (Hermes), and loads the kernel
from flash. I'd rather use uboot to start the SATA HDD and load the Linux
kernel from there. I have the source code for the bootloader and all the
Linux drivers, as well as documentation on the processor, but I'm not very
good at low level code.

As far as I can see I need to create a cpu/bcm7038 directory, add the
start.S from the original bootloader, and modify it to work with uboot (this
is the part I'm really not sure on!). Then add a board/hermes directory with
the rest of the original bootloader init code, and modify that to include
the SATA drivers, bring up the SATA interface, then load the kernel. But
theory is far from practice, and I'm already having trouble.

Would someone be able to assist me in porting to this cpu/board?

-- 
Regards,
Peter Belm

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Detlev Zundel]

Hi Peter,

> I posted a message before about this, but I didn't really give it the most
> descriptive subject (I went off to find the chip model and then forgot to
> add it to the subject, doh!)
>
> Basically I'm trying to port uboot to the Broadcom BCM7038 chip, the current
> bootloader I have is specific to the board (Hermes), and loads the kernel
> from flash. I'd rather use uboot to start the SATA HDD and load the Linux
> kernel from there. I have the source code for the bootloader and all the
> Linux drivers, as well as documentation on the processor, but I'm not very
> good at low level code.

You will be, once you have finished this port :)

> As far as I can see I need to create a cpu/bcm7038 directory, add the
> start.S from the original bootloader, and modify it to work with uboot (this
> is the part I'm really not sure on!).

Not quite.  A quick check reveals that the bcm7038 is a r5000 based
mips64 bit at heart (I'm a little confused here, there seem to be also
32bit r5000?).  So not only will you be doing a new cpu port (level 2),
but really a new architecture , i.e. mips64 - so you enter the game at
level 3 ;)

So very likely you should start out by creating cpu/mips64.  In here
should go everything which is general enough to also be of use for the
next mips64 ports that come along.

> Then add a board/hermes directory with the rest of the original
> bootloader init code, and modify that to include the SATA drivers,
> bring up the SATA interface, then load the kernel. But theory is far
> from practice, and I'm already having trouble.

SATA drivers will go below drivers/block, but yes, this is the theory.

> Would someone be able to assist me in porting to this cpu/board?

I'm not sure whether you fill find a single person, but I'm sure that
the mailing list as such will at least try to point you in the right
direction.

As always, post your ideas early and often not to invest too much time
in a non-promising route.

It might also be worthwhile to give the MIPS U-Boot maintainer a ping
whether he knows of anything with regard to your CPU or maybe even plans
something in his tree[1].

Cheers
  Detlev

[1] http://www.denx.de/wiki/U-Boot/Custodians

-- 
Etwas mehr wissen und etwas weniger leben.  Andere sagen es umgekehrt.
Gute Musse ist besser als Geschaefte. Nichts gehoert unser als nur die
Zeit, in welcher selbst der lebt, der keine Wohnung hat.
                                    --- Baltasar Gracian
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Wolfgang Denk]

Dear Detlev Zundel,

In message <m2prardbo5.fsf@ohwell.denx.de> you wrote:
> 
> Not quite.  A quick check reveals that the bcm7038 is a r5000 based
> mips64 bit at heart (I'm a little confused here, there seem to be also
> 32bit r5000?).  So not only will you be doing a new cpu port (level 2),
> but really a new architecture , i.e. mips64 - so you enter the game at
> level 3 ;)

That's not quite correct. IIRC, the "purple" board also uses a 64bit
MIPS processor (5Kc). So it's "just" anothe rnew board port.

> So very likely you should start out by creating cpu/mips64.  In here
> should go everything which is general enough to also be of use for the
> next mips64 ports that come along.

I think this is not compulsory.

> > Would someone be able to assist me in porting to this cpu/board?
> 
> I'm not sure whether you fill find a single person, but I'm sure that
> the mailing list as such will at least try to point you in the right
> direction.

And of course there is a number of companies who are specialized in
performing such ports, um... 

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: wd at denx.de
"There is nothing  so  deadly  as  not  to  hold  up  to  people  the
opportunity to do great and wonderful things, if we wish to stimulate
them in an active way."
- Dr. Harold Urey, Nobel Laureate in chemistry

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Peter Belm]

>
> > Not quite.  A quick check reveals that the bcm7038 is a r5000 based
> > mips64 bit at heart (I'm a little confused here, there seem to be also
> > 32bit r5000?).  So not only will you be doing a new cpu port (level 2),
> > but really a new architecture , i.e. mips64 - so you enter the game at
> > level 3 ;)
>
> That's not quite correct. IIRC, the "purple" board also uses a 64bit
> MIPS processor (5Kc). So it's "just" anothe rnew board port.
>

The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision
effects something like UBoot, would any registers be different? As for it
being 64bit, the current bootloader is being compiled with a 32bit version
of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or
does the fact it's a 64bit processor mean there's other changes which need
to be taken into account in UBoot?

And of course there is a number of companies who are specialized in
> performing such ports, um...


I'd prefer to perform this port myself (if possible!) it's no fun being a
hobbiest when you get someone else to do all your work.

SATA drivers will go below drivers/block, but yes, this is the theory.


Ok I think I get it now, in the cpu directory goes the code specific for
bringing up the cpu, using the cache, etc. So the board directory would
contain code for accessing the flash, init'ing memory, etc. And drivers
would go into drivers/ as you said.


There's one fundamental thing I still need to get sorted in my head, what
exactly is the role of UBoot? Is it just there to assist in creating a
bootloader? So the cpu code would do the main bringup, board specific code
would init the memory then use drivers provided by UBoot to access what it
needs to load the kernel, then calls code in UBoot to start it? Or does
UBoot perform a more invasive role than that?


Thank you for your help so far.

-- 
Regards,
Peter Belm

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Wolfgang Denk]

Dear Peter Belm,

In message <574bb010908200229m7da12930s39f7bc40a2384f1d@mail.gmail.com> you wrote:
>
> > That's not quite correct. IIRC, the "purple" board also uses a 64bit
> > MIPS processor (5Kc). So it's "just" anothe rnew board port.
> 
> The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision
> effects something like UBoot, would any registers be different? As for it

Well, _all_ hardware differences affect U-Boot. You will need a really
detailed understanding of the processor and your board.

> being 64bit, the current bootloader is being compiled with a 32bit version
> of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or

Right. That's what we do in case of the "purple" board, too.

> does the fact it's a 64bit processor mean there's other changes which need
> to be taken into account in UBoot?

This obviously depends on your hardware design. We cannot answer this
question.

> Ok I think I get it now, in the cpu directory goes the code specific for
> bringing up the cpu, using the cache, etc. So the board directory would
> contain code for accessing the flash, init'ing memory, etc. And drivers
> would go into drivers/ as you said.

Assuming you use standard flash chips, no code to access the flash
should co to the board directory. You should use the existing standard
drivers instead.

> There's one fundamental thing I still need to get sorted in my head, what
> exactly is the role of UBoot? Is it just there to assist in creating a
> bootloader? So the cpu code would do the main bringup, board specific code

U-Boot _is_ the boot loader.

> would init the memory then use drivers provided by UBoot to access what it
> needs to load the kernel, then calls code in UBoot to start it? Or does
> UBoot perform a more invasive role than that?

All the tasks you mention here are performed by U-Boot. U-Boot _is_
the boot loader.

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: wd at denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Peter Belm]

>
> All the tasks you mention here are performed by U-Boot. U-Boot _is_
> the boot loader.


Right, I'm just having trouble getting to grips with the code flow, the
start.S in the CPU is the initial entry point, at what point does that hand
over to U-Boot? Any chance you could give me a brief overview of the code
flow? In particular where the code I need to write fits in with the boot
process, i.e. where I need to interface with U-Boot.

Once I've got a better idea of how U-Boot boots, I should be able to get
started at least.

-- 
Regards,
Peter Belm

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Detlev Zundel]

Hi Wolfgang,

> Dear Detlev Zundel,
>
> In message <m2prardbo5.fsf@ohwell.denx.de> you wrote:
>> 
>> Not quite.  A quick check reveals that the bcm7038 is a r5000 based
>> mips64 bit at heart (I'm a little confused here, there seem to be also
>> 32bit r5000?).  So not only will you be doing a new cpu port (level 2),
>> but really a new architecture , i.e. mips64 - so you enter the game at
>> level 3 ;)
>
> That's not quite correct. IIRC, the "purple" board also uses a 64bit
> MIPS processor (5Kc). So it's "just" anothe rnew board port.

Yep, I've seen this.  But as this board defines "CONFIG_MIPS32" in its
config, I wasn't so sure about the real situation.

Cheers
  Detlev

-- 
"Win32 sucks so hard it could pull matter out of a Black Hole."
                                          -- Pohl Longsine
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Detlev Zundel]

Hi Peter,

>     All the tasks you mention here are performed by U-Boot. U-Boot _is_
>     the boot loader.
>
> Right, I'm just having trouble getting to grips with the code flow, the start.S
> in the CPU is the initial entry point, at what point does that hand over to
> U-Boot? Any chance you could give me a brief overview of the code flow? In
> particular where the code I need to write fits in with the boot process, i.e.
> where I need to interface with U-Boot.
>
> Once I've got a better idea of how U-Boot boots, I should be able to get
> started at least.

Be sure to read the section "Implementation Internals" in the README.
Other than that, simply trace the flow (on a piece of paper) for a
comparable board, e.g. the "purple" board which seems to be pretty close
to what you have.

Another hint is that functions in U-Boot ending with _f are run from
flash, wherease functions ending in _r run already relocated from RAM.

I hope this gets you started.

Cheers
  Detlev

-- 
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
             -- Miles Bader in <20030607122005.GA1086@gnu.org>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de