gmane.os.openbsd.arm

Re: beagle kernel hangs when executing init on Pandaboard

minux — 2013-06-16T18:48:58

On Mon, Jun 17, 2013 at 1:20 AM, Brandon Mercer
<yourcomputerpal< at >gmail.com> wrote:
Aha, didn't know that. Thank you for the info.

i was thinking because pandaboard was introduced earlier, it should have
better support, and it turned i was wrong.

anyway, I just got OpenBSD/beagle working happily on Pandaboard ES.

Thank you for all the hard work in porting.

Cheers,
minux

Re: beagle kernel hangs when executing init on Pandaboard

Brandon Mercer — 2013-06-16T17:20:43

Yes, unfortunately right now the -current stuff will only work with
panda ES. Things are being worked on, please be patient.

On Sun, Jun 16, 2013 at 10:05 AM, minux <minux.ma< at >gmail.com> wrote:

beagle kernel hangs when executing init on Pandaboard

minux — 2013-06-16T17:05:32

Dear List,

I'm working on getting OpenBSD/beagle running on a Pandaboard, but so
far, without success.
I'm using latest binary sets of armish port as root fs.

the GENERIC kernel seemed to boot correctly, and it recognized most
hardware, however, the console
output stopped after the WARNING line:

<snip>
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <SD/MMC, Drive #01, > SCSI2 0/direct fixed
sd0: 3781MB, 512 bytes/sector, 7744512 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: lookup '' failed.
root device: sd0a
swap device (default sd0b):
root on sd0a swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!

I tried to add some printf to init(8) and enabled SYSCALL_DEBUG, but
every time it boots, init(8) stops
at a different point.

example 1:
proc 22279 (init): native num 194 ret: err = 0, rv = 0x0,0xbffc3380
proc 22279 (init): native num 195 call: setrlimit(0x8, 0xbffc3390)
proc 22279 (init): native nu

EOMA-68 CPU - Arm Board

OpenBSD — 2013-06-07T14:35:30

Hi arm< at >

Would any of the arm developers be interested in a Rhombus Tech EOMA68 
CPU board? It has an ARM Cortex A8.

Further details can be found at:

http://rhombus-tech.net/allwinner_a10/

I would be able to get hold of one of the sample boards for a developer 
if there is any interest in an arm system like this.

Thanks

Fred

PS an image of the board is in the section: 29 Apr 2013: First sample 
pictures http://rhombus-tech.net/allwinner_a10/news/

Re: BeagleBoard Black

Claudiu Tanaselia — 2013-04-25T05:39:58

Unfortunately, I didn't had the chance to get my hands on a BeagleBoard
yet. I'll probably get one in the future, the price is pretty decent. I do
own a Raspberry Pi, but I can understand why there are no efforts towards
this platform.


On Wed, Apr 24, 2013 at 4:36 PM, Jonatan Walck <jonatan< at >walck.se> wrote:

Re: BeagleBoard Black

Brandon Mercer — 2013-04-24T13:43:07

The beaglebone black will not run on our existing beagle work. Dev
work would need to be done to get it up and running. There are a lot
of arm products coming out right now. Some of them have powerful cpus
and are useful for computational things. Others have SATA slots so we
can attach spinny disks or SSD's which is useful. Still yet, we have
things like the beaglebone and black have a bunch of headers for
interfacing with sensors, LED's. It's hard to decide which devices to
support.

On Wed, Apr 24, 2013 at 9:36 AM, Jonatan Walck <jonatan< at >walck.se> wrote:

Re: BeagleBoard Black

Jonatan Walck — 2013-04-24T13:36:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-04-24 11:39, Claudiu Tanaselia wrote:

Have you tried running the linked port on any other BeagleBoard
hardware, any experiences to share?

I already have a pile of BeagleBone Blacks on order - I'd be
interested in testing when they arrive. From the changes that have
been made from the original BeagleBone I see nothing that should limit
or exclude the Black from any previous porting efforts.

The linked page only talks of the original BeagleBoard thoiugh - which
is a quite different beast (different SOC family) so I don't dare to
guess what will work or break out of the box.

Best regards,
Jonatan Walck
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRd9/EAAoJEFwg9i9GDX+nxtkQALrmfKScE5lijDbnEZEOmDxU
Qlm/9znrkAbYlrnxLWlbbgOicsIH3sBJ354GBQEAF+pm7sK1royrHS8efHSkNbTh
jF5575Xz99pFN0qq1hhcWzO5RTJJUFeSeYLbrJ14QjmbmzSxk9D7jN5QenOGYik2
sjcyiwrajwrYpVZxbAIljxMoUw8rEd+gFdTuKm/6KF+euPwQvWFZX6mYY3yo8QfK
XloWLn6hwCf6iBSfjAQUb3NZ89DLkNR

BeagleBoard Black

Claudiu Tanaselia — 2013-04-24T09:39:14

Hi,

You are probably aware of the new BeagleBoard Black (
http://beagleboard.org/Products/BeagleBone%20Black). Any chance OpenBSD
would decently run on it any time soon? I am aware of the efforts posted
here: http://www.openbsd.org/beagle.html and I'm keeping an eye on that
page, hoping that support will be updated for the new version.

Regards,
Claudiu.

Re: Any platform useful as a graphical desktop?

Marek Vasut — 2013-03-04T21:26:17

Dear Rob Sciuk,


That's good :)

Best regards,
Marek Vasut

Re: Any platform useful as a graphical desktop?

Rob Sciuk — 2013-03-04T18:48:27

I'm aware of the ethaddr mechanism, but the complication was that the mac 
address is a function of the ATCA chassis address, and slot number, and 
this must be determined at boot time by means of an onboard ATCA/BMC 
controller requesting the address information over an I2C bus from the 
shelf manager.

In order to communicate with the BMC, I had to fake a second serial port 
in u-boot, by having the console switch back and forth between the real 
console and the uart controlling the BMC controller.  Also, there are 6 
MAC id's to configure, in accordance with a strict requirement.  The 
serial communication protocol used the IPMI/PICMG3 encoding, and quite 
frankly was a bigger pain than the boot protocol ... but I must say that I 
learned a lot in the process ... both about U-Boot, the PPC architecture 
and ATCA.



Thanks why I suggested NetBSD 8-) .... Thanks again for your comments. 
They are, indeed well received.

Cheers,
Rob.

Re: Any platform useful as a graphical desktop?

Marek Vasut — 2013-03-04T18:13:02

Dear Rob Sciuk,


True, the OF is getting a lot of traction. Btw. setting up the mac address in u-
boot is possible too by setting 'ethaddr' variable in the command line. It's 
even propagated into the DT node as local-mac-address iirc. I recall the FECes 
do not have mac address written in them indeed.


I had some ... uh ... disagreement with Theo. Besides, I now work on Linux/U-
Boot a lot, so that's about it.

Best regards,
Marek Vasut

Re: Any platform useful as a graphical desktop?

Rob Sciuk — 2013-03-04T16:52:57


This was a work related project on a PPC/FPGA(7) ATCA platform.  A number 
of constraints were in place, and the mechanism described allows MAC 
address setup in U-Boot (as determined by querying the Shelf controller 
via a serial port), and a great deal of flexibility in that by changing 
ONLY the dhcpd configuration, we can load different OS/FPGA loads onto the 
blade.  It has worked very well for us, as the ATCA platform is a 
controlled environment (and WE have control).  I don't defend the design 
decision, only mention it as it works well.  Also, this application is a 
high powered telecom simulator aimed at CO's of major telecom carriers, 
not a mass market product such as PDA.

Your comments regarding the aged Bootp protocol were well taken, but a 
close code inspection gave us the all the necessary info to extend the 
protocol, and the end result has provided good flexibility for future 
enhancements with a minimum of coding.

Given another project, particularly one aimed at end users, I would be

Re: Any platform useful as a graphical desktop?

Marek Vasut — 2013-03-04T12:15:33

Dear Rob Sciuk,


Uh, so why not switch to tftp or nfs since it's much easier to work with ?

Best regards,
Marek Vasut

Re: Any platform useful as a graphical desktop?

Marek Vasut — 2013-03-03T21:22:57

Dear Rob Sciuk,


Bootp is weird junk, just use tftp to transfer your files (using the 'tftp' 
command in U-Boot) and then 'bootm' that stuff. Note that the FDT location is 
passed to the kernel in one of the CPU registers, R2 IIRC.

Best regards,
Marek Vasut

Re: Any platform useful as a graphical desktop?

Rob Sciuk — 2013-02-22T22:59:33


If you are serious about changing your dhcpd configuration, here at least 
is the .conf file for dhcpd -- or a segment of it, which demonstrates the 
mechanism I used:

option boot-device-tree code 132 = text ;
option boot-file-system code 133 = text ;

# hotwire1 boards
#
class "hotwire1" {
     match if substring( dhcp-client-identifier, 0, 9 ) = "hotwire1_" ;

     filename "hotwire1.uImage" ;
     option boot-device-tree "hotwire1.fdt" ;
     option boot-file-system "hotwire1.initrd" ;
}

I would have to dig to find the u-boot code to extend the protocol, but it 
wasn't too difficult ...

Cheers,
Rob Sciuk

Re: Any platform useful as a graphical desktop?

Miod Vallat — 2013-02-22T22:48:47

So you had to extend an RFC protocol to boot some form of Linux. Sure,
that's the way thing go - I'm gonna fix my bootp server right now to
support the wicked way Linux on ARM does things, just so that I get a
thin chance for a kernel to recognize the world it's running in.

Am I the only one to think that we are trying to walk on our heads where
the way to boot a kernel is to chainsaw a good-old-comes-with-an-RFC
protocol to the greedy needs of a particular operating system?


I'd drink to that.

Re: Any platform useful as a graphical desktop?

Rob Sciuk — 2013-02-22T22:37:17


I used the tftp/bootp protocol to load the kernel, the initrd and the fdt 
into RAM from u-boot (the auto-boot), and then pass the three addresses 
(fixed) to the bootm command in order:  bootm 0x100000 0x200000 0x3000000. 
Of course, I had to extend the BOOTP protocol with an OEM extension to 
allow Bootp to know about the FDT, but that facility was already in 
U-Boot -- you simply need to look.



They do risk being spoiled by their own success ... OK ... everyone drop 
arm, and go to MIPS -- immediately! 8-)


Given that a single device tree, describing a target board could be used 
by each of the 3 distros, they could share OF drivers and trivially 
support new targets ... yup.  You're right, it is not compelling enough to 
get Theo and the other kids to play nicely.

Oh well.

Re: Any platform useful as a graphical desktop?

Miod Vallat — 2013-02-22T22:27:58

But how do you pass an FDT to the kernel? Oh, that's easy, it's at
0xff000000. Unless it's at 0xf0000000, that is. Which it is, except when
it's at 0xf800f000. But did I mention it might reside at 0xfd000000?
When it's not at 0xe2000000 of course, but you knew this because it was
not at 0xc2001000. Or was it?


Let me tell you a secret. But please don't tell anyone.

  THEY FSCKING DON'T CARE!

...because either way they'll sell their ugly chip anyway.


This item currently does not fit the ARM world. Convince them to adopt
sane standards and you'll be my hero (for at least a whole year).


BSD bonding together? Even for something which would benefit them?
You're smoking way too much weed.

Miod

Re: Any platform useful as a graphical desktop?

Rob Sciuk — 2013-02-22T22:20:19


Actually, FDT's have a specific node which is used to pass argments to the 
kernel, and arbitrary values are simple to pass via the device tree. 
U-Boot in particular has FDT editing capabilities which allow a run-time 
change to the kernel params via the FDT from the console.



A good thing IMHO.  I believe that the FreeBSD boot process still uses 
FICL, a forth interpreter which I believe was inspired by OpenFirmware.


Were Open, and indeed *ALL* the 'BSDs to adopt a similar OpenFirmware 
interface on ALL embedded, it would provide the impetus to move to a 
device tree model regardless of architecture.  Essentially, one need 
simply define the SoC and on board devices of a new target board within 
the device tree, and the drivers would find registers.  Drivers could be 
largely platform agnostic (at least to the extent that they can be), and 
even shared between OSes (licensing issues aside).

Do you get the feeling that I like the device tree approach??


Given that Arm is fabless, perhaps *THEY* shou

Re: Any platform useful as a graphical desktop?

Miod Vallat — 2013-02-22T21:27:50

Ok, I'll bite, but don't take it personnaly.

There are thousands arm-based designs available today. Every one of them
tries to be better than the others in at least one area.

But none of their manufacturer address the real problem.

The problem is that all those ARM designs lack a non-braindead, usable,
firmware interface.

Every ARM gimmick you can find over the last 10 years runs either
a custom configuration of RedBoot, or a custom configuration of U-Boot,
or something different. There is no way to write a design-agnostic
kernel which will be able to figure out its environment (firmware,
configuration data, devices). Passing an FDT file to describe the
devices is not an option, because there is no well-defined way to pass
arguments to the kernel, due to all these conflicting and/or subtly
incompatible firmwares.

Compare this to the PowerPC or SPARC world, where every decent system
can expect to have an OpenFirmware interface.

The OpenBSD ports to the various arm devices have been trying to cover
the

Allwinter

max stalnaker — 2013-02-22T20:42:44

Oh thanks.  Suppose i treated the allwinter as headless and just sshed in
and was happy with CLI.  Do i need a framebuffet still?  I think of the
framebuffer as been around forever and everything has it but what do i know.

Max
On Feb 22, 2013 12:28 PM, "Matthieu Herrb" <matthieu.herrb< at >laas.fr> wrote: