Skip to contentSkip to conversation

What device for ROMFS ?

DISCUSSION Marc-F. LUCCA-DANIAU 3 participants 8 messages May 23, 2016 – Jan 22, 2017 2 messages not in the archive

lore
Share & tools
lore
#0 lore raw

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
   0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
   1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
   2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   3: 1048 => 0000 0000 0000 0000 0000 0000 0000
   4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   5: 1048 => 0000 0000 0000 0000 0000 0000 0000
   6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   7: 1048 => 0000 0000 0000 0000 0000 0000 0000
   8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Thanks,

MFLD

#1 lore raw

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

Quoted 47 lines · Marc-F. LUCCA-DANIAU

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
   0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
   1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
   2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   3: 1048 => 0000 0000 0000 0000 0000 0000 0000
   4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   5: 1048 => 0000 0000 0000 0000 0000 0000 0000
   6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   7: 1048 => 0000 0000 0000 0000 0000 0000 0000
   8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
In reply to a message not in the archive

Thanks Juan for that info.

It helped me to find some missing #define in the setup configuration reading.
I will commit the related fixes later (because not so many people using ROM boot for ELKS :-)).

Coding a fresh new block device is one solution, but the ROM is by nature a flat and linear device (except when erasing / writting).

So I would rather refactor the existing ROMFS to directly pick data from a given area in the ROM, and that area to be described in the ELKS config, like the other ROM options.

Does it make sense ?

MFLD

Quoted 63 lines

Le 24/05/2016 01:07, Juan Perez-Sanchez a écrit :

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

On Mon, May 23, 2016 at 12:09 PM, Marc-F. LUCCA-DANIAU <[email protected]> wrote:

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
   0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
   1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
   2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   3: 1048 => 0000 0000 0000 0000 0000 0000 0000
   4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   5: 1048 => 0000 0000 0000 0000 0000 0000 0000
   6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   7: 1048 => 0000 0000 0000 0000 0000 0000 0000
   8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Quoted 10 lines

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
In reply to a message not in the archive

I do not intend to implement banked memory support, neither on my real SBC that has not such, nor in the EMU86 emulator where I test my SW before burning it to that SBC Flash. Just because I don't need it. 512K RAM and 512K ROM are enough for running ELKS with a confortable margin, especially when the code segment of the kernel is in ROM and let 40 K of additionnal RAM space.

The only constrained area is the root image to be stored in ROM : a full3 image for 1.44 MB floppy cannot fit in 512 K of ROM, so I have to think a bit about it. First of all, all the ELKS cmdlets are not needed for that target. And second, floppy is a block device, and so wastes lot a space because of block aligment. ROM has no alignement concern. Plus removing the bootloader & the kernel (already in ROM as raw blocks). Etc...

This would not be the same story on a 8-bits system. You can have a look to Alan's FUZZIX project presentation, where the banked memory is a must-have : https://github.com/EtchedPixels/FUZIX

MFLD

2016-05-26 11:41 GMT+02:00 Kirn Gill <[email protected]>:

Quoted 106 lines

Does this work for banked ROM? Or are ROMFS builds expected to fit within the 8086 memory space?

Quoted 101 lines · Marc-François LUCCA-DANIAU

Thanks Juan for that info.

It helped me to find some missing #define in the setup configuration reading.
I will commit the related fixes later (because not so many people using ROM
boot for ELKS :-)).

Coding a fresh new block device is one solution, but the ROM is by nature a
flat and linear device (except when erasing / writting).

So I would rather refactor the existing ROMFS to directly pick data from a given area in the ROM, and that area to be described in the ELKS config, like the other ROM options.

Does it make sense ?

MFLD

Quoted 65 lines · Juan Perez-Sanchez

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

On Mon, May 23, 2016 at 12:09 PM, Marc-F. LUCCA-DANIAU <[email protected]> wrote:

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it
under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user
processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
   0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
   1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
   2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   3: 1048 => 0000 0000 0000 0000 0000 0000 0000
   4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   5: 1048 => 0000 0000 0000 0000 0000 0000 0000
   6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   7: 1048 => 0000 0000 0000 0000 0000 0000 0000
   8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Quoted 10 lines

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw
Quoted 3 lines

This would not be the same story on a 8-bits system. You can have a look to Alan's FUZZIX project presentation, where the banked memory is a must-have : https://github.com/EtchedPixels/FUZIX

The Z180 based FUZIX systems effectively have some minimal segmentation rather than simple banking. You just need enough address space, and I agree 512K of memory is tons for a well written OS. I don't think I've ever managed to find a reason to use all the 512K of RAM on a Z180 based FUZIX box !

The other advantage of ROM if all mapped is that with a bit of tweaking you should be able to just insert the ROM banks into the segment map when you do an execve so that split I/D ('small rather than tiny in DOS speak') binaries can run with the code running directly from the ROM and taking no RAM space at all.

Alan

#7 lore raw
In reply to a message not in the archive

Looks good. That would be an interesting contribution to this project. Later, you could add Execute In Place (XIP) to this modified ROMFS.

Juan

Quoted 82 lines · Marc-F. LUCCA-DANIAU

Thanks Juan for that info.

It helped me to find some missing #define in the setup configuration reading.
I will commit the related fixes later (because not so many people using ROM boot for ELKS :-)).

Coding a fresh new block device is one solution, but the ROM is by nature a flat and linear device (except when erasing / writting).

So I would rather refactor the existing ROMFS to directly pick data from a given area in the ROM, and that area to be described in the ELKS config, like the other ROM options.

Does it make sense ?

MFLD

Le 24/05/2016 01:07, Juan Perez-Sanchez a écrit :

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

On Mon, May 23, 2016 at 12:09 PM, Marc-F. LUCCA-DANIAU <[email protected]> wrote:

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
   0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
   1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
   2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   3: 1048 => 0000 0000 0000 0000 0000 0000 0000
   4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   5: 1048 => 0000 0000 0000 0000 0000 0000 0000
   6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
   7: 1048 => 0000 0000 0000 0000 0000 0000 0000
   8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Quoted 10 lines

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw

Tracked by :

https://github.com/mfld-fr/elks/issues/2

MFLD

Quoted 99 lines · Juan Perez-Sanchez

Looks good. That would be an interesting contribution to this project. Later, you could add Execute In Place (XIP) to this modified ROMFS.

Juan

Quoted 92 lines · Marc-F. LUCCA-DANIAU

Thanks Juan for that info.

It helped me to find some missing #define in the setup configuration reading.
I will commit the related fixes later (because not so many people using ROM boot for ELKS :-)).

Coding a fresh new block device is one solution, but the ROM is by nature a flat and linear device (except when erasing / writting).

So I would rather refactor the existing ROMFS to directly pick data from a given area in the ROM, and that area to be described in the ELKS config, like the other ROM options.

Does it make sense ?

MFLD

Le 24/05/2016 01:07, Juan Perez-Sanchez a écrit :

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

On Mon, May 23, 2016 at 12:09 PM, Marc-F. LUCCA-DANIAU <[email protected]> wrote:

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
    0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
    1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
    2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    3: 1048 => 0000 0000 0000 0000 0000 0000 0000
    4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    5: 1048 => 0000 0000 0000 0000 0000 0000 0000
    6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    7: 1048 => 0000 0000 0000 0000 0000 0000 0000
    8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw

Tracked by :

https://github.com/mfld-fr/elks/issues/2

MFLD

Quoted 110 lines · Juan Perez-Sanchez
Quoted 107 lines

Looks good. That would be an interesting contribution to this project. Later, you could add Execute In Place (XIP) to this modified ROMFS.

Juan

Quoted 98 lines · Marc-F. LUCCA-DANIAU

Thanks Juan for that info.

It helped me to find some missing #define in the setup configuration reading.
I will commit the related fixes later (because not so many people using ROM
boot for ELKS :-)).

Coding a fresh new block device is one solution, but the ROM is by nature a
flat and linear device (except when erasing / writting).

So I would rather refactor the existing ROMFS to directly pick data from a
given area in the ROM, and that area to be described in the ELKS config, like the other ROM options.

Does it make sense ?

MFLD

Le 24/05/2016 01:07, Juan Perez-Sanchez a écrit :

Hello:

For the standard case, the root device is defined by the arch/i86/tools/build program (see Documentation/text/boot.txt). The device number is saved in bytes 508,509 of boot sector.

After booting, the root device number is read from that location into the ROOT_DEV variable by the function setup_arch() in arch/i86/kernel/system.c.

Maybe the mkbootloader does not define the root device as expected by the kernel.

In addition, you will have to write a ROM block device driver. Also, I think romfs for ELKS never reached a working status.

Juan

On Mon, May 23, 2016 at 12:09 PM, Marc-F. LUCCA-DANIAU <[email protected]> wrote:

Hello,

In a few words: what is the device to be used for a ROMFS root ?

More: I configured ELKS as a ROM image for an embedded system, and I run it
under EMU86, but I cannot figure out:

1- how to tell ELKS to read the ROMFS superblock from ROM address space? 2- how to build a ROMFS image to put in the ROM address space?

All my tries end up with the well known:

$ ./emu86 -w 0xe0000 -f ../../elks/elks/arch/i86/Image -x 0xe000:0x42 -i
$ ./pcat `cat emu86.pts`
Loading kernel image...
Console: BIOS 10x115 emulating ANSI (3 virtual consoles)
PC/AT class machine, inode! CPU8308K base RAM, CPUID `nd socket for in'.
ELKS kernel (39008 text + 4168 data + 48648 bss)
Kernel text at e062:0000, data at 90:0000 62 K of memory for user
processes.
ELKS network sockets
TCP/IP stack by Harry Kalogirou
ELKS version 0.2.0
panic: VFS: Unable to mount root fs on 206D
apparent call stack:
Line: Addr    Parameters~~~~: ~~~~    ~~~~~~~~~~
    0: 1D59 => 0000 7102 0000 0000 0000 0000 0000
    1: 00B7 => 0000 0000 0000 0000 0000 0000 0000
    2: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    3: 1048 => 0000 0000 0000 0000 0000 0000 0000
    4: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    5: 1048 => 0000 0000 0000 0000 0000 0000 0000
    6: 0000 => CE50 0000 0000 0001 0000 6166 6C69
    7: 1048 => 0000 0000 0000 0000 0000 0000 0000
    8: 0000 => CE50 0000 0000 0001 0000 6166 6C69
SYSTEM LOCKED - Press CTRL-ALT-DEL to reboot:

Any suggestion ?

Thanks,

MFLD

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html