linuxdc-dev — Developer discussion list

Re: [linuxdc-dev] Modem driver

[<ps...@wi...>]

if you did want to be helpful, there is something you can do. rally more support for the cause! :D if you know any C coders who'd like to help out, let them know about the list. the more the merrier and all. oh, and thanks for the link - i hadn't seen that before! i might just take on porting it if nobody else has started. time to get more familiar with C ;)

On Sat, 23 Nov 2002 02:38:04 -0900
"Ryan Bouwens" <rbo...@po...> wrote:

> Not like this is any kind of real contribution, but because I am generaly
> just an idiot, all I can offer is a true thank you. I usualy do not post
> cause I am not part of the solution,just a bystander, but I would really
> like you guys to know that the work you do is very much apreciated. I guess
> I am just one of those crazy people who find this stuff interesting with out
> any real ability to do anything to be part of the community. So all I can
> offer is my thanks.
> 
> Ryan

Re: [linuxdc-dev] Modem driver

[Ryan B. <rbo...@po...>]

Not like this is any kind of real contribution, but because I am generaly
just an idiot, all I can offer is a true thank you. I usualy do not post
cause I am not part of the solution,just a bystander, but I would really
like you guys to know that the work you do is very much apreciated. I guess
I am just one of those crazy people who find this stuff interesting with out
any real ability to do anything to be part of the community. So all I can
offer is my thanks.

Ryan

> The basic point is - we only have three people currently doing any
development
> work and we're all busy doing other things at the moment.
>
> A year ago I hadn't written any kernel stuff - so it's not rocket science.
> Anyone with C programing experience can do this - so why don't more people
> jump in!
>
> Adrian

Re: [linuxdc-dev] Modem driver

[Adrian M. <ad...@mc...>]

On Saturday 23 Nov 2002 1:21 am, M. R. Brown wrote:
> * Ryan Bouwens <rbo...@po...> on Fri, Nov 22, 2002:
> > Out of curiosity, I may have missed the threath, but is their any plans
> > to use the modem driver that was recently released on www.dreamcast.info.
>
> This modem driver was written for KOS, not Linux.
>
The basic point is - we only have three people currently doing any development 
work and we're all busy doing other things at the moment.

A year ago I hadn't written any kernel stuff - so it's not rocket science. 
Anyone with C programing experience can do this - so why don't more people 
jump in!

Adrian

Re: [linuxdc-dev] Modem driver

[M. R. B. <mr...@0x...>]

* Ryan Bouwens <rbo...@po...> on Fri, Nov 22, 2002:

> Out of curiosity, I may have missed the threath, but is their any plans to
> use the modem driver that was recently released on www.dreamcast.info.
>=20

This modem driver was written for KOS, not Linux.

M. R.

[linuxdc-dev] Modem driver

[Ryan B. <rbo...@po...>]

Out of curiosity, I may have missed the threath, but is their any plans to
use the modem driver that was recently released on www.dreamcast.info.

Ryan

Re: [linuxdc-dev] vmufs question

[b b <lin...@ya...>]

--- Ben Srour <sr...@cs...> wrote:
> Whats the deal with the website?

- regardless of the reaons, those of us with
dreamcasts  just itching for an updated Linux kernel
will just have to wait...

- btw, it appears that while you can indeed, log into
the dreamcast via the coders cable using the release
from http://www.m17n.org/linux-sh/dreamcast/kernel,
you apparently cannot use it for anything else, such
as slattach for SLIP or pppd PPP... 

- we mere (non-developer) dreamcast mortals are still
stuck w/the m17n.org - all else is conjecture... the
serial cable is the only viable option (one would have
to be truly mad to pay for a broadband adapter)...

- it would be wonderful to have a working kernel and
release w/X with a working serial port... 

- otherwise, my dreamcast remains a toy...
> 
> Ben
> 
> -- 
> Ben Srour
> sr...@cs...
> 
> On Thu, 21 Nov 2002 ad...@mc... wrote:
> 
> > mr...@0x... wrote:
> > > * Adrian McMenamin <ad...@mc...> on
> Thu, Nov 21, 2002:
> > > > In the vmu all the game files are loaded into
> the vmu from block 0. Other=
> > > =20
> > > > files can be loaded anywhere.
> > > >=20
> > > > Should I implement this in the vmufs driver -
> ie should I force game file=
> > > s=20
> > > > (those with the eXec bit on) to be loaded into
> the vmu from block 0.
> > > >=20
> > > > Reasons for: unless this behaviour is enforced
> it will not be possible to=
> > >  use=20
> > > > vmufs to swap games files.
> > > >=20
> > > > Reasons against: could cuase problems loading
> the vmu with additional fil=
> > > es,=20
> > > > mixes questions of policy with mechanisms.
> > > >=20
> > > > What do people think?
> > > >=20
> > > Isn't the whole point of vmufs to stay
> compatible with official Dreamcast
> > > software?
> > > M. R.
> > >
> > Isn't the point to stay compatible with the format
> not simply
> > the software? If I follow the Sega way then you
> woin't be able to
> > save more than two executibles on a vmu, say.
> >
> >
> >
> >
>
-------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Linuxdc-dev mailing list
> > Lin...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
> >
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxdc-dev


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [linuxdc-dev] vmufs question

[Adrian M. <ad...@mc...>]

On Thursday 21 Nov 2002 11:49 pm, M. R. Brown wrote:
> * ad...@mc... <ad...@mc...> on Thu, Nov 21, 2002:
> > Isn't the point to stay compatible with the format not simply
> > the software? If I follow the Sega way then you woin't be able to
> > save more than two executibles on a vmu, say.
>
> Well, based on our (heated) discussion on IRC, you can only run one
> executable on the VMU anyway, so saving to executables is moot.  IMO it's
> best to stay *completely* compatible.
>
> M. R.

Heated?

Hardly! Lively, probably.

[linuxdc-dev] Kernel compilation problem

[Jon L. <jon...@im...>]

Hi everyone,

I am trying to make kernel 2.5.13 using GCC 3.0.1 to use SLIP, i'm 
getting the followig error(s):

fs/fs.o: In function `mnt_init':
fs/fs.o(.text.init+0xcf4): undefined reference to `init_rootfs'
drivers/net/net.o: In function `sl_bump':
drivers/net/net.o(.text+0x4b0): undefined reference to `netif_rx'
drivers/net/net.o: In function `sl_encaps':
drivers/net/net.o(.text+0x5e8): undefined reference to `softnet_data'
drivers/net/net.o: In function `slip_write_wakeup':
drivers/net/net.o(.text+0x724): undefined reference to `softnet_data'
drivers/net/net.o: In function `sl_tx_timeout':
drivers/net/net.o(.text+0x884): undefined reference to `softnet_data'
drivers/net/net.o: In function `sl_sync':
drivers/net/net.o(.text+0xdc8): undefined reference to `dev_close'
drivers/net/net.o: In function `sl_alloc':
drivers/net/net.o(.text+0xff8): undefined reference to 
`unregister_netdevice'
drivers/net/net.o: In function `slip_open':
drivers/net/net.o(.text+0x11b8): undefined reference to `rtnl_lock'
drivers/net/net.o(.text+0x11c4): undefined reference to `rtnl_unlock'
drivers/net/net.o(.text+0x11cc): undefined reference to 
`register_netdevice'
make: *** [vmlinux] Error 1


.config file is here

http://www.imgone.net/config.txt

Has anyone seen this problem before?
Any help much appreciated.

Jon Locke

Re: [linuxdc-dev] vmufs question

[M. R. B. <mr...@0x...>]

* ps...@wi... <ps...@wi...> on Fri, N=
ov 22, 2002:

> On Thu, 21 Nov 2002 17:23:58 -0600 (CST)
> Ben Srour <sr...@cs...> wrote:
>=20
> > Whats the deal with the website?
> >=20
> > Ben
>=20
> AFAIK, M.R.Brown has been without internet access for some time. give him=
 a bit to get his stuff together and we should have a pretty new website.
>=20

No, I have my net connection back, but there are still other things
precluding me from getting it done.  I'll keep the list posted.

M. R.

Re: [linuxdc-dev] vmufs question

[<ps...@wi...>]

On Thu, 21 Nov 2002 17:23:58 -0600 (CST)
Ben Srour <sr...@cs...> wrote:

> Whats the deal with the website?
> 
> Ben

AFAIK, M.R.Brown has been without internet access for some time. give him a bit to get his stuff together and we should have a pretty new website.

Re: [linuxdc-dev] vmufs question

[M. R. B. <mr...@0x...>]

* ad...@mc... <ad...@mc...> on Thu, Nov 21, 2002:

> Isn't the point to stay compatible with the format not simply=20
> the software? If I follow the Sega way then you woin't be able to
> save more than two executibles on a vmu, say.
>=20

Well, based on our (heated) discussion on IRC, you can only run one
executable on the VMU anyway, so saving to executables is moot.  IMO it's
best to stay *completely* compatible.

M. R.

Re: [linuxdc-dev] vmufs question

[Ben S. <sr...@cs...>]

Whats the deal with the website?

Ben

-- 
Ben Srour
sr...@cs...

On Thu, 21 Nov 2002 ad...@mc... wrote:

> mr...@0x... wrote:
> > * Adrian McMenamin <ad...@mc...> on Thu, Nov 21, 2002:
> > > In the vmu all the game files are loaded into the vmu from block 0. Other=
> > =20
> > > files can be loaded anywhere.
> > >=20
> > > Should I implement this in the vmufs driver - ie should I force game file=
> > s=20
> > > (those with the eXec bit on) to be loaded into the vmu from block 0.
> > >=20
> > > Reasons for: unless this behaviour is enforced it will not be possible to=
> >  use=20
> > > vmufs to swap games files.
> > >=20
> > > Reasons against: could cuase problems loading the vmu with additional fil=
> > es,=20
> > > mixes questions of policy with mechanisms.
> > >=20
> > > What do people think?
> > >=20
> > Isn't the whole point of vmufs to stay compatible with official Dreamcast
> > software?
> > M. R.
> >
> Isn't the point to stay compatible with the format not simply
> the software? If I follow the Sega way then you woin't be able to
> save more than two executibles on a vmu, say.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
>

Re: [linuxdc-dev] vmufs question

[<ad...@mc...>]

mr...@0x... wrote:
> * Adrian McMenamin <ad...@mc...> on Thu, Nov 21, 2002:
> > In the vmu all the game files are loaded into the vmu from block 0. Other=
> =20
> > files can be loaded anywhere.
> >=20
> > Should I implement this in the vmufs driver - ie should I force game file=
> s=20
> > (those with the eXec bit on) to be loaded into the vmu from block 0.
> >=20
> > Reasons for: unless this behaviour is enforced it will not be possible to=
>  use=20
> > vmufs to swap games files.
> >=20
> > Reasons against: could cuase problems loading the vmu with additional fil=
> es,=20
> > mixes questions of policy with mechanisms.
> >=20
> > What do people think?
> >=20
> Isn't the whole point of vmufs to stay compatible with official Dreamcast
> software?
> M. R.
> 
Isn't the point to stay compatible with the format not simply 
the software? If I follow the Sega way then you woin't be able to
save more than two executibles on a vmu, say.

Re: [linuxdc-dev] vmufs question

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Thu, Nov 21, 2002:

> In the vmu all the game files are loaded into the vmu from block 0. Other=
=20
> files can be loaded anywhere.
>=20
> Should I implement this in the vmufs driver - ie should I force game file=
s=20
> (those with the eXec bit on) to be loaded into the vmu from block 0.
>=20
> Reasons for: unless this behaviour is enforced it will not be possible to=
 use=20
> vmufs to swap games files.
>=20
> Reasons against: could cuase problems loading the vmu with additional fil=
es,=20
> mixes questions of policy with mechanisms.
>=20
> What do people think?
>=20

Isn't the whole point of vmufs to stay compatible with official Dreamcast
software?

M. R.

[linuxdc-dev] vmufs question

[Adrian M. <ad...@mc...>]

In the vmu all the game files are loaded into the vmu from block 0. Other 
files can be loaded anywhere.

Should I implement this in the vmufs driver - ie should I force game files 
(those with the eXec bit on) to be loaded into the vmu from block 0.

Reasons for: unless this behaviour is enforced it will not be possible to use 
vmufs to swap games files.

Reasons against: could cuase problems loading the vmu with additional files, 
mixes questions of policy with mechanisms.

What do people think?

Adrian

Re: [linuxdc-dev] LCD driver

[Adrian M. <ad...@mc...>]

On Saturday 16 Nov 2002 4:00 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sat, Nov 16, 2002:
> > Can I have a definitive statement on where people think this code should
> > live? This seems like a reasonable Saturday afternoon project as most of
> > the code is extant anyway in the vmu flash driver.
> >
> > But is it a framebuffer device or an mtd device?
> >
> > Answers please.....
>
> Note that in both stable and devel trees, Maple will be gutted and redone
> within the next few weeks.  I don't know if you want to continue with the
> driver, but just know *all* maple drivers will be ripped to shreds fairly
> quickly...
>
> M. R.

I haven't got very far in any case - as doing this as an fb device is not as 
simple as simply ripping out bits of code I don't want.

I will stick to vmufs then...

Adrian

Re: [linuxdc-dev] LCD driver

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Sat, Nov 16, 2002:

> Can I have a definitive statement on where people think this code should =
live?=20
> This seems like a reasonable Saturday afternoon project as most of the co=
de=20
> is extant anyway in the vmu flash driver.
>=20
> But is it a framebuffer device or an mtd device?
>=20
> Answers please.....
>=20

Note that in both stable and devel trees, Maple will be gutted and redone
within the next few weeks.  I don't know if you want to continue with the
driver, but just know *all* maple drivers will be ripped to shreds fairly
quickly...

M. R.

Re: [linuxdc-dev] LCD driver

[Karl T. K. <ka...@pr...>]

On Sat, 16 Nov 2002 12:23:32 +0000
Adrian McMenamin <ad...@mc...> wrote:

> But is it a framebuffer device or an mtd device?

Physically, it's obviously a framebuffer device, and I guess we should try
to make it appear as one logically as well.

However, if that doesn't work, can we address its buffer using mmap after
doing an open("/dev/lcd0") or whatever node name we choose ?

Kind regards,

Karl T

[linuxdc-dev] LCD driver

[Adrian M. <ad...@mc...>]

Can I have a definitive statement on where people think this code should live? 
This seems like a reasonable Saturday afternoon project as most of the code 
is extant anyway in the vmu flash driver.

But is it a framebuffer device or an mtd device?

Answers please.....

Adrian

Re: [linuxdc-dev] Trapping exceptions in the kernel

[David W. <dav...@ia...>]

> Is there a way of doing this? I want to rewrite the vmufs driver to make it as 
> independent of the underlying medium as possible and so I wanto to probe the 
> size of the vmu.
> 
> An obvious way is to attempt to read in vmu sectors until this fails - eg at 
> 128, at 256, at 512, at 1024. (Working on the suggested likely sizes for 
> alternative VMUs, assuming these things just might exist somewhere).
> 
> On a standard VMU 128 would succeed, 256 would fail and a simple check would 
> then reveal that the superblock was in sector 255.
> 
> But a buffer read at 256 will oops the kernel in these circumstances - is 
> there a mechanism to trap that exception?

The solution is to make the kernel not oops.  Why would it oops if the VMU says
a sector doesn't exist?  Does the kernel oops if a scsi disk has a bad block?

Change the code that now oops's and replace it with a return of an error value.

Is that practical?

Cheers,
David

[linuxdc-dev] Trapping exceptions in the kernel

[Adrian M. <ad...@mc...>]

Is there a way of doing this? I want to rewrite the vmufs driver to make it as 
independent of the underlying medium as possible and so I wanto to probe the 
size of the vmu.

An obvious way is to attempt to read in vmu sectors until this fails - eg at 
128, at 256, at 512, at 1024. (Working on the suggested likely sizes for 
alternative VMUs, assuming these things just might exist somewhere).

On a standard VMU 128 would succeed, 256 would fail and a simple check would 
then reveal that the superblock was in sector 255.

But a buffer read at 256 will oops the kernel in these circumstances - is 
there a mechanism to trap that exception?

Adrian

Re: [linuxdc-dev] hi

[M. R. B. <mr...@0x...>]

* ps...@wi... <ps...@wi...> on Thu, N=
ov 07, 2002:

>=20
> by the by, does anyone have a binary of a ramdisk and kernel to be used t=
o access things like serial and the GDROM without having the cd loaded? i'd=
 like to... access certain gdrom disks of mine and previous methods have fa=
iled, largely due to my own incompetence.
>=20

The Linux GD-ROM driver doesn't support GD-ROMs by design.  You can only
use normal CD-ROM media.

M. R.

Re: [linuxdc-dev] hi

[<ps...@wi...>]

On Thu, 07 Nov 2002 12:05:20 +0100
Lorant Toth <Lor...@gm...> wrote:

> Bill Gatliff's article on LinuxDevices.com does give a pretty good 
> overview. Should be enough methinks. I will try to recompile it too as soon 
> as I get a coder's cable I think [and figure out how to use it to test 
> compiled programs ;]. (I don't really want to burn a new CD each time) - or 
> is there even another way to test LinuxDC compiled programs?
> BTW: Does anybody know a good (german, maybe european) source for a coder's 
> cable?

www.lik-sang.com - a favorite for years. the site's in hong kong but they ship to the US so i assume they'll ship to germany too. i got my Broadband Adapter there a while back. while they may run you quite a pretty penny nowadays, they are quite useful for development and general linux use. i also got my Coder's Cable there, and have never used it, but it's here if i do find the urge to use the serial port instead of ethernet some day. i assume you could set up SLIP for communications, but when linux is booted and [a]getty is running on the serial port, just plug the serial connector into a serial port on your PC, run [a]getty on that serial port, and you've pretty much got a console type link. 

by the by, does anyone have a binary of a ramdisk and kernel to be used to access things like serial and the GDROM without having the cd loaded? i'd like to... access certain gdrom disks of mine and previous methods have failed, largely due to my own incompetence.

Re: [linuxdc-dev] hi

[M. R. B. <mr...@0x...>]

* Lorant Toth <Lor...@gm...> on Thu, Nov 07, 2002:

>=20
> *Or* does anybody know if it is possible to use the internal dreamcast=20
> modem with Linux yet? Is it a standard modem? B/c there are actually guid=
es=20
> on connecting a dreamcast with a dreamkey browser to a Windows box to sur=
f=20
> the internet -> networking between DC and PC w/o the BBA (which is really=
=20
> rare here :(   ) . That should be possible w/ Linux on both sides as well=
,=20
> right?!
>=20

A serial driver has to be written for the DC modem.  It's on the TODO list,
but of course patches are always welcome...

M. R.

Re: [linuxdc-dev] hi

[Lorant T. <Lor...@gm...>]

Bill Gatliff's article on LinuxDevices.com does give a pretty good 
overview. Should be enough methinks. I will try to recompile it too as soon 
as I get a coder's cable I think [and figure out how to use it to test 
compiled programs ;]. (I don't really want to burn a new CD each time) - or 
is there even another way to test LinuxDC compiled programs?

http://linuxdevices.com/articles/AT7466555948.html

BTW: Does anybody know a good (german, maybe european) source for a coder's 
cable?

*Or* does anybody know if it is possible to use the internal dreamcast 
modem with Linux yet? Is it a standard modem? B/c there are actually guides 
on connecting a dreamcast with a dreamkey browser to a Windows box to surf 
the internet -> networking between DC and PC w/o the BBA (which is really 
rare here :(   ) . That should be possible w/ Linux on both sides as well, 
right?!

- Lorant

At 17:54 06.11.2002 -0600, Ben Srour wrote:
>Could someone give me a quick and dirty "here is how to compile the
>checked out kernel code from cvs" howto? I can't wait to start working on
>this.
>
>ben
>
>--
>Ben Srour
>sr...@cs...
>
>On Wed, 6 Nov 2002, Adrian McMenamin wrote:
>
> > On Wednesday 06 Nov 2002 7:03 pm, Lorant Toth wrote:
> > > hello,
> > >
> > > I'm new to this list. So maybe that's a dumb question but I am 
> curious. Did
> > > anybody ever try compile and run Qt/Embedded and qtopia/opie on the DC?
> > > Should work memory-wise, have no idea about the qt/e internals though
> > > (maybe it works with an fb-device?). I don't know but I'd love to see 
> a guy
> > > with some nice applications. Although Opie might look childish and 
> for PDAs
> > > I guess there are a few interesting apps like Konquerer running as well.
> > >
> > > Regards
> > >
> > > - Lorant
> > >
> > Both Marcus Brown and I were able to build static (ie total bloat) 
> versions of
> > the Qt/E apps, but some things wouldn't build and nothing would build 
> shared.
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: See the NEW Palm
> > Tungsten T handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> > _______________________________________________
> > Linuxdc-dev mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
> >