Question about "Installing" Slackware/Debian

[Martin aka Conzi]

Hello,

i'm new to the bifferboard community and would like to ask one or two
newbie-question for which i a could not find answers anywhere. I
recieved my BB yesterday and was happy to see, that there is OpenWRT
preinstalled an that pluging in is all i had to do. But that's not fun
and was not the goal. So i tried to get debian to work (following
famzah's doc) but i was not able to get it running. A shot moment i
though i bricked my bb, but reflashing the original bzImage worked
like a charme. So i tried to get slackware running and did not succed
at all. :-/
Back at work i had some spare time and tried it again and got it. But
like i mentioned before here are my questions:

a) I thought that i've read somewhere, that biffboot will boot "any"
linux put on a USB-Stick ootb. Am i wrong here? I had no success with
it and had to flash the /boot/bzImage found in the slackware
tarball.

b) "someone mentioned somewhere" that putting the OpenWRT rootfs on an
USB-Stick would be enough to get OpenWRT running there. I would like
to install some packages but the onboard-space is to less. So i need a
rootfs on a stick => where can i get it? Must i it build on my own?

c) finally the "1 million dollar question": Why does debian not work?
This question is not meant "like it is" - i would like to be pointed
in thr right direction or on the "standard problem"....


Regards from Cologne/Germany,
Martin

[biff...@yahoo.co.uk]

On Nov 25, 6:39 pm, Martin aka Conzi <m...@conzi.com> wrote:
> Hello,
>
> i'm new to the bifferboard community and would like to ask one or two
> newbie-question for which i a could not find answers anywhere. I
> recieved my BB yesterday and was happy to see, that there is OpenWRT
> preinstalled an that pluging in is all i had to do. But that's not fun
> and was not the goal. So i tried to get debian to work (following
> famzah's doc) but i was not able to get it running. A shot moment i

It would be good to tell us what you did, what you typed, and what got
printed when you did this.

> though i bricked my bb, but reflashing the original bzImage worked
> like a charme. So i tried to get slackware running and did not succed
> at all. :-/

As above.

> Back at work i had some spare time and tried it again and got it. But
> like i mentioned before here are my questions:
>
> a) I thought that i've read somewhere, that biffboot will boot "any"
> linux put on a USB-Stick ootb. Am i wrong here? I had no success with
> it and had to flash the /boot/bzImage found in the slackware
> tarball.

That's not true. You need the correct kernel, kernel command-line and
rootfs to get a boot.

> b) "someone mentioned somewhere" that putting the OpenWRT rootfs on an
> USB-Stick would be enough to get OpenWRT running there. I would like

It's not that simple. You have to make some modifications first.
Some to get a boot, then quite a few to get the opkg package
management system working. Not for beginners.

> to install some packages but the onboard-space is to less. So i need a
> rootfs on a stick => where can i get it? Must i it build on my own?

The best is to use OpenWrt only for running from the onboard flash,
use Debian or Slackware for USB-root systems.

> c) finally the "1 million dollar question": Why does debian not work?
> This question is not meant "like it is" - i would like to be pointed
> in thr right direction or on the "standard problem"....

The 10 million dollar question is are you going to provide enough
information for anyone to tell you why? :).

regards,
Biff.

[Martin aka Conzi]

Hello Biff,

thanks for your reply. While writing my answer i was playing around
with my "new" serial cable. And i found the solution. It was the a
missing kernel commandline :-/ But i will keep this post "as i wrote
it some minutes ago" to give other newbies something to find if they
do a google search ;-) The solution could be found at the end...

On 25 Nov., 22:22, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

> On Nov 25, 6:39 pm, Martin aka Conzi <m...@conzi.com> wrote:

>
> That's not true.  You need the correct kernel, kernel command-line and
> rootfs to get a boot.
>

> ...

>
> It's not that simple.  You have to make some modifications first.
> Some to get a boot, then quite a few to get the opkg package
> management system working.  Not for beginners.

Ok, good to know.

> The best is to use OpenWrt only for running from the onboard flash,
> use Debian or Slackware for USB-root systems.
>

Ok, I got Slackware up an running. But i like debian an would like to
run it on the BB to. So lets get to the 10 million dollar question:

> The 10 million dollar question is are you going to provide enough
> information for anyone to tell you why? :).

I will try ;-) I took an USB Stick and prepared it like described
here: http://blog.famzah.net/2009/11/20/running-debian-on-bifferboard/
I've tested this stick on my Ubunut notebook an was able to use this
stick as rootfs. So i think, the stick might be not the problem.

The i used the bb_eth_upload8.py from svn to upload the Kernel
(vmlinuz-2.6.30.5-bifferboard-ipipe) as described under the above
link. There where no errors and 113 Chunks were written.

After that i put the Stick in and powered the BB up an nothing
happend. The stick doen't even light up.

Today i took an sparkfun.com FTDI Board an builded an serial cable to
see what's happening (or not). That's what i get when powering the
Board on:

BIFFBOOT v3.3 00B3F6005F76 32-bit Loader by bifferos (c) 2010
Redistribution prohibited, all rights reserved.
Press
NIC up in: 1220 mS
Link up
Checking NIC
Started net console
re-reading config
Booting...
00100000 loaded from flash.
Booting Linux with:

That'a ll :-/
I tried the same with the dutch debian kernel () and got the same .
Finally I did the above steps with Slackware and everything went fine.
So what could be wrong with debian?

SOLUTION: After i reconfigured my minicom as described here (http://
blog.pjsip.org/2008/01/02/setting-up-your-linux-desktop-for-blackfin-
bf-537-stamp-board-development/ but use 115200baud!) i was finally
able to press ESC at biffboot. After typing "help" (thanks for that!)
i saw a command "usbroot". So i typed "usbroot" and "go" (and an
reboot later "usbroot" => "save") and i've got debian up and running!
Yeah!

IMPORANT: Debain on the Bifferboard is not possible without the use of
a serial cable!


Regards from Cologne/Germany
Martin

PS: Sorry for my "freestyle english" ;-)

[Andrew Scheller]

> able to press ESC at biffboot. After typing "help" (thanks for that!)
> i saw a command "usbroot". So i typed "usbroot" and "go" (and an
> reboot later "usbroot" => "save") and i've got debian up and running!

Glad to hear you got it working :) The confusion is due to the fact
that the first versions of the bifferboard shipped with the kernel
command line pre-set to use a USB rootfs. So all the instructions that
were written at the time didn't bother explaining that the command
line needed to be set.
But then Biff got OpenWRT working from flash, so he removed the
'default' command line in BiffBoot, and embedded the command line
inside the openwrt kernel.
But of course in order to follow "older" instructions (Slackware or
Debian), you need to set/change the kernel command line to what it
used to be.
And to find out what the command line used to be, you can look at the
'screenshots' on
http://sites.google.com/site/bifferboard/Home/bootloader/changelog

> IMPORANT: Debain on the Bifferboard is not possible without the use of
> a serial cable!

Not necessarily ;)
http://sites.google.com/site/bifferboard/Home/bootloader/bb_eth_setconfig-py

Lurch

[Martin aka Conzi]

> But of course in order to follow "older" instructions (Slackware or
> Debian), you need to set/change the kernel command line to what it
> used to be.

I will contact famzah and tell him to add a note to his guide.

> Not necessarily ;) http://sites.google.com/site/bifferboard/Home/bootloader/bb_eth_setco...

*argh* - but i love the smell of solder ;-)

I'm going to write a german howto/step by step guide on http://www.m8in.de
in the next days. Maybe other noobs will not run in those to "traps"
again...

Regards,
Martin

[Martin aka Conzi]

One last question (for today):

I took a look at famzah's debian kernel config and found the following
lines:

CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=uart,io,0x3f8 root=/dev/sda1 rootwait ro"
CONFIG_CMDLINE_OVERRIDE=y

Shouldn't that be enought to get debian boot from /dev/sda1?

Regard,
Martin

[Ivan Zahariev (famzah)]

That was unexpected and not backward compatible :P~

Lurch, what do we need to set the "Boot source" using
"bb_eth_setconfig.py" - set it from the default "Flash" to "MMC" (in
order to boot from USB) ?

Thanks.
--famzah

On 28 Ноем, 20:58, Andrew Scheller <ya...@loowis.durge.org> wrote:
> Glad to hear you got it working :) The confusion is due to the fact
> that the first versions of the bifferboard shipped with the kernel
> command line pre-set to use a USB rootfs. So all the instructions that
> were written at the time didn't bother explaining that the command
> line needed to be set.

> > IMPORANT: Debain on the Bifferboard is not possible without the use of
> > a serial cable!
>

> Not necessarily ;)http://sites.google.com/site/bifferboard/Home/bootloader/bb_eth_setco...
>
> Lurch

[Andrew Scheller]

> That was unexpected and not backward compatible :P~

It wasn't a personal criticism - I'm also guilty of not updating my
Slackware instructions yet...

> Lurch, what do we need to set the "Boot source" using
> "bb_eth_setconfig.py" - set it from the default "Flash" to "MMC" (in
> order to boot from USB) ?

The Boot source is where it loads the kernel from - so you need to set
it *always* to Flash. The MMC setting is only if you're doing
http://sites.google.com/site/bifferboard/sd_mmc_howto

Where the rootfs is loaded from (i.e. USB for Debian and Slackware),
is controlled entirely by the kernel (and/or the kernel command line).

Lurch

[Ivan Zahariev (famzah)]

> > That was unexpected and not backward compatible :P~
>
> It wasn't a personal criticism - I'm also guilty of not updating my
> Slackware instructions yet...

I know, I was just joking ;)

> Where the rootfs is loaded from (i.e. USB for Debian and Slackware),
> is controlled entirely by the kernel (and/or the kernel command line).

I got confused, a bit. I've got a couple of things to straight out:

1. The default "Boot source" is fine, even with the new versions of
Biffboot? (it boots from the USB Flash/MMC)

2. The new thing is that the "Kernel cmndline" is now different,
right? Is it empty or what?

3. How should I re-compile the Debian Linux kernel now? With the
"console=uart,io,0x3f8 root=/dev/sda1 rootwait ro" command line string
by default?

4. (this depends on #2) Should I completely override the kernel string
provided by the Biffboot loader, by enabling "CMDLINE_OVERRIDE" in the
kernel config?

5. Or should I just leave the kernel as it is, and ask people to fix
the kernel command line by "bb_eth_setconfig.py" or by the serial
console?

6. What did the "usbroot" magic command did in Biffboot, as described
by Martin? He says that fixed it all. The command "usbroot" just
updated the kernel command line in Biffboot to the old default value -
"console=uart,io,0x3f8 root=/dev/sda1 rootwait ro"?

Thanks. And sorry for all the questions...
--famzah

[Andrew Scheller]

> 1. The default "Boot source" is fine, even with the new versions of
> Biffboot? (it boots from the USB Flash/MMC)

Yup.
But again "boot source" determines kernel location, not rootfs. For
the 2-port bifferboards, if the MMC/SD slot is used it just appears as
another USB Mass Storage device, and disables one of the USB ports.
I don't think Biffboot actually knows anything about USB (?)

> 2. The new thing is that the "Kernel cmndline" is now different,
> right? Is it empty or what?

See the 'screenshots' on
http://sites.google.com/site/bifferboard/Home/bootloader/changelog for
a complete(-ish) list of all the default config options on the
different BiffBoot versions.

> 3. How should I re-compile the Debian Linux kernel now? With the

> 4. (this depends on #2) Should I completely override the kernel string

> 5. Or should I just leave the kernel as it is, and ask people to fix

Entirely up to you, I guess :)
Whichever way you do it, you can guarantee different people will be
using different Biffboot versions (and therefore different default
configs).
I'm not sure of the specifics (as it's something I've not played with)
but apparently sometimes the command-line set in biffboot can
'interfere' with the command-line embedded in the kernel.

> 6. What did the "usbroot" magic command did in Biffboot, as described
> by Martin? He says that fixed it all. The command "usbroot" just
> updated the kernel command line in Biffboot to the old default value -
> "console=uart,io,0x3f8 root=/dev/sda1 rootwait ro"?

I don't have any bifferboards flashed to that kernel version ATM, but
I can check later if you like (if Biff doesn't beat me too it!)
I don't recall any Biffboot versions ever setting the rootfs readonly?

> Thanks. And sorry for all the questions...

No problem :)

Lurch

[biff...@yahoo.co.uk]

On Nov 30, 11:34 am, Andrew Scheller <ya...@loowis.durge.org> wrote:
> > 3. How should I re-compile the Debian Linux kernel now? With the
> > 4. (this depends on #2) Should I completely override the kernel string
> > 5. Or should I just leave the kernel as it is, and ask people to fix
>
> Entirely up to you, I guess :)

If you're maintaining your own kernel with your own distribution and
want to be safe you should override the command-line from the
bootloader completely. You don't want to add your own built-in
command-line to the Biffboot one, and you certainly don't want to rely
entirely on the Biffboot one, otherwise you're creating lots of
reasons why the user may fail to get a boot depending on their
configuration.

The downside to this is that they cannot then use the serial console
for other things, but if they want to do that chances are they have to
modify their rootfs anyhow (remove the getty stuff), so this is a bit
more complicated, and I don't think it's practical to have two
distributions, one for each case.

If you guys can think of ways of making all this simpler for future
versions of Biffboot, then please let me know. I'd like to avoid a
'Debian' option in Biffboot, because I don't really think it's the
business of the BIOS to know about the OS it's booting (other than to
conform to some parameter-passing kernel API perhaps). I plan to
remove the 'usbroot' option in future versions. It may have worked
for somebody sometime, but I think it only causes confusion.

thanks,
Biff.

[Ivan Zahariev (famzah)]

> If you're maintaining your own kernel with your own distribution and
> want to be safe you should override the command-line from the
> bootloader completely.

Agreed, if we choose to use a custom kernel command-line string, then
it should completely override the (default) one by the bootloader.

> You don't want to add your own built-in
> command-line to the Biffboot one, and you certainly don't want to rely
> entirely on the Biffboot one, otherwise you're creating lots of
> reasons why the user may fail to get a boot depending on their
> configuration.

This is the really tough choice here, which should be made...

1. Leave/force administrators to update the Biffboot command-line
kernel string accordingly (and have *one more installation step* when
they run custom kernels).
--or
2. Give them no choice and hard-code the "rootfs=/dev/sda1" and
"console=uart" options (easier way to run/try custom kernels, but with
two significant drawbacks - the serial console is always used in
kernel mode, and the administrator *cannot* alter the kernel command-
line string, at all, in order to disable kernel features, or change
the rootfs location - can we have another one, besides USB/MMC for
Debian?).

My experience so far shows that if you want people to try Debian (in
this case), you have to make it as easy as possible -- option #2.
However, my engineer soul can't let me so easily close my way to
modifying the kernel command-line options, if we hard-code them. After
all, that's what why the bootloader gives you an option to modify the
kernel command-line string.

I'll be glad if anyone wants to share their opinion/thoughts on this
dilemma.

[Martin aka Conzi]

> I'll be glad if anyone wants to share their opinion/thoughts on this
> dilemma.

Hello,
my opinion is: let ist all unchanged. It was my "fault", that i did
not understand the relationship between biffboot -> commandline ->
kernel -> rootfs. I think it is important to let people know _what_
they have to do (and even how) - but then let that do on their own.

Regards,
Martin

[Andrew Scheller]

> I'll be glad if anyone wants to share their opinion/thoughts on this
> dilemma.

How hard would it be to just provide two kernels? A "newbie" kernel
which has a hard-coded embedded command line (and therefore works with
all biffboot default versions) and an "expert" kernel that reads the
command line from Biffboot?

Obviously the rootfs for each kernel would be the same...

Andrew