blob-cvs-commit

Using reblob to load another blob from ram

[Stefan S. <st...@da...>]

Hello.

I'm not sure if i'm wrong here, because this is cvs-commit list and
not discussion.

I'm writing here becuase the lart ml seems to be broken for at least 3
weeks. BTW, lart ml archive and anon cvs access to blob cvs is broken,
too. So no really good starting point for hacking on blob.

OK, back to my main problem. I'm one of the developer behind the
http://openezx.org/ project. EZX is the name of the Motorola Linux
smartphone architecture based on pxa27x. On this phones they use blob
as bootloader. But we like to extend blob to choose the kernel to boot
and booting kernel from MicroSD/SD card. This would help us a lot in
kernel and userspace development because we don't need to touch the
pre-installed system.

In some small talk with Tim Riker on IRC he suggested me to load
the extended blob into ram and do a reblob. Sounds great, but=20
unfortunately i get it not working.

Some more words about the setup. Motorola had modified blob. After
some discussion i was able to get the source. You can find it here:

http://www.datenfreihafen.org/~stefan/EZX/a780-blob.tar.bz2

It based on blob-2.0.5-pre2 .

We are able to communicate with the bootloader over usb. Harald Welte
wrote some kind of bootloader client which is called boot_usb.

http://svn.gnumonks.org/trunk/a780/src/boot_usb/

It loads the code into ram, exactly to KERNEL_RAM_BASE, and afterwards
JUMP to it. This works fine for selfcompiled kernels. But it does not
work for the blob binary at the moment.

A compile of the modified blob source give me the the following
interesting binaries:

blob
blob-chain
blob-rest
blob-rest-elf32
blob-start
blob-start-chain
blob-start-chain-elf32
blob-start-elf32

I tried all of them load to KERNEL_RAM_BASE and also to BLOB_RAM_BASE
as defined inside the blob code.

If i load blob or blob-start-elf32 the display goes blank and thats
it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
other tests exactly nothing happens.

I just changed the version string displayed to confirm if i see the
new blob on the screen.

So perhaps anybody here can help me at this point. The most
interesting questions are the following:

- Is there some good doc about blob? I don't find anything.
- Which binary i had to use for reblob?
- Which place i had to load into ram? BLOB_RAM_BASE or
  KERNEL_RAM_BASE?
- Tim Riker mentoined there are flying some SD card patches around.
  Where can i find it?

regards
Stefan Schmidt

Re: Using reblob to load another blob from ram

[Klaus F. <k.f...@fe...>]

Hello,

>Hello.
>
>I'm not sure if i'm wrong here, because this is cvs-commit list and
>not discussion.
>
>I'm writing here becuase the lart ml seems to be broken for at least 3
>weeks. BTW, lart ml archive and anon cvs access to blob cvs is broken,
>too. So no really good starting point for hacking on blob.
>
>OK, back to my main problem. I'm one of the developer behind the
>http://openezx.org/ project. EZX is the name of the Motorola Linux
>smartphone architecture based on pxa27x. On this phones they use blob
>as bootloader. But we like to extend blob to choose the kernel to boot
>and booting kernel from MicroSD/SD card. This would help us a lot in
>kernel and userspace development because we don't need to touch the
>pre-installed system.
>
>In some small talk with Tim Riker on IRC he suggested me to load
>the extended blob into ram and do a reblob. Sounds great, but 
>unfortunately i get it not working.
>
>Some more words about the setup. Motorola had modified blob. After
>some discussion i was able to get the source. You can find it here:
>
>http://www.datenfreihafen.org/~stefan/EZX/a780-blob.tar.bz2
>
>It based on blob-2.0.5-pre2 .
>
>We are able to communicate with the bootloader over usb. Harald Welte
>wrote some kind of bootloader client which is called boot_usb.
>
>http://svn.gnumonks.org/trunk/a780/src/boot_usb/
>
>It loads the code into ram, exactly to KERNEL_RAM_BASE, and afterwards
>JUMP to it. This works fine for selfcompiled kernels. But it does not
>work for the blob binary at the moment.
>
>A compile of the modified blob source give me the the following
>interesting binaries:
>
>blob
>blob-chain
>blob-rest
>blob-rest-elf32
>blob-start
>blob-start-chain
>blob-start-chain-elf32
>blob-start-elf32
>
>I tried all of them load to KERNEL_RAM_BASE and also to BLOB_RAM_BASE
>as defined inside the blob code.
>
>If i load blob or blob-start-elf32 the display goes blank and thats
>it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
>other tests exactly nothing happens.
>
>I just changed the version string displayed to confirm if i see the
>new blob on the screen.
>
>So perhaps anybody here can help me at this point. The most
>interesting questions are the following:
>
>- Is there some good doc about blob? I don't find anything.
>- Which binary i had to use for reblob?
>- Which place i had to load into ram? BLOB_RAM_BASE or
>  
>

BLOB_RAM_BASE : This is the destination address for the first stage of Blob, where the rest of blob is copied from flash to RAM.

>  ?
>  
>

KERNEL_RAM_BASE : This is the destination address, where the second stage of Blob the kernel copies from flash to RAM.



>- Tim Riker mentoined there are flying some SD card patches around.
>  Where can i find it?
>
>  
>
Klaus

Re: Using reblob to load another blob from ram

[Erik M. <er...@bi...>]

On Thu, Apr 27, 2006 at 08:55:23PM +0200, Stefan Schmidt wrote:
> I'm not sure if i'm wrong here, because this is cvs-commit list and
> not discussion.

Well, yeah, it's used for discussion as well.

> I'm writing here becuase the lart ml seems to be broken for at least 3
> weeks. BTW, lart ml archive and anon cvs access to blob cvs is broken,
> too. So no really good starting point for hacking on blob.

AnonCVS breakage is due to SF.net breakage. It's supposed to be fixed
Real Soon Now [tm]: https://sourceforge.net/docs/A04/#cvs .

I finally managed to upload my SSH key and get cvssuck to mirror the
CVS repository. See http://cvs.m17n.org/~akr/cvssuck/ . It's rather
slow however. Using cvsconnect to cache the connection speeds things up
but creates empty repositories so I'm back at cvssuck alone. When
that's done, I'll try to generate a GIT archive from the CVS repository
using Keith Packard's parsecvs (git-cvsimport barfs over certain
branches). It works quite well for other CVS repositories I tried, so I
guess it will manage to import blob CVS as well.

> OK, back to my main problem. I'm one of the developer behind the
> http://openezx.org/ project. EZX is the name of the Motorola Linux
> smartphone architecture based on pxa27x. On this phones they use blob
> as bootloader. But we like to extend blob to choose the kernel to boot
> and booting kernel from MicroSD/SD card. This would help us a lot in
> kernel and userspace development because we don't need to touch the
> pre-installed system.
> 
> In some small talk with Tim Riker on IRC he suggested me to load
> the extended blob into ram and do a reblob. Sounds great, but 
> unfortunately i get it not working.
> 
> Some more words about the setup. Motorola had modified blob. After
> some discussion i was able to get the source. You can find it here:
> 
> http://www.datenfreihafen.org/~stefan/EZX/a780-blob.tar.bz2
> 
> It based on blob-2.0.5-pre2 .
> 
> We are able to communicate with the bootloader over usb. Harald Welte
> wrote some kind of bootloader client which is called boot_usb.
> 
> http://svn.gnumonks.org/trunk/a780/src/boot_usb/
> 
> It loads the code into ram, exactly to KERNEL_RAM_BASE, and afterwards
> JUMP to it. This works fine for selfcompiled kernels. But it does not
> work for the blob binary at the moment.
> 
> A compile of the modified blob source give me the the following
> interesting binaries:
> 
> blob
> blob-chain
> blob-rest
> blob-rest-elf32
> blob-start
> blob-start-chain
> blob-start-chain-elf32
> blob-start-elf32

Everything -elf32 is the ELF32 version of the target. However, that
can't be used to start the machine, so we use objcopy to generate a
binary image. So: blob-start-elf32 --> (objcopy) --> blob-start .

Note the current CVS version uses a different way to build cause we use
the linker to link the second stage loader: we tell ld to generate an
.o file from blob-rest and link that into the first stage loader.

> I tried all of them load to KERNEL_RAM_BASE and also to BLOB_RAM_BASE
> as defined inside the blob code.

Right now there are four targets:

- blob-rest-elf32
- blob-rest
- blob-elf32
- blob

> If i load blob or blob-start-elf32 the display goes blank and thats
> it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
> other tests exactly nothing happens.

You should be able to reblob the second stage loader (i.e.: blob-rest).
It should be loaded at BLOB_RAM_BASE.

> I just changed the version string displayed to confirm if i see the
> new blob on the screen.
> 
> So perhaps anybody here can help me at this point. The most
> interesting questions are the following:
> 
> - Is there some good doc about blob? I don't find anything.

The source and the README is all there is.

> - Which binary i had to use for reblob?

blob-rest.

> - Which place i had to load into ram? BLOB_RAM_BASE or
>   KERNEL_RAM_BASE?

BLOB_RAM_BASE.

> - Tim Riker mentoined there are flying some SD card patches around.
>   Where can i find it?

I don't know about them. There is however some SD support in the
kernel.


Erik

-- 
----  Erik Mouw  ----  www.bitwizard.nl  ----  +31 15 2600 998  ----

Re: Using reblob to load another blob from ram

[Erik M. <er...@bi...>]

On Fri, Apr 28, 2006 at 04:09:12PM +0200, Erik Mouw wrote:
> I finally managed to upload my SSH key and get cvssuck to mirror the
> CVS repository. See http://cvs.m17n.org/~akr/cvssuck/ . It's rather
> slow however. Using cvsconnect to cache the connection speeds things up
> but creates empty repositories so I'm back at cvssuck alone. When
> that's done, I'll try to generate a GIT archive from the CVS repository
> using Keith Packard's parsecvs (git-cvsimport barfs over certain
> branches). It works quite well for other CVS repositories I tried, so I
> guess it will manage to import blob CVS as well.

Looks like it's going to work this time. I managed to convert the
CVSROOT into a git repository. Not very useful, but it shows the proof
of concept. Clone like this:

git clone http://a82-92-155-199.adsl.xs4all.nl/~erik/git/blob/CVSROOT/.git CVSROOT


Erik

-- 
----  Erik Mouw  ----  www.bitwizard.nl  ----  +31 15 2600 998  ----

Re: Using reblob to load another blob from ram

[Stefan S. <st...@da...>]

Hello.

On Fri, 2006-04-28 at 16:21, Erik Mouw wrote:
>=20
> Looks like it's going to work this time. I managed to convert the
> CVSROOT into a git repository. Not very useful, but it shows the proof
> of concept. Clone like this:
>=20
> git clone http://a82-92-155-199.adsl.xs4all.nl/~erik/git/blob/CVSROOT/.gi=
t CVSROOT

Thanks.

regards
Stefan Schmidt

Re: Using reblob to load another blob from ram

[Erik M. <er...@bi...>]

On Fri, Apr 28, 2006 at 05:05:53PM +0200, Stefan Schmidt wrote:
> On Fri, 2006-04-28 at 16:21, Erik Mouw wrote:
> > 
> > Looks like it's going to work this time. I managed to convert the
> > CVSROOT into a git repository. Not very useful, but it shows the proof
> > of concept. Clone like this:
> > 
> > git clone http://a82-92-155-199.adsl.xs4all.nl/~erik/git/blob/CVSROOT/.git CVSROOT
> 
> Thanks.

The blob archive itself is ready as well:

git clone http://a82-92-155-199.adsl.xs4all.nl/~erik/git/blob/blob/.git blob

Have fun.


Erik

-- 
----  Erik Mouw  ----  www.bitwizard.nl  ----  +31 15 2600 998  ----

Re: Using reblob to load another blob from ram

[Stefan S. <st...@da...>]

Hello.

On Fri, 2006-04-28 at 16:09, Erik Mouw wrote:
> >=20
> > A compile of the modified blob source give me the the following
> > interesting binaries:
> >=20
> > blob
> > blob-chain
> > blob-rest
> > blob-rest-elf32
> > blob-start
> > blob-start-chain
> > blob-start-chain-elf32
> > blob-start-elf32
>=20
> Everything -elf32 is the ELF32 version of the target. However, that
> can't be used to start the machine, so we use objcopy to generate a
> binary image. So: blob-start-elf32 --> (objcopy) --> blob-start .

OK, thanks for this information. Things get clear slowly.

> > If i load blob or blob-start-elf32 the display goes blank and thats
> > it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
> > other tests exactly nothing happens.
>=20
> You should be able to reblob the second stage loader (i.e.: blob-rest).
> It should be loaded at BLOB_RAM_BASE.

OK, so i can focus on this and try to add some debug information to
see why things go wrong.

> > - Is there some good doc about blob? I don't find anything.
>=20
> The source and the README is all there is.

So i'll need to dig through the source code. Perhaps i have some time
at the weekend. :)

regards
Stefan Schmidt

Re: Using reblob to load another blob from ram

[Stefan S. <st...@da...>]

Hello.

On Fri, 2006-04-28 at 16:09, Erik Mouw wrote:
>=20
> > If i load blob or blob-start-elf32 the display goes blank and thats
> > it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
> > other tests exactly nothing happens.
>=20
> You should be able to reblob the second stage loader (i.e.: blob-rest).
> It should be loaded at BLOB_RAM_BASE.

JFYI: This did not work here. Perhaps this feature is disabled inside
the Motorola blob. I'm busy at the moment, but hopefully have some
time the next weekend for debugging this.

regards
Stefan Schmidt

Re: Using reblob to load another blob from ram

[Dan <da...@so...>]

Stefan Schmidt wrote:
> Hello.
>
> On Fri, 2006-04-28 at 16:09, Erik Mouw wrote:
>   
>>> If i load blob or blob-start-elf32 the display goes blank and thats
>>> it. For blob-start at KERNEL_RAM_BASE it goes blank, too. On all the
>>> other tests exactly nothing happens.
>>>       
>> You should be able to reblob the second stage loader (i.e.: blob-rest).
>> It should be loaded at BLOB_RAM_BASE.
>>     
>
> JFYI: This did not work here. Perhaps this feature is disabled inside
> the Motorola blob. I'm busy at the moment, but hopefully have some
> time the next weekend for debugging this.
>
> regards
> Stefan Schmidt
>   

I observed that while BLOB loads and jumps to BLOB_RAM_BASE, the second 
stage loader (blob-rest) is actually built to run at 
BLOB_ABS_BASE_ADDR.   The reblob command should be [safely] copying the 
second stage BLOB from BLOB_RAM_BASE to BLOB_ABS_BASE_ADDR and then 
jumping there, but I guess it doesn't (not that I've checked in a while).

So one trick I use for reblob is to build and install a BLOB, then swap 
those two defines, build a new BLOB, and feed the second BLOB to the 
first.  Did that make sense?

cheers,
Dan

Re: Using reblob to load another blob from ram

[Erik M. <er...@bi...>]

On Mon, May 01, 2006 at 06:22:16PM -0400, Dan wrote:
> Stefan Schmidt wrote:
> >On Fri, 2006-04-28 at 16:09, Erik Mouw wrote:
> >>You should be able to reblob the second stage loader (i.e.: blob-rest).
> >>It should be loaded at BLOB_RAM_BASE.
> >
> >JFYI: This did not work here. Perhaps this feature is disabled inside
> >the Motorola blob. I'm busy at the moment, but hopefully have some
> >time the next weekend for debugging this.
> 
> I observed that while BLOB loads and jumps to BLOB_RAM_BASE, the second 
> stage loader (blob-rest) is actually built to run at 
> BLOB_ABS_BASE_ADDR.   The reblob command should be [safely] copying the 
> second stage BLOB from BLOB_RAM_BASE to BLOB_ABS_BASE_ADDR and then 
> jumping there, but I guess it doesn't (not that I've checked in a while).

You nailed the problem, thanks. Here's the git patch to fix it (also
pushed to the repository). The target to use for reblob is/was
blob-chain.


Erik

diff-tree bd6e87da76478d39e134387edef68f2a0c766e5b (from 16ee5944280da198b1c569ddc8500797a8332d13)
Author: Erik Mouw <mo...@nl...>
Date:   Tue May 2 12:33:12 2006 +0200

    Recreate blob-chain target used for the "reblob" command.
    
    When overhauling the Makefile to include the second stage
    loader, I forgot to overhaul the chain loader as well. This
    patch recreats the blob-chain target. Also some minor cleanups
    in chain.S, we don't need to fiddle with the LEDs anymore.

diff --git a/src/blob/Makefile.am b/src/blob/Makefile.am
index 32151c5..18d3743 100644
--- a/src/blob/Makefile.am
+++ b/src/blob/Makefile.am
@@ -24,7 +24,9 @@ #
 bin_PROGRAMS	= \
 	blob-rest-elf32 \
 	blob-rest \
+	blob-chain-elf32 \
 	blob-elf32 \
+	blob-chain \
 	blob
 
 
@@ -188,6 +190,26 @@ blob: blob-elf32
 	$(OBJCOPY) $(OCFLAGS) $< $@
 
 
+# ---- Blob-chain first stage loader for use with reblob -------------
+
+blob_chain_elf32_SOURCES	= \
+	chain.S
+
+blob_chain_elf32_DEPENDENCIES = \
+	start-ld-script \
+	blob-rest-piggy.o
+
+blob_chain_elf32_LDFLAGS = \
+	-static -nostdlib \
+	-Wl,-T,${srcdir}/start-ld-script \
+	-Wl,-Map,blob-chain-elf32.map
+
+blob_chain_SOURCES =
+
+blob-chain: blob-chain-elf32
+	$(OBJCOPY) $(OCFLAGS) $< $@
+
+
 # ---- Automake administrativia --------------------------------------
 
 EXTRA_DIST	= \
diff --git a/src/blob/chain.S b/src/blob/chain.S
index 8b4d94c..a5550aa 100644
--- a/src/blob/chain.S
+++ b/src/blob/chain.S
@@ -45,20 +45,15 @@ _start:
 	sub	r0, pc, #8
 	str	r0, START
 
-#ifdef H3600
+	b	relocate
+
 	/* this is a hack to be able to chain load blob from
 	 * bootldr. bootldr checks if it can find the linux zImage
 	 * magic value at the ninth word of an image, so we just put
 	 * it there.
 	 */
-	b	led
 .org (_start + 9 * 4)
 	.word	0x016f2818
-led:
-#endif
-
-	/* init LED */
-	//bl	ledinit
 
 	/* assume that the CPU and the memory are already set up at
 	 * this point. also assume that interrupts are disabled, and if
@@ -92,12 +87,6 @@ copy_loop:
 	ble	copy_loop
 
 
-	/* turn off the LED. if it stays off it is an indication that
-	 * we didn't make it into the C code 
-	 */
-	//bl led_off
-
-
 	/* blob is copied to ram, so jump to it */
 	ldr	r0, BLOB_START
 	mov	pc, r0

-- 
----  Erik Mouw  ----  www.bitwizard.nl  ----  +31 15 2600 998  ----